Vulnerabilities

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 /> 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 /> smb: client: fix potential deadlock when reconnecting channels<br /> <br /> Fix cifs_signal_cifsd_for_reconnect() to take the correct lock order<br /> and prevent the following deadlock from happening<br /> <br /> ======================================================<br /> WARNING: possible circular locking dependency detected<br /> 6.16.0-rc3-build2+ #1301 Tainted: G S W<br /> ------------------------------------------------------<br /> cifsd/6055 is trying to acquire lock:<br /> ffff88810ad56038 (&amp;tcp_ses-&gt;srv_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x134/0x200<br /> <br /> but task is already holding lock:<br /> ffff888119c64330 (&amp;ret_buf-&gt;chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200<br /> <br /> which lock already depends on the new lock.<br /> <br /> the existing dependency chain (in reverse order) is:<br /> <br /> -&gt; #2 (&amp;ret_buf-&gt;chan_lock){+.+.}-{3:3}:<br /> validate_chain+0x1cf/0x270<br /> __lock_acquire+0x60e/0x780<br /> lock_acquire.part.0+0xb4/0x1f0<br /> _raw_spin_lock+0x2f/0x40<br /> cifs_setup_session+0x81/0x4b0<br /> cifs_get_smb_ses+0x771/0x900<br /> cifs_mount_get_session+0x7e/0x170<br /> cifs_mount+0x92/0x2d0<br /> cifs_smb3_do_mount+0x161/0x460<br /> smb3_get_tree+0x55/0x90<br /> vfs_get_tree+0x46/0x180<br /> do_new_mount+0x1b0/0x2e0<br /> path_mount+0x6ee/0x740<br /> do_mount+0x98/0xe0<br /> __do_sys_mount+0x148/0x180<br /> do_syscall_64+0xa4/0x260<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> -&gt; #1 (&amp;ret_buf-&gt;ses_lock){+.+.}-{3:3}:<br /> validate_chain+0x1cf/0x270<br /> __lock_acquire+0x60e/0x780<br /> lock_acquire.part.0+0xb4/0x1f0<br /> _raw_spin_lock+0x2f/0x40<br /> cifs_match_super+0x101/0x320<br /> sget+0xab/0x270<br /> cifs_smb3_do_mount+0x1e0/0x460<br /> smb3_get_tree+0x55/0x90<br /> vfs_get_tree+0x46/0x180<br /> do_new_mount+0x1b0/0x2e0<br /> path_mount+0x6ee/0x740<br /> do_mount+0x98/0xe0<br /> __do_sys_mount+0x148/0x180<br /> do_syscall_64+0xa4/0x260<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> -&gt; #0 (&amp;tcp_ses-&gt;srv_lock){+.+.}-{3:3}:<br /> check_noncircular+0x95/0xc0<br /> check_prev_add+0x115/0x2f0<br /> validate_chain+0x1cf/0x270<br /> __lock_acquire+0x60e/0x780<br /> lock_acquire.part.0+0xb4/0x1f0<br /> _raw_spin_lock+0x2f/0x40<br /> cifs_signal_cifsd_for_reconnect+0x134/0x200<br /> __cifs_reconnect+0x8f/0x500<br /> cifs_handle_standard+0x112/0x280<br /> cifs_demultiplex_thread+0x64d/0xbc0<br /> kthread+0x2f7/0x310<br /> ret_from_fork+0x2a/0x230<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> other info that might help us debug this:<br /> <br /> Chain exists of:<br /> &amp;tcp_ses-&gt;srv_lock --&gt; &amp;ret_buf-&gt;ses_lock --&gt; &amp;ret_buf-&gt;chan_lock<br /> <br /> Possible unsafe locking scenario:<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> lock(&amp;ret_buf-&gt;chan_lock);<br /> lock(&amp;ret_buf-&gt;ses_lock);<br /> lock(&amp;ret_buf-&gt;chan_lock);<br /> lock(&amp;tcp_ses-&gt;srv_lock);<br /> <br /> *** DEADLOCK ***<br /> <br /> 3 locks held by cifsd/6055:<br /> #0: ffffffff857de398 (&amp;cifs_tcp_ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x7b/0x200<br /> #1: ffff888119c64060 (&amp;ret_buf-&gt;ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x9c/0x200<br /> #2: ffff888119c64330 (&amp;ret_buf-&gt;chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> userns and mnt_idmap leak in open_tree_attr(2)<br /> <br /> Once want_mount_setattr() has returned a positive, it does require<br /> finish_mount_kattr() to release -&gt;mnt_userns. Failing do_mount_setattr()<br /> does not change that.<br /> <br /> As the result, we can end up leaking userns and possibly mnt_idmap as<br /> well.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bridge: mcast: Fix use-after-free during router port configuration<br /> <br /> The bridge maintains a global list of ports behind which a multicast<br /> router resides. The list is consulted during forwarding to ensure<br /> multicast packets are forwarded to these ports even if the ports are not<br /> member in the matching MDB entry.<br /> <br /> When per-VLAN multicast snooping is enabled, the per-port multicast<br /> context is disabled on each port and the port is removed from the global<br /> router port list:<br /> <br /> # ip link add name br1 up type bridge vlan_filtering 1 mcast_snooping 1<br /> # ip link add name dummy1 up master br1 type dummy<br /> # ip link set dev dummy1 type bridge_slave mcast_router 2<br /> $ bridge -d mdb show | grep router<br /> router ports on br1: dummy1<br /> # ip link set dev br1 type bridge mcast_vlan_snooping 1<br /> $ bridge -d mdb show | grep router<br /> <br /> However, the port can be re-added to the global list even when per-VLAN<br /> multicast snooping is enabled:<br /> <br /> # ip link set dev dummy1 type bridge_slave mcast_router 0<br /> # ip link set dev dummy1 type bridge_slave mcast_router 2<br /> $ bridge -d mdb show | grep router<br /> router ports on br1: dummy1<br /> <br /> Since commit 4b30ae9adb04 ("net: bridge: mcast: re-implement<br /> br_multicast_{enable, disable}_port functions"), when per-VLAN multicast<br /> snooping is enabled, multicast disablement on a port will disable the<br /> per-{port, VLAN} multicast contexts and not the per-port one. As a<br /> result, a port will remain in the global router port list even after it<br /> is deleted. This will lead to a use-after-free [1] when the list is<br /> traversed (when adding a new port to the list, for example):<br /> <br /> # ip link del dev dummy1<br /> # ip link add name dummy2 up master br1 type dummy<br /> # ip link set dev dummy2 type bridge_slave mcast_router 2<br /> <br /> Similarly, stale entries can also be found in the per-VLAN router port<br /> list. When per-VLAN multicast snooping is disabled, the per-{port, VLAN}<br /> contexts are disabled on each port and the port is removed from the<br /> per-VLAN router port list:<br /> <br /> # ip link add name br1 up type bridge vlan_filtering 1 mcast_snooping 1 mcast_vlan_snooping 1<br /> # ip link add name dummy1 up master br1 type dummy<br /> # bridge vlan add vid 2 dev dummy1<br /> # bridge vlan global set vid 2 dev br1 mcast_snooping 1<br /> # bridge vlan set vid 2 dev dummy1 mcast_router 2<br /> $ bridge vlan global show dev br1 vid 2 | grep router<br /> router ports: dummy1<br /> # ip link set dev br1 type bridge mcast_vlan_snooping 0<br /> $ bridge vlan global show dev br1 vid 2 | grep router<br /> <br /> However, the port can be re-added to the per-VLAN list even when<br /> per-VLAN multicast snooping is disabled:<br /> <br /> # bridge vlan set vid 2 dev dummy1 mcast_router 0<br /> # bridge vlan set vid 2 dev dummy1 mcast_router 2<br /> $ bridge vlan global show dev br1 vid 2 | grep router<br /> router ports: dummy1<br /> <br /> When the VLAN is deleted from the port, the per-{port, VLAN} multicast<br /> context will not be disabled since multicast snooping is not enabled<br /> on the VLAN. As a result, the port will remain in the per-VLAN router<br /> port list even after it is no longer member in the VLAN. This will lead<br /> to a use-after-free [2] when the list is traversed (when adding a new<br /> port to the list, for example):<br /> <br /> # ip link add name dummy2 up master br1 type dummy<br /> # bridge vlan add vid 2 dev dummy2<br /> # bridge vlan del vid 2 dev dummy1<br /> # bridge vlan set vid 2 dev dummy2 mcast_router 2<br /> <br /> Fix these issues by removing the port from the relevant (global or<br /> per-VLAN) router port list in br_multicast_port_ctx_deinit(). The<br /> function is invoked during port deletion with the per-port multicast<br /> context and during VLAN deletion with the per-{port, VLAN} multicast<br /> context.<br /> <br /> Note that deleting the multicast router timer is not enough as it only<br /> takes care of the temporary multicast router states (1 or 3) and not the<br /> permanent one (2).<br /> <br /> [1]<br /> BUG: KASAN: slab-out-of-bounds in br_multicast_add_router.part.0+0x3f1/0x560<br /> Write of size 8 at addr ffff888004a67328 by task ip/384<br /> [...]<br /> Call Trace:<br /> <br /> dump_stack<br /> ---truncated---

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> atm: Release atm_dev_mutex after removing procfs in atm_dev_deregister().<br /> <br /> syzbot reported a warning below during atm_dev_register(). [0]<br /> <br /> Before creating a new device and procfs/sysfs for it, atm_dev_register()<br /> looks up a duplicated device by __atm_dev_lookup(). These operations are<br /> done under atm_dev_mutex.<br /> <br /> However, when removing a device in atm_dev_deregister(), it releases the<br /> mutex just after removing the device from the list that __atm_dev_lookup()<br /> iterates over.<br /> <br /> So, there will be a small race window where the device does not exist on<br /> the device list but procfs/sysfs are still not removed, triggering the<br /> splat.<br /> <br /> Let&amp;#39;s hold the mutex until procfs/sysfs are removed in<br /> atm_dev_deregister().<br /> <br /> [0]:<br /> proc_dir_entry &amp;#39;atm/atmtcp:0&amp;#39; already registered<br /> WARNING: CPU: 0 PID: 5919 at fs/proc/generic.c:377 proc_register+0x455/0x5f0 fs/proc/generic.c:377<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 5919 Comm: syz-executor284 Not tainted 6.16.0-rc2-syzkaller-00047-g52da431bf03b #0 PREEMPT(full)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025<br /> RIP: 0010:proc_register+0x455/0x5f0 fs/proc/generic.c:377<br /> Code: 48 89 f9 48 c1 e9 03 80 3c 01 00 0f 85 a2 01 00 00 48 8b 44 24 10 48 c7 c7 20 c0 c2 8b 48 8b b0 d8 00 00 00 e8 0c 02 1c ff 90 0b 90 90 48 c7 c7 80 f2 82 8e e8 0b de 23 09 48 8b 4c 24 28 48<br /> RSP: 0018:ffffc9000466fa30 EFLAGS: 00010282<br /> RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817ae248<br /> RDX: ffff888026280000 RSI: ffffffff817ae255 RDI: 0000000000000001<br /> RBP: ffff8880232bed48 R08: 0000000000000001 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000001 R12: ffff888076ed2140<br /> R13: dffffc0000000000 R14: ffff888078a61340 R15: ffffed100edda444<br /> FS: 00007f38b3b0c6c0(0000) GS:ffff888124753000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f38b3bdf953 CR3: 0000000076d58000 CR4: 00000000003526f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> proc_create_data+0xbe/0x110 fs/proc/generic.c:585<br /> atm_proc_dev_register+0x112/0x1e0 net/atm/proc.c:361<br /> atm_dev_register+0x46d/0x890 net/atm/resources.c:113<br /> atmtcp_create+0x77/0x210 drivers/atm/atmtcp.c:369<br /> atmtcp_attach drivers/atm/atmtcp.c:403 [inline]<br /> atmtcp_ioctl+0x2f9/0xd60 drivers/atm/atmtcp.c:464<br /> do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159<br /> sock_do_ioctl+0x115/0x280 net/socket.c:1190<br /> sock_ioctl+0x227/0x6b0 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 fs/ioctl.c:893 [inline]<br /> __x64_sys_ioctl+0x18b/0x210 fs/ioctl.c:893<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f38b3b74459<br /> Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 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 b0 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007f38b3b0c198 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> RAX: ffffffffffffffda RBX: 00007f38b3bfe318 RCX: 00007f38b3b74459<br /> RDX: 0000000000000000 RSI: 0000000000006180 RDI: 0000000000000005<br /> RBP: 00007f38b3bfe310 R08: 65732f636f72702f R09: 65732f636f72702f<br /> R10: 65732f636f72702f R11: 0000000000000246 R12: 00007f38b3bcb0ac<br /> R13: 00007f38b3b0c1a0 R14: 0000200000000200 R15: 00007f38b3bcb03b<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bnxt: properly flush XDP redirect lists<br /> <br /> We encountered following crash when testing a XDP_REDIRECT feature<br /> in production:<br /> <br /> [56251.579676] list_add corruption. next-&gt;prev should be prev (ffff93120dd40f30), but was ffffb301ef3a6740. (next=ffff93120dd<br /> 40f30).<br /> [56251.601413] ------------[ cut here ]------------<br /> [56251.611357] kernel BUG at lib/list_debug.c:29!<br /> [56251.621082] Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI<br /> [56251.632073] CPU: 111 UID: 0 PID: 0 Comm: swapper/111 Kdump: loaded Tainted: P O 6.12.33-cloudflare-2025.6.<br /> 3 #1<br /> [56251.653155] Tainted: [P]=PROPRIETARY_MODULE, [O]=OOT_MODULE<br /> [56251.663877] Hardware name: MiTAC GC68B-B8032-G11P6-GPU/S8032GM-HE-CFR, BIOS V7.020.B10-sig 01/22/2025<br /> [56251.682626] RIP: 0010:__list_add_valid_or_report+0x4b/0xa0<br /> [56251.693203] Code: 0e 48 c7 c7 68 e7 d9 97 e8 42 16 fe ff 0f 0b 48 8b 52 08 48 39 c2 74 14 48 89 f1 48 c7 c7 90 e7 d9 97 48<br /> 89 c6 e8 25 16 fe ff 0b 4c 8b 02 49 39 f0 74 14 48 89 d1 48 c7 c7 e8 e7 d9 97 4c 89<br /> [56251.725811] RSP: 0018:ffff93120dd40b80 EFLAGS: 00010246<br /> [56251.736094] RAX: 0000000000000075 RBX: ffffb301e6bba9d8 RCX: 0000000000000000<br /> [56251.748260] RDX: 0000000000000000 RSI: ffff9149afda0b80 RDI: ffff9149afda0b80<br /> [56251.760349] RBP: ffff9131e49c8000 R08: 0000000000000000 R09: ffff93120dd40a18<br /> [56251.772382] R10: ffff9159cf2ce1a8 R11: 0000000000000003 R12: ffff911a80850000<br /> [56251.784364] R13: ffff93120fbc7000 R14: 0000000000000010 R15: ffff9139e7510e40<br /> [56251.796278] FS: 0000000000000000(0000) GS:ffff9149afd80000(0000) knlGS:0000000000000000<br /> [56251.809133] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [56251.819561] CR2: 00007f5e85e6f300 CR3: 00000038b85e2006 CR4: 0000000000770ef0<br /> [56251.831365] PKRU: 55555554<br /> [56251.838653] Call Trace:<br /> [56251.845560] <br /> [56251.851943] cpu_map_enqueue.cold+0x5/0xa<br /> [56251.860243] xdp_do_redirect+0x2d9/0x480<br /> [56251.868388] bnxt_rx_xdp+0x1d8/0x4c0 [bnxt_en]<br /> [56251.877028] bnxt_rx_pkt+0x5f7/0x19b0 [bnxt_en]<br /> [56251.885665] ? cpu_max_write+0x1e/0x100<br /> [56251.893510] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [56251.902276] __bnxt_poll_work+0x190/0x340 [bnxt_en]<br /> [56251.911058] bnxt_poll+0xab/0x1b0 [bnxt_en]<br /> [56251.919041] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [56251.927568] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [56251.935958] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [56251.944250] __napi_poll+0x2b/0x160<br /> [56251.951155] bpf_trampoline_6442548651+0x79/0x123<br /> [56251.959262] __napi_poll+0x5/0x160<br /> [56251.966037] net_rx_action+0x3d2/0x880<br /> [56251.973133] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [56251.981265] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [56251.989262] ? __hrtimer_run_queues+0x162/0x2a0<br /> [56251.996967] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [56252.004875] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [56252.012673] ? bnxt_msix+0x62/0x70 [bnxt_en]<br /> [56252.019903] handle_softirqs+0xcf/0x270<br /> [56252.026650] irq_exit_rcu+0x67/0x90<br /> [56252.032933] common_interrupt+0x85/0xa0<br /> [56252.039498] <br /> [56252.044246] <br /> [56252.048935] asm_common_interrupt+0x26/0x40<br /> [56252.055727] RIP: 0010:cpuidle_enter_state+0xb8/0x420<br /> [56252.063305] Code: dc 01 00 00 e8 f9 79 3b ff e8 64 f7 ff ff 49 89 c5 0f 1f 44 00 00 31 ff e8 a5 32 3a ff 45 84 ff 0f 85 ae<br /> 01 00 00 fb 45 85 f6 88 88 01 00 00 48 8b 04 24 49 63 ce 4c 89 ea 48 6b f1 68 48 29<br /> [56252.088911] RSP: 0018:ffff93120c97fe98 EFLAGS: 00000202<br /> [56252.096912] RAX: ffff9149afd80000 RBX: ffff9141d3a72800 RCX: 0000000000000000<br /> [56252.106844] RDX: 00003329176c6b98 RSI: ffffffe36db3fdc7 RDI: 0000000000000000<br /> [56252.116733] RBP: 0000000000000002 R08: 0000000000000002 R09: 000000000000004e<br /> [56252.126652] R10: ffff9149afdb30c4 R11: 071c71c71c71c71c R12: ffffffff985ff860<br /> [56252.136637] R13: 00003329176c6b98 R14: 0000000000000002 R15: 0000000000000000<br /> [56252.146667] ? cpuidle_enter_state+0xab/0x420<br /> [56252.153909] cpuidle_enter+0x2d/0x40<br /> [56252.160360] do_idle+0x176/0x1c0<br /> [56252.166456<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: fnic: Fix crash in fnic_wq_cmpl_handler when FDMI times out<br /> <br /> When both the RHBA and RPA FDMI requests time out, fnic reuses a frame to<br /> send ABTS for each of them. On send completion, this causes an attempt to<br /> free the same frame twice that leads to a crash.<br /> <br /> Fix crash by allocating separate frames for RHBA and RPA, and modify ABTS<br /> logic accordingly.<br /> <br /> Tested by checking MDS for FDMI information.<br /> <br /> Tested by using instrumented driver to:<br /> <br /> - Drop PLOGI response<br /> - Drop RHBA response<br /> - Drop RPA response<br /> - Drop RHBA and RPA response<br /> - Drop PLOGI response + ABTS response<br /> - Drop RHBA response + ABTS response<br /> - Drop RPA response + ABTS response<br /> - Drop RHBA and RPA response + ABTS response for both of them