Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: aloop: Fix peer runtime UAF during format-change stop<br /> <br /> loopback_check_format() may stop the capture side when playback starts<br /> with parameters that no longer match a running capture stream. Commit<br /> 826af7fa62e3 ("ALSA: aloop: Fix racy access at PCM trigger") moved<br /> the peer lookup under cable-&gt;lock, but the actual snd_pcm_stop() still<br /> runs after dropping that lock.<br /> <br /> A concurrent close can clear the capture entry from cable-&gt;streams[] and<br /> detach or free its runtime while the playback trigger path still holds a<br /> stale peer substream pointer.<br /> <br /> Keep a per-cable count of in-flight peer stops before dropping<br /> cable-&gt;lock, and make free_cable() wait for those stops before<br /> detaching the runtime. This preserves the existing behavior while<br /> making the peer runtime lifetime explicit.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: rc: igorplugusb: heed coherency rules<br /> <br /> In a control request, the USB request structure<br /> can be subject to DMA on some HCs. Hence it must obey<br /> the rules for DMA coherency. Allocate it separately.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw88: check for PCI upstream bridge existence<br /> <br /> pci_upstream_bridge() returns NULL if the device is on a root bus. If<br /> 8821CE is installed in the system with such a PCI topology, the probing<br /> routine will crash. This has probably been unnoticed as 8821CE is mostly<br /> supplied in laptops where there is a PCI-to-PCI bridge located upstream<br /> from the device. However the card might be installed on a system with<br /> different configuration.<br /> <br /> Check if the bridge does exist for the specific workaround to be applied.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Svace static<br /> analysis tool.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/vmalloc: take vmap_purge_lock in shrinker<br /> <br /> decay_va_pool_node() can be invoked concurrently from two paths:<br /> __purge_vmap_area_lazy() when pools are being purged, and the shrinker via<br /> vmap_node_shrink_scan().<br /> <br /> However, decay_va_pool_node() is not safe to run concurrently, and the<br /> shrinker path currently lacks serialization, leading to races and possible<br /> leaks.<br /> <br /> Protect decay_va_pool_node() by taking vmap_purge_lock in the shrinker<br /> path to ensure serialization with purge users.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix bounds check in check_xattrs() to prevent out-of-bounds access<br /> <br /> The bounds check for the next xattr entry in check_xattrs() uses<br /> (void *)next &gt;= end, which allows next to point within sizeof(u32)<br /> bytes of end. On the next loop iteration, IS_LAST_ENTRY() reads 4<br /> bytes via *(__u32 *)(entry), which can overrun the valid xattr region.<br /> <br /> For example, if next lands at end - 1, the check passes since<br /> next end,<br /> ensuring there is always enough space for the IS_LAST_ENTRY() read<br /> on the subsequent iteration.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: atmel-tdes - fix DMA sync direction<br /> <br /> Before DMA output is consumed by the CPU, -&gt;dma_addr_out must be synced<br /> with dma_sync_single_for_cpu() instead of dma_sync_single_for_device().<br /> Using the wrong direction can return stale cache data on non-coherent<br /> platforms.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: fix the out-of-bounds nameoff handling for trailing dirents<br /> <br /> Currently we already have boundary-checks for nameoffs, but the trailing<br /> dirents are special since the namelens are calculated with strnlen()<br /> with unchecked nameoffs.<br /> <br /> If a crafted EROFS has a trailing dirent with nameoff &gt;= maxsize,<br /> maxsize - nameoff can underflow, causing strnlen() to read past the<br /> directory block.<br /> <br /> nameoff0 should also be verified to be a multiple of<br /> `sizeof(struct erofs_dirent)` as well [1].<br /> <br /> [1] https://sashiko.dev/#/patchset/20260416063511.3173774-1-hsiangkao%40linux.alibaba.com

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rbd: fix null-ptr-deref when device_add_disk() fails<br /> <br /> do_rbd_add() publishes the device with device_add() before calling<br /> device_add_disk(). If device_add_disk() fails after device_add()<br /> succeeds, the error path calls rbd_free_disk() directly and then later<br /> falls through to rbd_dev_device_release(), which calls rbd_free_disk()<br /> again. This double teardown can leave blk-mq cleanup operating on<br /> invalid state and trigger a null-ptr-deref in<br /> __blk_mq_free_map_and_rqs(), reached from blk_mq_free_tag_set().<br /> <br /> Fix this by following the normal remove ordering: call device_del()<br /> before rbd_dev_device_release() when device_add_disk() fails after<br /> device_add(). That keeps the teardown sequence consistent and avoids<br /> re-entering disk cleanup through the wrong path.<br /> <br /> The bug was first flagged by an experimental analysis tool we are<br /> developing for kernel memory-management bugs while analyzing<br /> v6.13-rc1. The tool is still under development and is not yet publicly<br /> available.<br /> <br /> We reproduced the bug on v7.0 with a real Ceph backend and a QEMU x86_64<br /> guest booted with KASAN and CONFIG_FAILSLAB enabled. The reproducer<br /> confines failslab injections to the __add_disk() range and injects<br /> fail-nth while mapping an RBD image through<br /> /sys/bus/rbd/add_single_major.<br /> <br /> On the unpatched kernel, fail-nth=4 reliably triggered the fault:<br /> <br /> Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI<br /> KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]<br /> CPU: 0 UID: 0 PID: 273 Comm: bash Not tainted 7.0.0-01247-gd60bc1401583 #6 PREEMPT(lazy)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014<br /> RIP: 0010:__blk_mq_free_map_and_rqs+0x8c/0x240<br /> Code: 00 00 48 8b 6b 60 41 89 f4 49 c1 e4 03 4c 01 e5 45 85 ed 0f 85 0a 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 e9 48 c1 e9 03 3c 01 00 0f 85 31 01 00 00 4c 8b 6d 00 4d 85 ed 0f 84 e2 00 00<br /> RSP: 0018:ff1100000ab0fac8 EFLAGS: 00000246<br /> RAX: dffffc0000000000 RBX: ff1100000c4806a0 RCX: 0000000000000000<br /> RDX: 0000000000000002 RSI: 0000000000000000 RDI: ff1100000c4806f4<br /> RBP: 0000000000000000 R08: 0000000000000001 R09: ffe21c000189001b<br /> R10: ff1100000c4800df R11: ff1100006cf37be0 R12: 0000000000000000<br /> R13: 0000000000000000 R14: ff1100000c480700 R15: ff1100000c480004<br /> FS: 00007f0fbe8fe740(0000) GS:ff110000e5851000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fe53473b2e0 CR3: 0000000012eef000 CR4: 00000000007516f0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> blk_mq_free_tag_set+0x77/0x460<br /> do_rbd_add+0x1446/0x2b80<br /> ? __pfx_do_rbd_add+0x10/0x10<br /> ? lock_acquire+0x18c/0x300<br /> ? find_held_lock+0x2b/0x80<br /> ? sysfs_file_kobj+0xb6/0x1b0<br /> ? __pfx_sysfs_kf_write+0x10/0x10<br /> kernfs_fop_write_iter+0x2f4/0x4a0<br /> vfs_write+0x98e/0x1000<br /> ? expand_files+0x51f/0x850<br /> ? __pfx_vfs_write+0x10/0x10<br /> ksys_write+0xf2/0x1d0<br /> ? __pfx_ksys_write+0x10/0x10<br /> do_syscall_64+0x115/0x690<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f0fbea15907<br /> Code: 10 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24<br /> RSP: 002b:00007ffe22346ea8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001<br /> RAX: ffffffffffffffda RBX: 0000000000000058 RCX: 00007f0fbea15907<br /> RDX: 0000000000000058 RSI: 0000563ace6c0ef0 RDI: 0000000000000001<br /> RBP: 0000563ace6c0ef0 R08: 0000563ace6c0ef0 R09: 6b6435726d694141<br /> R10: 5250337279762f78 R11: 0000000000000246 R12: 0000000000000058<br /> R13: 00007f0fbeb1c780 R14: ff1100000c480700 R15: ff1100000c480004<br /> <br /> <br /> With this fix applied, rerunning the reproducer over fail-nth=1..256<br /> yields no KASAN reports.<br /> <br /> [ idryomov: rename err_out_device_del -&gt; err_out_device ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: split transactions in dio completion to avoid credit exhaustion<br /> <br /> During ocfs2 dio operations, JBD2 may report warnings via following<br /> call trace:<br /> ocfs2_dio_end_io_write<br /> ocfs2_mark_extent_written<br /> ocfs2_change_extent_flag<br /> ocfs2_split_extent<br /> ocfs2_try_to_merge_extent<br /> ocfs2_extend_rotate_transaction<br /> ocfs2_extend_trans<br /> jbd2__journal_restart<br /> start_this_handle<br /> output: JBD2: kworker/6:2 wants too many credits credits:5450 rsv_credits:0 max:5449<br /> <br /> To prevent exceeding the credits limit, modify ocfs2_dio_end_io_write() to<br /> handle extents in a batch of transaction.<br /> <br /> Additionally, relocate ocfs2_del_inode_from_orphan(). The orphan inode<br /> should only be removed from the orphan list after the extent tree update<br /> is complete. This ensures that if a crash occurs in the middle of extent<br /> tree updates, we won&amp;#39;t leave stale blocks beyond EOF.<br /> <br /> This patch also changes the logic for updating the inode size and removing<br /> orphan, making it similar to ext4_dio_write_end_io(). Both operations are<br /> performed only when everything looks good.<br /> <br /> Finally, thanks to Jans and Joseph for providing the bug fix prototype and<br /> suggestions.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: acomp - fix wrong pointer stored by acomp_save_req()<br /> <br /> acomp_save_req() stores &amp;req-&gt;chain in req-&gt;base.data. When<br /> acomp_reqchain_done() is invoked on asynchronous completion, it receives<br /> &amp;req-&gt;chain as the data argument but casts it directly to struct<br /> acomp_req. Since data points to the chain member, all subsequent field<br /> accesses are at a wrong offset, resulting in memory corruption.<br /> <br /> The issue occurs when an asynchronous hardware implementation, such as<br /> the QAT driver, completes a request that uses the DMA virtual address<br /> interface (e.g. acomp_request_set_src_dma()). This combination causes<br /> crypto_acomp_compress() to enter the acomp_do_req_chain() path, which<br /> sets acomp_reqchain_done() as the completion callback via<br /> acomp_save_req().<br /> <br /> With KASAN enabled, this manifests as a general protection fault in<br /> acomp_reqchain_done():<br /> <br /> general protection fault, probably for non-canonical address 0xe000040000000000<br /> KASAN: probably user-memory-access in range [0x0000400000000000-0x0000400000000007]<br /> RIP: 0010:acomp_reqchain_done+0x15b/0x4e0<br /> Call Trace:<br /> <br /> qat_comp_alg_callback+0x5d/0xa0 [intel_qat]<br /> adf_ring_response_handler+0x376/0x8b0 [intel_qat]<br /> adf_response_handler+0x60/0x170 [intel_qat]<br /> tasklet_action_common+0x223/0x820<br /> handle_softirqs+0x1ab/0x640<br /> <br /> <br /> Fix this by storing the request itself in req-&gt;base.data instead of<br /> &amp;req-&gt;chain, so that acomp_reqchain_done() receives the correct pointer.<br /> Simplify acomp_restore_req() accordingly to access req-&gt;chain directly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: SVM: Inject #UD for INVLPGA if EFER.SVME=0<br /> <br /> INVLPGA should cause a #UD when EFER.SVME is not set. Add a check to<br /> properly inject #UD when EFER.SVME=0.<br /> <br /> [sean: tag for stable@]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: fix resource leaks on device setup failure<br /> <br /> Make sure to call controller cleanup() if spi_setup() fails while<br /> registering a device to avoid leaking any resources allocated by<br /> setup().