Vulnerabilities

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 /> f2fs: fix to do sanity check on ino and xnid<br /> <br /> syzbot reported a f2fs bug as below:<br /> <br /> INFO: task syz-executor140:5308 blocked for more than 143 seconds.<br /> Not tainted 6.14.0-rc7-syzkaller-00069-g81e4f8d68c66 #0<br /> "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> task:syz-executor140 state:D stack:24016 pid:5308 tgid:5308 ppid:5306 task_flags:0x400140 flags:0x00000006<br /> Call Trace:<br /> <br /> context_switch kernel/sched/core.c:5378 [inline]<br /> __schedule+0x190e/0x4c90 kernel/sched/core.c:6765<br /> __schedule_loop kernel/sched/core.c:6842 [inline]<br /> schedule+0x14b/0x320 kernel/sched/core.c:6857<br /> io_schedule+0x8d/0x110 kernel/sched/core.c:7690<br /> folio_wait_bit_common+0x839/0xee0 mm/filemap.c:1317<br /> __folio_lock mm/filemap.c:1664 [inline]<br /> folio_lock include/linux/pagemap.h:1163 [inline]<br /> __filemap_get_folio+0x147/0xb40 mm/filemap.c:1917<br /> pagecache_get_page+0x2c/0x130 mm/folio-compat.c:87<br /> find_get_page_flags include/linux/pagemap.h:842 [inline]<br /> f2fs_grab_cache_page+0x2b/0x320 fs/f2fs/f2fs.h:2776<br /> __get_node_page+0x131/0x11b0 fs/f2fs/node.c:1463<br /> read_xattr_block+0xfb/0x190 fs/f2fs/xattr.c:306<br /> lookup_all_xattrs fs/f2fs/xattr.c:355 [inline]<br /> f2fs_getxattr+0x676/0xf70 fs/f2fs/xattr.c:533<br /> __f2fs_get_acl+0x52/0x870 fs/f2fs/acl.c:179<br /> f2fs_acl_create fs/f2fs/acl.c:375 [inline]<br /> f2fs_init_acl+0xd7/0x9b0 fs/f2fs/acl.c:418<br /> f2fs_init_inode_metadata+0xa0f/0x1050 fs/f2fs/dir.c:539<br /> f2fs_add_inline_entry+0x448/0x860 fs/f2fs/inline.c:666<br /> f2fs_add_dentry+0xba/0x1e0 fs/f2fs/dir.c:765<br /> f2fs_do_add_link+0x28c/0x3a0 fs/f2fs/dir.c:808<br /> f2fs_add_link fs/f2fs/f2fs.h:3616 [inline]<br /> f2fs_mknod+0x2e8/0x5b0 fs/f2fs/namei.c:766<br /> vfs_mknod+0x36d/0x3b0 fs/namei.c:4191<br /> unix_bind_bsd net/unix/af_unix.c:1286 [inline]<br /> unix_bind+0x563/0xe30 net/unix/af_unix.c:1379<br /> __sys_bind_socket net/socket.c:1817 [inline]<br /> __sys_bind+0x1e4/0x290 net/socket.c:1848<br /> __do_sys_bind net/socket.c:1853 [inline]<br /> __se_sys_bind net/socket.c:1851 [inline]<br /> __x64_sys_bind+0x7a/0x90 net/socket.c:1851<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Let&amp;#39;s dump and check metadata of corrupted inode, it shows its xattr_nid<br /> is the same to its i_ino.<br /> <br /> dump.f2fs -i 3 chaseyu.img.raw<br /> i_xattr_nid [0x 3 : 3]<br /> <br /> So that, during mknod in the corrupted directory, it tries to get and<br /> lock inode page twice, result in deadlock.<br /> <br /> - f2fs_mknod<br /> - f2fs_add_inline_entry<br /> - f2fs_get_inode_page --- lock dir&amp;#39;s inode page<br /> - f2fs_init_acl<br /> - f2fs_acl_create(dir,..)<br /> - __f2fs_get_acl<br /> - f2fs_getxattr<br /> - lookup_all_xattrs<br /> - __get_node_page --- try to lock dir&amp;#39;s inode page<br /> <br /> In order to fix this, let&amp;#39;s add sanity check on ino and xnid.

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.