Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7996: drop fragments with multicast or broadcast RA<br /> <br /> IEEE 802.11 fragmentation can only be applied to unicast frames.<br /> Therefore, drop fragments with multicast or broadcast RA. This patch<br /> addresses vulnerabilities such as CVE-2020-26145.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback()<br /> <br /> Robert Morris reported:<br /> <br /> |If a malicious USB device pretends to be an Intersil p54 wifi<br /> |interface and generates an eeprom_readback message with a large<br /> |eeprom-&gt;v1.len, p54_rx_eeprom_readback() will copy data from the<br /> |message beyond the end of priv-&gt;eeprom.<br /> |<br /> |static void p54_rx_eeprom_readback(struct p54_common *priv,<br /> | struct sk_buff *skb)<br /> |{<br /> | struct p54_hdr *hdr = (struct p54_hdr *) skb-&gt;data;<br /> | struct p54_eeprom_lm86 *eeprom = (struct p54_eeprom_lm86 *) hdr-&gt;data;<br /> |<br /> | if (priv-&gt;fw_var &gt;= 0x509) {<br /> | memcpy(priv-&gt;eeprom, eeprom-&gt;v2.data,<br /> | le16_to_cpu(eeprom-&gt;v2.len));<br /> | } else {<br /> | memcpy(priv-&gt;eeprom, eeprom-&gt;v1.data,<br /> | le16_to_cpu(eeprom-&gt;v1.len));<br /> | }<br /> | [...]<br /> <br /> The eeprom-&gt;v{1,2}.len is set by the driver in p54_download_eeprom().<br /> The device is supposed to provide the same length back to the driver.<br /> But yes, it&amp;#39;s possible (like shown in the report) to alter the value<br /> to something that causes a crash/panic due to overrun.<br /> <br /> This patch addresses the issue by adding the size to the common device<br /> context, so p54_rx_eeprom_readback no longer relies on possibly tampered<br /> values... That said, it also checks if the "firmware" altered the value<br /> and no longer copies them.<br /> <br /> The one, small saving grace is: Before the driver tries to read the eeprom,<br /> it needs to upload &gt;a

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ftrace: Fix UAF when lookup kallsym after ftrace disabled<br /> <br /> The following issue happens with a buggy module:<br /> <br /> BUG: unable to handle page fault for address: ffffffffc05d0218<br /> PGD 1bd66f067 P4D 1bd66f067 PUD 1bd671067 PMD 101808067 PTE 0<br /> Oops: Oops: 0000 [#1] SMP KASAN PTI<br /> Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS<br /> RIP: 0010:sized_strscpy+0x81/0x2f0<br /> RSP: 0018:ffff88812d76fa08 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: ffffffffc0601010 RCX: dffffc0000000000<br /> RDX: 0000000000000038 RSI: dffffc0000000000 RDI: ffff88812608da2d<br /> RBP: 8080808080808080 R08: ffff88812608da2d R09: ffff88812608da68<br /> R10: ffff88812608d82d R11: ffff88812608d810 R12: 0000000000000038<br /> R13: ffff88812608da2d R14: ffffffffc05d0218 R15: fefefefefefefeff<br /> FS: 00007fef552de740(0000) GS:ffff8884251c7000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffffffffc05d0218 CR3: 00000001146f0000 CR4: 00000000000006f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ftrace_mod_get_kallsym+0x1ac/0x590<br /> update_iter_mod+0x239/0x5b0<br /> s_next+0x5b/0xa0<br /> seq_read_iter+0x8c9/0x1070<br /> seq_read+0x249/0x3b0<br /> proc_reg_read+0x1b0/0x280<br /> vfs_read+0x17f/0x920<br /> ksys_read+0xf3/0x1c0<br /> do_syscall_64+0x5f/0x2e0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> The above issue may happen as follows:<br /> (1) Add kprobe tracepoint;<br /> (2) insmod test.ko;<br /> (3) Module triggers ftrace disabled;<br /> (4) rmmod test.ko;<br /> (5) cat /proc/kallsyms; --&gt; Will trigger UAF as test.ko already removed;<br /> ftrace_mod_get_kallsym()<br /> ...<br /> strscpy(module_name, mod_map-&gt;mod-&gt;name, MODULE_NAME_LEN);<br /> ...<br /> <br /> The problem is when a module triggers an issue with ftrace and<br /> sets ftrace_disable. The ftrace_disable is set when an anomaly is<br /> discovered and to prevent any more damage, ftrace stops all text<br /> modification. The issue that happened was that the ftrace_disable stops<br /> more than just the text modification.<br /> <br /> When a module is loaded, its init functions can also be traced. Because<br /> kallsyms deletes the init functions after a module has loaded, ftrace<br /> saves them when the module is loaded and function tracing is enabled. This<br /> allows the output of the function trace to show the init function names<br /> instead of just their raw memory addresses.<br /> <br /> When a module is removed, ftrace_release_mod() is called, and if<br /> ftrace_disable is set, it just returns without doing anything more. The<br /> problem here is that it leaves the mod_list still around and if kallsyms<br /> is called, it will call into this code and access the module memory that<br /> has already been freed as it will return:<br /> <br /> strscpy(module_name, mod_map-&gt;mod-&gt;name, MODULE_NAME_LEN);<br /> <br /> Where the "mod" no longer exists and triggers a UAF bug.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPICA: fix acpi operand cache leak in dswstate.c<br /> <br /> ACPICA commit 987a3b5cf7175916e2a4b6ea5b8e70f830dfe732<br /> <br /> I found an ACPI cache leak in ACPI early termination and boot continuing case.<br /> <br /> When early termination occurs due to malicious ACPI table, Linux kernel<br /> terminates ACPI function and continues to boot process. While kernel terminates<br /> ACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak.<br /> <br /> Boot log of ACPI operand cache leak is as follows:<br /> &gt;[ 0.585957] ACPI: Added _OSI(Module Device)<br /> &gt;[ 0.587218] ACPI: Added _OSI(Processor Device)<br /> &gt;[ 0.588530] ACPI: Added _OSI(3.0 _SCP Extensions)<br /> &gt;[ 0.589790] ACPI: Added _OSI(Processor Aggregator Device)<br /> &gt;[ 0.591534] ACPI Error: Illegal I/O port address/length above 64K: C806E00000004002/0x2 (20170303/hwvalid-155)<br /> &gt;[ 0.594351] ACPI Exception: AE_LIMIT, Unable to initialize fixed events (20170303/evevent-88)<br /> &gt;[ 0.597858] ACPI: Unable to start the ACPI Interpreter<br /> &gt;[ 0.599162] ACPI Error: Could not remove SCI handler (20170303/evmisc-281)<br /> &gt;[ 0.601836] kmem_cache_destroy Acpi-Operand: Slab cache still has objects<br /> &gt;[ 0.603556] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26<br /> &gt;[ 0.605159] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006<br /> &gt;[ 0.609177] Call Trace:<br /> &gt;[ 0.610063] ? dump_stack+0x5c/0x81<br /> &gt;[ 0.611118] ? kmem_cache_destroy+0x1aa/0x1c0<br /> &gt;[ 0.612632] ? acpi_sleep_proc_init+0x27/0x27<br /> &gt;[ 0.613906] ? acpi_os_delete_cache+0xa/0x10<br /> &gt;[ 0.617986] ? acpi_ut_delete_caches+0x3f/0x7b<br /> &gt;[ 0.619293] ? acpi_terminate+0xa/0x14<br /> &gt;[ 0.620394] ? acpi_init+0x2af/0x34f<br /> &gt;[ 0.621616] ? __class_create+0x4c/0x80<br /> &gt;[ 0.623412] ? video_setup+0x7f/0x7f<br /> &gt;[ 0.624585] ? acpi_sleep_proc_init+0x27/0x27<br /> &gt;[ 0.625861] ? do_one_initcall+0x4e/0x1a0<br /> &gt;[ 0.627513] ? kernel_init_freeable+0x19e/0x21f<br /> &gt;[ 0.628972] ? rest_init+0x80/0x80<br /> &gt;[ 0.630043] ? kernel_init+0xa/0x100<br /> &gt;[ 0.631084] ? ret_from_fork+0x25/0x30<br /> &gt;[ 0.633343] vgaarb: loaded<br /> &gt;[ 0.635036] EDAC MC: Ver: 3.0.0<br /> &gt;[ 0.638601] PCI: Probing PCI hardware<br /> &gt;[ 0.639833] PCI host bridge to bus 0000:00<br /> &gt;[ 0.641031] pci_bus 0000:00: root bus resource [io 0x0000-0xffff]<br /> &gt; ... Continue to boot and log is omitted ...<br /> <br /> I analyzed this memory leak in detail and found acpi_ds_obj_stack_pop_and_<br /> delete() function miscalculated the top of the stack. acpi_ds_obj_stack_push()<br /> function uses walk_state-&gt;operand_index for start position of the top, but<br /> acpi_ds_obj_stack_pop_and_delete() function considers index 0 for it.<br /> Therefore, this causes acpi operand memory leak.<br /> <br /> This cache leak causes a security threat because an old kernel (

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPICA: fix acpi parse and parseext cache leaks<br /> <br /> ACPICA commit 8829e70e1360c81e7a5a901b5d4f48330e021ea5<br /> <br /> I&amp;#39;m Seunghun Han, and I work for National Security Research Institute of<br /> South Korea.<br /> <br /> I have been doing a research on ACPI and found an ACPI cache leak in ACPI<br /> early abort cases.<br /> <br /> Boot log of ACPI cache leak is as follows:<br /> [ 0.352414] ACPI: Added _OSI(Module Device)<br /> [ 0.353182] ACPI: Added _OSI(Processor Device)<br /> [ 0.353182] ACPI: Added _OSI(3.0 _SCP Extensions)<br /> [ 0.353182] ACPI: Added _OSI(Processor Aggregator Device)<br /> [ 0.356028] ACPI: Unable to start the ACPI Interpreter<br /> [ 0.356799] ACPI Error: Could not remove SCI handler (20170303/evmisc-281)<br /> [ 0.360215] kmem_cache_destroy Acpi-State: Slab cache still has objects<br /> [ 0.360648] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W<br /> 4.12.0-rc4-next-20170608+ #10<br /> [ 0.361273] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS<br /> virtual_box 12/01/2006<br /> [ 0.361873] Call Trace:<br /> [ 0.362243] ? dump_stack+0x5c/0x81<br /> [ 0.362591] ? kmem_cache_destroy+0x1aa/0x1c0<br /> [ 0.362944] ? acpi_sleep_proc_init+0x27/0x27<br /> [ 0.363296] ? acpi_os_delete_cache+0xa/0x10<br /> [ 0.363646] ? acpi_ut_delete_caches+0x6d/0x7b<br /> [ 0.364000] ? acpi_terminate+0xa/0x14<br /> [ 0.364000] ? acpi_init+0x2af/0x34f<br /> [ 0.364000] ? __class_create+0x4c/0x80<br /> [ 0.364000] ? video_setup+0x7f/0x7f<br /> [ 0.364000] ? acpi_sleep_proc_init+0x27/0x27<br /> [ 0.364000] ? do_one_initcall+0x4e/0x1a0<br /> [ 0.364000] ? kernel_init_freeable+0x189/0x20a<br /> [ 0.364000] ? rest_init+0xc0/0xc0<br /> [ 0.364000] ? kernel_init+0xa/0x100<br /> [ 0.364000] ? ret_from_fork+0x25/0x30<br /> <br /> I analyzed this memory leak in detail. I found that “Acpi-State” cache and<br /> “Acpi-Parse” cache were merged because the size of cache objects was same<br /> slab cache size.<br /> <br /> I finally found “Acpi-Parse” cache and “Acpi-parse_ext” cache were leaked<br /> using SLAB_NEVER_MERGE flag in kmem_cache_create() function.<br /> <br /> Real ACPI cache leak point is as follows:<br /> [ 0.360101] ACPI: Added _OSI(Module Device)<br /> [ 0.360101] ACPI: Added _OSI(Processor Device)<br /> [ 0.360101] ACPI: Added _OSI(3.0 _SCP Extensions)<br /> [ 0.361043] ACPI: Added _OSI(Processor Aggregator Device)<br /> [ 0.364016] ACPI: Unable to start the ACPI Interpreter<br /> [ 0.365061] ACPI Error: Could not remove SCI handler (20170303/evmisc-281)<br /> [ 0.368174] kmem_cache_destroy Acpi-Parse: Slab cache still has objects<br /> [ 0.369332] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W<br /> 4.12.0-rc4-next-20170608+ #8<br /> [ 0.371256] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS<br /> virtual_box 12/01/2006<br /> [ 0.372000] Call Trace:<br /> [ 0.372000] ? dump_stack+0x5c/0x81<br /> [ 0.372000] ? kmem_cache_destroy+0x1aa/0x1c0<br /> [ 0.372000] ? acpi_sleep_proc_init+0x27/0x27<br /> [ 0.372000] ? acpi_os_delete_cache+0xa/0x10<br /> [ 0.372000] ? acpi_ut_delete_caches+0x56/0x7b<br /> [ 0.372000] ? acpi_terminate+0xa/0x14<br /> [ 0.372000] ? acpi_init+0x2af/0x34f<br /> [ 0.372000] ? __class_create+0x4c/0x80<br /> [ 0.372000] ? video_setup+0x7f/0x7f<br /> [ 0.372000] ? acpi_sleep_proc_init+0x27/0x27<br /> [ 0.372000] ? do_one_initcall+0x4e/0x1a0<br /> [ 0.372000] ? kernel_init_freeable+0x189/0x20a<br /> [ 0.372000] ? rest_init+0xc0/0xc0<br /> [ 0.372000] ? kernel_init+0xa/0x100<br /> [ 0.372000] ? ret_from_fork+0x25/0x30<br /> [ 0.388039] kmem_cache_destroy Acpi-parse_ext: Slab cache still has objects<br /> [ 0.389063] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W<br /> 4.12.0-rc4-next-20170608+ #8<br /> [ 0.390557] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS<br /> virtual_box 12/01/2006<br /> [ 0.392000] Call Trace:<br /> [ 0.392000] ? dump_stack+0x5c/0x81<br /> [ 0.392000] ? kmem_cache_destroy+0x1aa/0x1c0<br /> [ 0.392000] ? acpi_sleep_proc_init+0x27/0x27<br /> [ 0.392000] ? acpi_os_delete_cache+0xa/0x10<br /> [ 0.392000] ? acpi_ut_delete_caches+0x6d/0x7b<br /> [ 0.392000] ? acpi_terminate+0xa/0x14<br /> [ 0.392000] ? acpi_init+0x2af/0x3<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> software node: Correct a OOB check in software_node_get_reference_args()<br /> <br /> software_node_get_reference_args() wants to get @index-th element, so<br /> the property value requires at least &amp;#39;(index + 1) * sizeof(*ref)&amp;#39; bytes<br /> but that can not be guaranteed by current OOB check, and may cause OOB<br /> for malformed property.<br /> <br /> Fix by using as OOB check &amp;#39;((index + 1) * sizeof(*ref) &gt; prop-&gt;length)&amp;#39;.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> eth: fbnic: avoid double free when failing to DMA-map FW msg<br /> <br /> The semantics are that caller of fbnic_mbx_map_msg() retains<br /> the ownership of the message on error. All existing callers<br /> dutifully free the page.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: cs_dsp: Fix OOB memory read access in KUnit test<br /> <br /> KASAN reported out of bounds access - cs_dsp_mock_bin_add_name_or_info(),<br /> because the source string length was rounded up to the allocation size.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/bpf: fix JIT code size calculation of bpf trampoline<br /> <br /> arch_bpf_trampoline_size() provides JIT size of the BPF trampoline<br /> before the buffer for JIT&amp;#39;ing it is allocated. The total number of<br /> instructions emitted for BPF trampoline JIT code depends on where<br /> the final image is located. So, the size arrived at with the dummy<br /> pass in arch_bpf_trampoline_size() can vary from the actual size<br /> needed in arch_prepare_bpf_trampoline(). When the instructions<br /> accounted in arch_bpf_trampoline_size() is less than the number of<br /> instructions emitted during the actual JIT compile of the trampoline,<br /> the below warning is produced:<br /> <br /> WARNING: CPU: 8 PID: 204190 at arch/powerpc/net/bpf_jit_comp.c:981 __arch_prepare_bpf_trampoline.isra.0+0xd2c/0xdcc<br /> <br /> which is:<br /> <br /> /* Make sure the trampoline generation logic doesn&amp;#39;t overflow */<br /> if (image &amp;&amp; WARN_ON_ONCE(&amp;image[ctx-&gt;idx] &gt;<br /> (u32 *)rw_image_end - BPF_INSN_SAFETY)) {<br /> <br /> So, during the dummy pass, instead of providing some arbitrary image<br /> location, account for maximum possible instructions if and when there<br /> is a dependency with image location for JIT&amp;#39;ing.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/nfs/read: fix double-unlock bug in nfs_return_empty_folio()<br /> <br /> Sometimes, when a file was read while it was being truncated by<br /> another NFS client, the kernel could deadlock because folio_unlock()<br /> was called twice, and the second call would XOR back the `PG_locked`<br /> flag.<br /> <br /> Most of the time (depending on the timing of the truncation), nobody<br /> notices the problem because folio_unlock() gets called three times,<br /> which flips `PG_locked` back off:<br /> <br /> 1. vfs_read, nfs_read_folio, ... nfs_read_add_folio,<br /> nfs_return_empty_folio<br /> 2. vfs_read, nfs_read_folio, ... netfs_read_collection,<br /> netfs_unlock_abandoned_read_pages<br /> 3. vfs_read, ... nfs_do_read_folio, nfs_read_add_folio,<br /> nfs_return_empty_folio<br /> <br /> The problem is that nfs_read_add_folio() is not supposed to unlock the<br /> folio if fscache is enabled, and a nfs_netfs_folio_unlock() check is<br /> missing in nfs_return_empty_folio().<br /> <br /> Rarely this leads to a warning in netfs_read_collection():<br /> <br /> ------------[ cut here ]------------<br /> R=0000031c: folio 10 is not locked<br /> WARNING: CPU: 0 PID: 29 at fs/netfs/read_collect.c:133 netfs_read_collection+0x7c0/0xf00<br /> [...]<br /> Workqueue: events_unbound netfs_read_collection_worker<br /> RIP: 0010:netfs_read_collection+0x7c0/0xf00<br /> [...]<br /> Call Trace:<br /> <br /> netfs_read_collection_worker+0x67/0x80<br /> process_one_work+0x12e/0x2c0<br /> worker_thread+0x295/0x3a0<br /> <br /> Most of the time, however, processes just get stuck forever in<br /> folio_wait_bit_common(), waiting for `PG_locked` to disappear, which<br /> never happens because nobody is really holding the folio lock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jbd2: fix data-race and null-ptr-deref in jbd2_journal_dirty_metadata()<br /> <br /> Since handle-&gt;h_transaction may be a NULL pointer, so we should change it<br /> to call is_handle_aborted(handle) first before dereferencing it.<br /> <br /> And the following data-race was reported in my fuzzer:<br /> <br /> ==================================================================<br /> BUG: KCSAN: data-race in jbd2_journal_dirty_metadata / jbd2_journal_dirty_metadata<br /> <br /> write to 0xffff888011024104 of 4 bytes by task 10881 on cpu 1:<br /> jbd2_journal_dirty_metadata+0x2a5/0x770 fs/jbd2/transaction.c:1556<br /> __ext4_handle_dirty_metadata+0xe7/0x4b0 fs/ext4/ext4_jbd2.c:358<br /> ext4_do_update_inode fs/ext4/inode.c:5220 [inline]<br /> ext4_mark_iloc_dirty+0x32c/0xd50 fs/ext4/inode.c:5869<br /> __ext4_mark_inode_dirty+0xe1/0x450 fs/ext4/inode.c:6074<br /> ext4_dirty_inode+0x98/0xc0 fs/ext4/inode.c:6103<br /> ....<br /> <br /> read to 0xffff888011024104 of 4 bytes by task 10880 on cpu 0:<br /> jbd2_journal_dirty_metadata+0xf2/0x770 fs/jbd2/transaction.c:1512<br /> __ext4_handle_dirty_metadata+0xe7/0x4b0 fs/ext4/ext4_jbd2.c:358<br /> ext4_do_update_inode fs/ext4/inode.c:5220 [inline]<br /> ext4_mark_iloc_dirty+0x32c/0xd50 fs/ext4/inode.c:5869<br /> __ext4_mark_inode_dirty+0xe1/0x450 fs/ext4/inode.c:6074<br /> ext4_dirty_inode+0x98/0xc0 fs/ext4/inode.c:6103<br /> ....<br /> <br /> value changed: 0x00000000 -&gt; 0x00000001<br /> ==================================================================<br /> <br /> This issue is caused by missing data-race annotation for jh-&gt;b_modified.<br /> Therefore, the missing annotation needs to be added.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ata: pata_via: Force PIO for ATAPI devices on VT6415/VT6330<br /> <br /> The controller has a hardware bug that can hard hang the system when<br /> doing ATAPI DMAs without any trace of what happened. Depending on the<br /> device attached, it can also prevent the system from booting.<br /> <br /> In this case, the system hangs when reading the ATIP from optical media<br /> with cdrecord -vvv -atip on an _NEC DVD_RW ND-4571A 1-01 and an<br /> Optiarc DVD RW AD-7200A 1.06 attached to an ASRock 990FX Extreme 4,<br /> running at UDMA/33.<br /> <br /> The issue can be reproduced by running the same command with a cygwin<br /> build of cdrecord on WinXP, although it requires more attempts to cause<br /> it. The hang in that case is also resolved by forcing PIO. It doesn&amp;#39;t<br /> appear that VIA has produced any drivers for that OS, thus no known<br /> workaround exists.<br /> <br /> HDDs attached to the controller do not suffer from any DMA issues.