Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> futex: Prevent lockup in requeue-PI during signal/ timeout wakeup<br /> <br /> During wait-requeue-pi (task A) and requeue-PI (task B) the following<br /> race can happen:<br /> <br /> Task A Task B<br /> futex_wait_requeue_pi()<br /> futex_setup_timer()<br /> futex_do_wait()<br /> futex_requeue()<br /> CLASS(hb, hb1)(&amp;key1);<br /> CLASS(hb, hb2)(&amp;key2);<br /> *timeout*<br /> futex_requeue_pi_wakeup_sync()<br /> requeue_state = Q_REQUEUE_PI_IGNORE<br /> <br /> *blocks on hb-&gt;lock*<br /> <br /> futex_proxy_trylock_atomic()<br /> futex_requeue_pi_prepare()<br /> Q_REQUEUE_PI_IGNORE =&gt; -EAGAIN<br /> double_unlock_hb(hb1, hb2)<br /> *retry*<br /> <br /> Task B acquires both hb locks and attempts to acquire the PI-lock of the<br /> top most waiter (task B). Task A is leaving early due to a signal/<br /> timeout and started removing itself from the queue. It updates its<br /> requeue_state but can not remove it from the list because this requires<br /> the hb lock which is owned by task B.<br /> <br /> Usually task A is able to swoop the lock after task B unlocked it.<br /> However if task B is of higher priority then task A may not be able to<br /> wake up in time and acquire the lock before task B gets it again.<br /> Especially on a UP system where A is never scheduled.<br /> <br /> As a result task A blocks on the lock and task B busy loops, trying to<br /> make progress but live locks the system instead. Tragic.<br /> <br /> This can be fixed by removing the top most waiter from the list in this<br /> case. This allows task B to grab the next top waiter (if any) in the<br /> next iteration and make progress.<br /> <br /> Remove the top most waiter if futex_requeue_pi_prepare() fails.<br /> Let the waiter conditionally remove itself from the list in<br /> handle_early_requeue_pi_wakeup().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bonding: 3ad: implement proper RCU rules for port-&gt;aggregator<br /> <br /> syzbot found a data-race in bond_3ad_get_active_agg_info /<br /> bond_3ad_state_machine_handler [1] which hints at lack of proper<br /> RCU implementation.<br /> <br /> Add __rcu qualifier to port-&gt;aggregator, and add proper RCU API.<br /> <br /> [1]<br /> <br /> BUG: KCSAN: data-race in bond_3ad_get_active_agg_info / bond_3ad_state_machine_handler<br /> <br /> write to 0xffff88813cf5c4b0 of 8 bytes by task 36 on cpu 0:<br /> ad_port_selection_logic drivers/net/bonding/bond_3ad.c:1659 [inline]<br /> bond_3ad_state_machine_handler+0x9d5/0x2d60 drivers/net/bonding/bond_3ad.c:2569<br /> process_one_work kernel/workqueue.c:3302 [inline]<br /> process_scheduled_works+0x4f0/0x9c0 kernel/workqueue.c:3385<br /> worker_thread+0x58a/0x780 kernel/workqueue.c:3466<br /> kthread+0x22a/0x280 kernel/kthread.c:436<br /> ret_from_fork+0x146/0x330 arch/x86/kernel/process.c:158<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245<br /> <br /> read to 0xffff88813cf5c4b0 of 8 bytes by task 22063 on cpu 1:<br /> __bond_3ad_get_active_agg_info drivers/net/bonding/bond_3ad.c:2858 [inline]<br /> bond_3ad_get_active_agg_info+0x8c/0x230 drivers/net/bonding/bond_3ad.c:2881<br /> bond_fill_info+0xe0f/0x10f0 drivers/net/bonding/bond_netlink.c:853<br /> rtnl_link_info_fill net/core/rtnetlink.c:906 [inline]<br /> rtnl_link_fill+0x1d7/0x4e0 net/core/rtnetlink.c:927<br /> rtnl_fill_ifinfo+0xf8e/0x1380 net/core/rtnetlink.c:2168<br /> rtmsg_ifinfo_build_skb+0x11c/0x1b0 net/core/rtnetlink.c:4453<br /> rtmsg_ifinfo_event net/core/rtnetlink.c:4486 [inline]<br /> rtmsg_ifinfo+0x6d/0x110 net/core/rtnetlink.c:4495<br /> __dev_notify_flags+0x76/0x390 net/core/dev.c:9790<br /> netif_change_flags+0xac/0xd0 net/core/dev.c:9823<br /> do_setlink+0x905/0x2950 net/core/rtnetlink.c:3180<br /> rtnl_group_changelink net/core/rtnetlink.c:3813 [inline]<br /> __rtnl_newlink net/core/rtnetlink.c:3981 [inline]<br /> rtnl_newlink+0xf55/0x1400 net/core/rtnetlink.c:4109<br /> rtnetlink_rcv_msg+0x64b/0x720 net/core/rtnetlink.c:6995<br /> netlink_rcv_skb+0x123/0x220 net/netlink/af_netlink.c:2550<br /> rtnetlink_rcv+0x1c/0x30 net/core/rtnetlink.c:7022<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline]<br /> netlink_unicast+0x5a8/0x680 net/netlink/af_netlink.c:1344<br /> netlink_sendmsg+0x5c8/0x6f0 net/netlink/af_netlink.c:1894<br /> sock_sendmsg_nosec net/socket.c:787 [inline]<br /> __sock_sendmsg net/socket.c:802 [inline]<br /> ____sys_sendmsg+0x563/0x5b0 net/socket.c:2698<br /> ___sys_sendmsg+0x195/0x1e0 net/socket.c:2752<br /> __sys_sendmsg net/socket.c:2784 [inline]<br /> __do_sys_sendmsg net/socket.c:2789 [inline]<br /> __se_sys_sendmsg net/socket.c:2787 [inline]<br /> __x64_sys_sendmsg+0xd4/0x160 net/socket.c:2787<br /> x64_sys_call+0x194c/0x3020 arch/x86/include/generated/asm/syscalls_64.h:47<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0x12c/0x3b0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> value changed: 0x0000000000000000 -&gt; 0xffff88813cf5c400<br /> <br /> Reported by Kernel Concurrency Sanitizer on:<br /> CPU: 1 UID: 0 PID: 22063 Comm: syz.0.31122 Tainted: G W syzkaller #0 PREEMPT(full)<br /> Tainted: [W]=WARN<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe: Fix error cleanup in xe_exec_queue_create_ioctl()<br /> <br /> Two error handling issues exist in xe_exec_queue_create_ioctl():<br /> <br /> 1. When xe_hw_engine_group_add_exec_queue() fails, the error path jumps<br /> to put_exec_queue which skips xe_exec_queue_kill(). If the VM is in<br /> preempt fence mode, xe_vm_add_compute_exec_queue() has already added<br /> the queue to the VM&amp;#39;s compute exec queue list. Skipping the kill<br /> leaves the queue on that list, leading to a dangling pointer after<br /> the queue is freed.<br /> <br /> 2. When xa_alloc() fails after xe_hw_engine_group_add_exec_queue() has<br /> succeeded, the error path does not call<br /> xe_hw_engine_group_del_exec_queue() to remove the queue from the hw<br /> engine group list. The queue is then freed while still linked into<br /> the hw engine group, causing a use-after-free.<br /> <br /> Fix both by:<br /> - Changing the xe_hw_engine_group_add_exec_queue() failure path to jump<br /> to kill_exec_queue so that xe_exec_queue_kill() properly removes the<br /> queue from the VM&amp;#39;s compute list.<br /> - Adding a del_hw_engine_group label before kill_exec_queue for the<br /> xa_alloc() failure path, which removes the queue from the hw engine<br /> group before proceeding with the rest of the cleanup.<br /> <br /> (cherry picked from commit 37c831f401746a45d510b312b0ed7a77b1e06ec8)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: Reject wrapped offset in kvm_reset_dirty_gfn()<br /> <br /> kvm_reset_dirty_gfn() guards the gfn range with<br /> <br /> if (!memslot || (offset + __fls(mask)) &gt;= memslot-&gt;npages)<br /> return;<br /> <br /> but offset is u64 and the addition is unchecked. The check can be<br /> silently bypassed by a u64 wrap.<br /> <br /> The dirty ring backing those entries is MAP_SHARED at<br /> KVM_DIRTY_LOG_PAGE_OFFSET of the vcpu fd, so the VMM can rewrite the<br /> slot and offset fields of any entry between when the kernel pushes<br /> them and when KVM_RESET_DIRTY_RINGS consumes them. On reset,<br /> kvm_dirty_ring_reset() re-reads the values via READ_ONCE() and feeds<br /> them straight back into this check; only the flags handshake is<br /> treated as the handover, the slot/offset payload is taken on trust.<br /> <br /> Crafting two entries<br /> <br /> entry[i].offset = 0xffffffffffffffc1<br /> entry[i+1].offset = 0<br /> <br /> makes the coalescing loop in kvm_dirty_ring_reset() compute<br /> <br /> delta = (s64)(0 - 0xffffffffffffffc1) = 63<br /> <br /> which falls in [0, BITS_PER_LONG), so it folds entry[i+1] into the<br /> existing mask by setting bit 63. The trailing kvm_reset_dirty_gfn()<br /> call then sees offset = 0xffffffffffffffc1 and __fls(mask) = 63;<br /> the sum is 0 in u64 and the bounds check passes.<br /> <br /> That offset propagates into kvm_arch_mmu_enable_log_dirty_pt_masked()<br /> unchanged. On the legacy MMU path -- kvm_memslots_have_rmaps() ==<br /> true, i.e. shadow paging, any VM that has allocated shadow roots, or<br /> a write-tracked slot -- it reaches gfn_to_rmap(), which indexes<br /> slot-&gt;arch.rmap[0][] with a near-U64_MAX gfn. That is an<br /> out-of-bounds load of a kvm_rmap_head, followed by a conditional<br /> clear of PT_WRITABLE_MASK in whatever the loaded pointer points at.<br /> The path is reachable from any process holding /dev/kvm.<br /> <br /> Range-check offset on its own first, so the addition cannot wrap.<br /> memslot-&gt;npages is bounded well below U64_MAX, so once offset

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: s390: pci: fix GAIT table indexing due to double-scaling pointer arithmetic<br /> <br /> kvm_s390_pci_aif_enable(), kvm_s390_pci_aif_disable(), and<br /> aen_host_forward() index the GAIT by manually multiplying the index<br /> with sizeof(struct zpci_gaite).<br /> <br /> Since aift-&gt;gait is already a struct zpci_gaite pointer, this<br /> double-scales the offset, accessing element aisb*16 instead of aisb.<br /> <br /> This causes out-of-bounds accesses when aisb &gt;= 32 (with<br /> ZPCI_NR_DEVICES=512)<br /> <br /> Fix by removing the erroneous sizeof multiplication.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: tls: fix strparser anchor skb leak on offload RX setup failure<br /> <br /> When tls_set_device_offload_rx() fails at tls_dev_add(), the error path<br /> calls tls_sw_free_resources_rx() to clean up the SW context that was<br /> initialized by tls_set_sw_offload(). This function calls<br /> tls_sw_release_resources_rx() (which stops the strparser via<br /> tls_strp_stop()) and tls_sw_free_ctx_rx() (which kfrees the context),<br /> but never frees the anchor skb that was allocated by alloc_skb(0) in<br /> tls_strp_init().<br /> <br /> Note that tls_sw_free_resources_rx() is exclusively used for this<br /> "failed to start offload" code path, there&amp;#39;s no other caller.<br /> <br /> The leak did not exist before commit 84c61fe1a75b ("tls: rx: do not use<br /> the standard strparser"), because the standard strparser doesn&amp;#39;t try<br /> to pre-allocate an skb.<br /> <br /> The normal close path in tls_sk_proto_close() handles cleanup by calling<br /> tls_sw_strparser_done() (which calls tls_strp_done()) after dropping<br /> the socket lock, because tls_strp_done() does cancel_work_sync() and<br /> the strparser work handler takes the socket lock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ena: PHC: Fix potential use-after-free in get_timestamp<br /> <br /> Move the phc-&gt;active check and resp pointer assignment to after<br /> acquiring the spinlock. Previously, phc-&gt;active was checked without<br /> holding the lock, and resp was cached from ena_dev-&gt;phc.virt_addr<br /> before the lock was acquired.<br /> <br /> If ena_com_phc_destroy() runs between the lockless active check and<br /> the lock acquisition, it sets active=false, releases the lock, frees<br /> the DMA memory, and sets virt_addr=NULL. The get_timestamp path would<br /> then read a NULL virt_addr and dereference it.<br /> <br /> With both the active check and the pointer read under the lock,<br /> destroy cannot free the memory while get_timestamp is using it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nft_ct: fix missing expect put in obj eval<br /> <br /> nft_ct_expect_obj_eval() allocates an expectation and may call<br /> nf_ct_expect_related(), but never drops its local reference.<br /> <br /> Add nf_ct_expect_put(exp) before return to balance allocation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb/client: fix possible infinite loop and oob read in symlink_data()<br /> <br /> On 32-bit architectures, the infinite loop is as follows:<br /> <br /> len = p-&gt;ErrorDataLength == 0xfffffff8<br /> u8 *next = p-&gt;ErrorContextData + len<br /> next == p<br /> <br /> On 32-bit architectures, the out-of-bounds read is as follows:<br /> <br /> len = p-&gt;ErrorDataLength == 0xfffffff0<br /> u8 *next = p-&gt;ErrorContextData + len<br /> next == (u8 *)p - 8

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm: Replace old pointer to new idr<br /> <br /> Commit 5e28b7b94408 introduced a logical error by failing to replace the<br /> newly generated IDR pointer to old id&amp;#39;s pointer at the correct location<br /> within the "change handle" logic; this resulted in the issue reported by<br /> syzbot [1].<br /> <br /> Specifically, the new IDR object pointer is intended to replace the original<br /> id&amp;#39;s pointer during the normal execution flow.<br /> <br /> Additionally, an unnecessary conditional check for the ret exit path has<br /> been removed.<br /> <br /> [1]<br /> !RB_EMPTY_ROOT(&amp;prime_fpriv-&gt;dmabufs)<br /> WARNING: drivers/gpu/drm/drm_prime.c:224 at drm_prime_destroy_file_private+0x48/0x60 drivers/gpu/drm/drm_prime.c:224, CPU#0: syz.0.17/5833<br /> Call Trace:<br /> drm_file_free.part.0+0x7e6/0xcc0 drivers/gpu/drm/drm_file.c:269<br /> drm_file_free drivers/gpu/drm/drm_file.c:237 [inline]<br /> drm_close_helper.isra.0+0x186/0x200 drivers/gpu/drm/drm_file.c:290<br /> drm_release+0x1ab/0x360 drivers/gpu/drm/drm_file.c:438

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: af_alg - Cap AEAD AD length to 0x80000000<br /> <br /> In order to prevent arithmetic overflows when checking the TX<br /> buffer size, cap the associated data length to 0x80000000.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> futex: Drop CLONE_THREAD requirement for private default hash alloc<br /> <br /> Currently need_futex_hash_allocate_default() depends on strict pthread<br /> semantics, abusing CLONE_THREAD. This breaks the non-concurrency<br /> assumptions when doing the mm-&gt;futex_ref pcpu allocations, leading to<br /> bugs[0] when sharing the mm in other ways; ie:<br /> <br /> BUG: KASAN: slab-use-after-free in futex_hash_put<br /> <br /> ... where the +1 bias can end up on a percpu counter that mm-&gt;futex_ref<br /> no longer points at.<br /> <br /> Loosen the check to cover any CLONE_VM clone, except vfork(). Excluding<br /> vfork keeps the existing paths untouched (no overhead), and we can&amp;#39;t<br /> race in the first place: either the parent is suspended and the child<br /> runs alone, or mm-&gt;futex_ref is already allocated from an earlier<br /> CLONE_VM.