Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: usb-audio: Fix out-of-bounds read in snd_usb_get_audioformat_uac3()<br /> <br /> In snd_usb_get_audioformat_uac3(), the length value returned from<br /> snd_usb_ctl_msg() is used directly for memory allocation without<br /> validation. This length is controlled by the USB device.<br /> <br /> The allocated buffer is cast to a uac3_cluster_header_descriptor<br /> and its fields are accessed without verifying that the buffer<br /> is large enough. If the device returns a smaller than expected<br /> length, this leads to an out-of-bounds read.<br /> <br /> Add a length check to ensure the buffer is large enough for<br /> uac3_cluster_header_descriptor.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_core: Fix use-after-free in vhci_flush()<br /> <br /> syzbot reported use-after-free in vhci_flush() without repro. [0]<br /> <br /> From the splat, a thread close()d a vhci file descriptor while<br /> its device was being used by iotcl() on another thread.<br /> <br /> Once the last fd refcnt is released, vhci_release() calls<br /> hci_unregister_dev(), hci_free_dev(), and kfree() for struct<br /> vhci_data, which is set to hci_dev-&gt;dev-&gt;driver_data.<br /> <br /> The problem is that there is no synchronisation after unlinking<br /> hdev from hci_dev_list in hci_unregister_dev(). There might be<br /> another thread still accessing the hdev which was fetched before<br /> the unlink operation.<br /> <br /> We can use SRCU for such synchronisation.<br /> <br /> Let&amp;#39;s run hci_dev_reset() under SRCU and wait for its completion<br /> in hci_unregister_dev().<br /> <br /> Another option would be to restore hci_dev-&gt;destruct(), which was<br /> removed in commit 587ae086f6e4 ("Bluetooth: Remove unused<br /> hci-destruct cb"). However, this would not be a good solution, as<br /> we should not run hci_unregister_dev() while there are in-flight<br /> ioctl() requests, which could lead to another data-race KCSAN splat.<br /> <br /> Note that other drivers seem to have the same problem, for exmaple,<br /> virtbt_remove().<br /> <br /> [0]:<br /> BUG: KASAN: slab-use-after-free in skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline]<br /> BUG: KASAN: slab-use-after-free in skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937<br /> Read of size 8 at addr ffff88807cb8d858 by task syz.1.219/6718<br /> <br /> CPU: 1 UID: 0 PID: 6718 Comm: syz.1.219 Not tainted 6.16.0-rc1-syzkaller-00196-g08207f42d3ff #0 PREEMPT(full)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:408 [inline]<br /> print_report+0xd2/0x2b0 mm/kasan/report.c:521<br /> kasan_report+0x118/0x150 mm/kasan/report.c:634<br /> skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline]<br /> skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937<br /> skb_queue_purge include/linux/skbuff.h:3368 [inline]<br /> vhci_flush+0x44/0x50 drivers/bluetooth/hci_vhci.c:69<br /> hci_dev_do_reset net/bluetooth/hci_core.c:552 [inline]<br /> hci_dev_reset+0x420/0x5c0 net/bluetooth/hci_core.c:592<br /> sock_do_ioctl+0xd9/0x300 net/socket.c:1190<br /> sock_ioctl+0x576/0x790 net/socket.c:1311<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:907 [inline]<br /> __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7fcf5b98e929<br /> Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007fcf5c7b9038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> RAX: ffffffffffffffda RBX: 00007fcf5bbb6160 RCX: 00007fcf5b98e929<br /> RDX: 0000000000000000 RSI: 00000000400448cb RDI: 0000000000000009<br /> RBP: 00007fcf5ba10b39 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 0000000000000000 R14: 00007fcf5bbb6160 R15: 00007ffd6353d528<br /> <br /> <br /> Allocated by task 6535:<br /> kasan_save_stack mm/kasan/common.c:47 [inline]<br /> kasan_save_track+0x3e/0x80 mm/kasan/common.c:68<br /> poison_kmalloc_redzone mm/kasan/common.c:377 [inline]<br /> __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394<br /> kasan_kmalloc include/linux/kasan.h:260 [inline]<br /> __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359<br /> kmalloc_noprof include/linux/slab.h:905 [inline]<br /> kzalloc_noprof include/linux/slab.h:1039 [inline]<br /> vhci_open+0x57/0x360 drivers/bluetooth/hci_vhci.c:635<br /> misc_open+0x2bc/0x330 drivers/char/misc.c:161<br /> chrdev_open+0x4c9/0x5e0 fs/char_dev.c:414<br /> do_dentry_open+0xdf0/0x1970 fs/open.c:964<br /> vfs_open+0x3b/0x340 fs/open.c:1094<br /> do_open fs/namei.c:3887 [inline]<br /> path_openat+0x2ee5/0x3830 fs/name<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> atm: clip: prevent NULL deref in clip_push()<br /> <br /> Blamed commit missed that vcc_destroy_socket() calls<br /> clip_push() with a NULL skb.<br /> <br /> If clip_devs is NULL, clip_push() then crashes when reading<br /> skb-&gt;truesize.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cxl/ras: Fix CPER handler device confusion<br /> <br /> By inspection, cxl_cper_handle_prot_err() is making a series of fragile<br /> assumptions that can lead to crashes:<br /> <br /> 1/ It assumes that endpoints identified in the record are a CXL-type-3<br /> device, nothing guarantees that.<br /> <br /> 2/ It assumes that the device is bound to the cxl_pci driver, nothing<br /> guarantees that.<br /> <br /> 3/ Minor, it holds the device lock over the switch-port tracing for no<br /> reason as the trace is 100% generated from data in the record.<br /> <br /> Correct those by checking that the PCIe endpoint parents a cxl_memdev<br /> before assuming the format of the driver data, and move the lock to where<br /> it is required. Consequently this also makes the implementation ready for<br /> CXL accelerators that are not bound to cxl_pci.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: wacom: fix crash in wacom_aes_battery_handler()<br /> <br /> Commit fd2a9b29dc9c ("HID: wacom: Remove AES power_supply after extended<br /> inactivity") introduced wacom_aes_battery_handler() which is scheduled<br /> as a delayed work (aes_battery_work).<br /> <br /> In wacom_remove(), aes_battery_work is not canceled. Consequently, if<br /> the device is removed while aes_battery_work is still pending, then hard<br /> crashes or "Oops: general protection fault..." are experienced when<br /> wacom_aes_battery_handler() is finally called. E.g., this happens with<br /> built-in USB devices after resume from hibernate when aes_battery_work<br /> was still pending at the time of hibernation.<br /> <br /> So, take care to cancel aes_battery_work in wacom_remove().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Add sanity checks for drm_edid_raw()<br /> <br /> When EDID is retrieved via drm_edid_raw(), it doesn&amp;#39;t guarantee to<br /> return proper EDID bytes the caller wants: it may be either NULL (that<br /> leads to an Oops) or with too long bytes over the fixed size raw_edid<br /> array (that may lead to memory corruption). The latter was reported<br /> actually when connected with a bad adapter.<br /> <br /> Add sanity checks for drm_edid_raw() to address the above corner<br /> cases, and return EDID_BAD_INPUT accordingly.<br /> <br /> (cherry picked from commit 648d3f4d209725d51900d6a3ed46b7b600140cdf)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> lib/group_cpus: fix NULL pointer dereference from group_cpus_evenly()<br /> <br /> While testing null_blk with configfs, echo 0 &gt; poll_queues will trigger<br /> following panic:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000010<br /> Oops: Oops: 0000 [#1] SMP NOPTI<br /> CPU: 27 UID: 0 PID: 920 Comm: bash Not tainted 6.15.0-02023-gadbdb95c8696-dirty #1238 PREEMPT(undef)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014<br /> RIP: 0010:__bitmap_or+0x48/0x70<br /> Call Trace:<br /> <br /> __group_cpus_evenly+0x822/0x8c0<br /> group_cpus_evenly+0x2d9/0x490<br /> blk_mq_map_queues+0x1e/0x110<br /> null_map_queues+0xc9/0x170 [null_blk]<br /> blk_mq_update_queue_map+0xdb/0x160<br /> blk_mq_update_nr_hw_queues+0x22b/0x560<br /> nullb_update_nr_hw_queues+0x71/0xf0 [null_blk]<br /> nullb_device_poll_queues_store+0xa4/0x130 [null_blk]<br /> configfs_write_iter+0x109/0x1d0<br /> vfs_write+0x26e/0x6f0<br /> ksys_write+0x79/0x180<br /> __x64_sys_write+0x1d/0x30<br /> x64_sys_call+0x45c4/0x45f0<br /> do_syscall_64+0xa5/0x240<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> Root cause is that numgrps is set to 0, and ZERO_SIZE_PTR is returned from<br /> kcalloc(), and later ZERO_SIZE_PTR will be deferenced.<br /> <br /> Fix the problem by checking numgrps first in group_cpus_evenly(), and<br /> return NULL directly if numgrps is zero.<br /> <br /> [yukuai3@huawei.com: also fix the non-SMP version]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/rsrc: fix folio unpinning<br /> <br /> syzbot complains about an unmapping failure:<br /> <br /> [ 108.070381][ T14] kernel BUG at mm/gup.c:71!<br /> [ 108.070502][ T14] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP<br /> [ 108.123672][ T14] Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20250221-8.fc42 02/21/2025<br /> [ 108.127458][ T14] Workqueue: iou_exit io_ring_exit_work<br /> [ 108.174205][ T14] Call trace:<br /> [ 108.175649][ T14] sanity_check_pinned_pages+0x7cc/0x7d0 (P)<br /> [ 108.178138][ T14] unpin_user_page+0x80/0x10c<br /> [ 108.180189][ T14] io_release_ubuf+0x84/0xf8<br /> [ 108.182196][ T14] io_free_rsrc_node+0x250/0x57c<br /> [ 108.184345][ T14] io_rsrc_data_free+0x148/0x298<br /> [ 108.186493][ T14] io_sqe_buffers_unregister+0x84/0xa0<br /> [ 108.188991][ T14] io_ring_ctx_free+0x48/0x480<br /> [ 108.191057][ T14] io_ring_exit_work+0x764/0x7d8<br /> [ 108.193207][ T14] process_one_work+0x7e8/0x155c<br /> [ 108.195431][ T14] worker_thread+0x958/0xed8<br /> [ 108.197561][ T14] kthread+0x5fc/0x75c<br /> [ 108.199362][ T14] ret_from_fork+0x10/0x20<br /> <br /> We can pin a tail page of a folio, but then io_uring will try to unpin<br /> the head page of the folio. While it should be fine in terms of keeping<br /> the page actually alive, mm folks say it&amp;#39;s wrong and triggers a debug<br /> warning. Use unpin_user_folio() instead of unpin_user_page*.<br /> <br /> [axboe: adapt to current tree, massage commit message]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/pkey: Prevent overflow in size calculation for memdup_user()<br /> <br /> Number of apqn target list entries contained in &amp;#39;nr_apqns&amp;#39; variable is<br /> determined by userspace via an ioctl call so the result of the product in<br /> calculation of size passed to memdup_user() may overflow.<br /> <br /> In this case the actual size of the allocated area and the value<br /> describing it won&amp;#39;t be in sync leading to various types of unpredictable<br /> behaviour later.<br /> <br /> Use a proper memdup_array_user() helper which returns an error if an<br /> overflow is detected. Note that it is different from when nr_apqns is<br /> initially zero - that case is considered valid and should be handled in<br /> subsequent pkey_handler implementations.<br /> <br /> Found by Linux Verification Center (linuxtesting.org).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/shmem, swap: fix softlockup with mTHP swapin<br /> <br /> Following softlockup can be easily reproduced on my test machine with:<br /> <br /> echo always &gt; /sys/kernel/mm/transparent_hugepage/hugepages-64kB/enabled<br /> swapon /dev/zram0 # zram0 is a 48G swap device<br /> mkdir -p /sys/fs/cgroup/memory/test<br /> echo 1G &gt; /sys/fs/cgroup/test/memory.max<br /> echo $BASHPID &gt; /sys/fs/cgroup/test/cgroup.procs<br /> while true; do<br /> dd if=/dev/zero of=/tmp/test.img bs=1M count=5120<br /> cat /tmp/test.img &gt; /dev/null<br /> rm /tmp/test.img<br /> done<br /> <br /> Then after a while:<br /> watchdog: BUG: soft lockup - CPU#0 stuck for 763s! [cat:5787]<br /> Modules linked in: zram virtiofs<br /> CPU: 0 UID: 0 PID: 5787 Comm: cat Kdump: loaded Tainted: G L 6.15.0.orig-gf3021d9246bc-dirty #118 PREEMPT(voluntary)·<br /> Tainted: [L]=SOFTLOCKUP<br /> Hardware name: Red Hat KVM/RHEL-AV, BIOS 0.0.0 02/06/2015<br /> RIP: 0010:mpol_shared_policy_lookup+0xd/0x70<br /> Code: e9 b8 b4 ff ff 31 c0 c3 cc cc cc cc 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 41 54 55 53 8b 1f 48 85 db 74 41 4c 8d 67 08 48 89 fb 48 89 f5 4c 89 e7 e8<br /> RSP: 0018:ffffc90002b1fc28 EFLAGS: 00000202<br /> RAX: 00000000001c20ca RBX: 0000000000724e1e RCX: 0000000000000001<br /> RDX: ffff888118e214c8 RSI: 0000000000057d42 RDI: ffff888118e21518<br /> RBP: 000000000002bec8 R08: 0000000000000001 R09: 0000000000000000<br /> R10: 0000000000000bf4 R11: 0000000000000000 R12: 0000000000000001<br /> R13: 00000000001c20ca R14: 00000000001c20ca R15: 0000000000000000<br /> FS: 00007f03f995c740(0000) GS:ffff88a07ad9a000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f03f98f1000 CR3: 0000000144626004 CR4: 0000000000770eb0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> shmem_alloc_folio+0x31/0xc0<br /> shmem_swapin_folio+0x309/0xcf0<br /> ? filemap_get_entry+0x117/0x1e0<br /> ? xas_load+0xd/0xb0<br /> ? filemap_get_entry+0x101/0x1e0<br /> shmem_get_folio_gfp+0x2ed/0x5b0<br /> shmem_file_read_iter+0x7f/0x2e0<br /> vfs_read+0x252/0x330<br /> ksys_read+0x68/0xf0<br /> do_syscall_64+0x4c/0x1c0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7f03f9a46991<br /> Code: 00 48 8b 15 81 14 10 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd e8 20 ad 01 00 f3 0f 1e fa 80 3d 35 97 10 00 00 74 13 31 c0 0f 05 3d 00 f0 ff ff 77 4f c3 66 0f 1f 44 00 00 55 48 89 e5 48 83 ec<br /> RSP: 002b:00007fff3c52bd28 EFLAGS: 00000246 ORIG_RAX: 0000000000000000<br /> RAX: ffffffffffffffda RBX: 0000000000040000 RCX: 00007f03f9a46991<br /> RDX: 0000000000040000 RSI: 00007f03f98ba000 RDI: 0000000000000003<br /> RBP: 00007fff3c52bd50 R08: 0000000000000000 R09: 00007f03f9b9a380<br /> R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000040000<br /> R13: 00007f03f98ba000 R14: 0000000000000003 R15: 0000000000000000<br /> <br /> <br /> The reason is simple, readahead brought some order 0 folio in swap cache,<br /> and the swapin mTHP folio being allocated is in conflict with it, so<br /> swapcache_prepare fails and causes shmem_swap_alloc_folio to return<br /> -EEXIST, and shmem simply retries again and again causing this loop.<br /> <br /> Fix it by applying a similar fix for anon mTHP swapin.<br /> <br /> The performance change is very slight, time of swapin 10g zero folios<br /> with shmem (test for 12 times):<br /> Before: 2.47s<br /> After: 2.48s<br /> <br /> [kasong@tencent.com: add comment]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: userfaultfd: fix race of userfaultfd_move and swap cache<br /> <br /> This commit fixes two kinds of races, they may have different results:<br /> <br /> Barry reported a BUG_ON in commit c50f8e6053b0, we may see the same<br /> BUG_ON if the filemap lookup returned NULL and folio is added to swap<br /> cache after that.<br /> <br /> If another kind of race is triggered (folio changed after lookup) we<br /> may see RSS counter is corrupted:<br /> <br /> [ 406.893936] BUG: Bad rss-counter state mm:ffff0000c5a9ddc0<br /> type:MM_ANONPAGES val:-1<br /> [ 406.894071] BUG: Bad rss-counter state mm:ffff0000c5a9ddc0<br /> type:MM_SHMEMPAGES val:1<br /> <br /> Because the folio is being accounted to the wrong VMA.<br /> <br /> I&amp;#39;m not sure if there will be any data corruption though, seems no. <br /> The issues above are critical already.<br /> <br /> <br /> On seeing a swap entry PTE, userfaultfd_move does a lockless swap cache<br /> lookup, and tries to move the found folio to the faulting vma. Currently,<br /> it relies on checking the PTE value to ensure that the moved folio still<br /> belongs to the src swap entry and that no new folio has been added to the<br /> swap cache, which turns out to be unreliable.<br /> <br /> While working and reviewing the swap table series with Barry, following<br /> existing races are observed and reproduced [1]:<br /> <br /> In the example below, move_pages_pte is moving src_pte to dst_pte, where<br /> src_pte is a swap entry PTE holding swap entry S1, and S1 is not in the<br /> swap cache:<br /> <br /> CPU1 CPU2<br /> userfaultfd_move<br /> move_pages_pte()<br /> entry = pte_to_swp_entry(orig_src_pte);<br /> // Here it got entry = S1<br /> ... ...<br /> <br /> // folio A is a new allocated folio<br /> // and get installed into src_pte<br /> <br /> // src_pte now points to folio A, S1<br /> // has swap count == 0, it can be freed<br /> // by folio_swap_swap or swap<br /> // allocator&amp;#39;s reclaim.<br /> <br /> // folio B is a folio in another VMA.<br /> <br /> // S1 is freed, folio B can use it<br /> // for swap out with no problem.<br /> ...<br /> folio = filemap_get_folio(S1)<br /> // Got folio B here !!!<br /> ... ...<br /> <br /> // Now S1 is free to be used again.<br /> <br /> // Now src_pte is a swap entry PTE<br /> // holding S1 again.<br /> folio_trylock(folio)<br /> move_swap_pte<br /> double_pt_lock<br /> is_pte_pages_stable<br /> // Check passed because src_pte == S1<br /> folio_move_anon_rmap(...)<br /> // Moved invalid folio B here !!!<br /> <br /> The race window is very short and requires multiple collisions of multiple<br /> rare events, so it&amp;#39;s very unlikely to happen, but with a deliberately<br /> constructed reproducer and increased time window, it can be reproduced<br /> easily.<br /> <br /> This can be fixed by checking if the folio returned by filemap is the<br /> valid swap cache folio after acquiring the folio lock.<br /> <br /> Another similar race is possible: filemap_get_folio may return NULL, but<br /> folio (A) could be swapped in and then swapped out again using the same<br /> swap entry after the lookup. In such a case, folio (A) may remain in the<br /> swap cache, so it must be moved too:<br /> <br /> CPU1 CPU2<br /> userfaultfd_move<br /> move_pages_pte()<br /> entry = pte_to_swp_entry(orig_src_pte);<br /> // Here it got entry = S1, and S1 is not in swap cache<br /> folio = filemap_get<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix invalid inode pointer dereferences during log replay<br /> <br /> In a few places where we call read_one_inode(), if we get a NULL pointer<br /> we end up jumping into an error path, or fallthrough in case of<br /> __add_inode_ref(), where we then do something like this:<br /> <br /> iput(&amp;inode-&gt;vfs_inode);<br /> <br /> which results in an invalid inode pointer that triggers an invalid memory<br /> access, resulting in a crash.<br /> <br /> Fix this by making sure we don&amp;#39;t do such dereferences.