Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netdevsim: zero initialize struct iphdr in dummy sk_buff<br /> <br /> Syzbot reports a KMSAN uninit-value originating from<br /> nsim_dev_trap_skb_build, with the allocation also<br /> being performed in the same function.<br /> <br /> Fix this by calling skb_put_zero instead of skb_put to<br /> guarantee zero initialization of the whole IP header.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: netem: fix queue limit check to include reordered packets<br /> <br /> The queue limit check in netem_enqueue() uses q-&gt;t_len which only<br /> counts packets in the internal tfifo. Packets placed in sch-&gt;q by<br /> the reorder path (__qdisc_enqueue_head) are not counted, allowing<br /> the total queue occupancy to exceed sch-&gt;limit under reordering.<br /> <br /> Include sch-&gt;q.qlen in the limit check.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: airoha: fix BQL imbalance in TX path<br /> <br /> Fix a possible BQL imbalance in airoha_dev_xmit(), where inflight<br /> packets are accounted only for the AIROHA_NUM_TX_RING netdev TX<br /> queues. The queue index is computed as:<br /> <br /> qid = skb_get_queue_mapping(skb) % ARRAY_SIZE(qdma-&gt;q_tx)<br /> txq = netdev_get_tx_queue(dev, qid);<br /> <br /> However, airoha_qdma_tx_napi_poll() accounts completions across all<br /> netdev TX queues (num_tx_queues), leading to inconsistent BQL<br /> accounting.<br /> <br /> Also reset all netdev TX queues in the ndo_stop callback.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: avoid double drm_exec_fini() in userq validate<br /> <br /> When new_addition is true, amdgpu_userq_vm_validate() calls<br /> drm_exec_fini(&amp;exec) before iterating over the collected HMM ranges and<br /> calling amdgpu_ttm_tt_get_user_pages().<br /> <br /> If amdgpu_ttm_tt_get_user_pages() fails in that path, the code jumps to<br /> unlock_all and calls drm_exec_fini(&amp;exec) a second time on the same<br /> exec object. drm_exec_fini() is not idempotent: it frees exec-&gt;objects<br /> and may also drop exec-&gt;contended and finalize the ww acquire context.<br /> <br /> Route that error path directly to the range cleanup once exec has<br /> already been finalized.<br /> <br /> Issue found using a prototype static analysis tool<br /> and confirmed by code review.<br /> <br /> (cherry picked from commit 2802952e4a07306da6ebe813ff1acacc5691851a)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: rtl8150: fix use-after-free in rtl8150_start_xmit()<br /> <br /> syzbot reported a KASAN slab-use-after-free read in rtl8150_start_xmit()<br /> when accessing skb-&gt;len for tx statistics after usb_submit_urb() has<br /> been called:<br /> <br /> BUG: KASAN: slab-use-after-free in rtl8150_start_xmit+0x71f/0x760<br /> drivers/net/usb/rtl8150.c:712<br /> Read of size 4 at addr ffff88810eb7a930 by task kworker/0:4/5226<br /> <br /> The URB completion handler write_bulk_callback() frees the skb via<br /> dev_kfree_skb_irq(dev-&gt;tx_skb). The URB may complete on another CPU<br /> in softirq context before usb_submit_urb() returns in the submitter,<br /> so by the time the submitter reads skb-&gt;len the skb has already been<br /> queued to the per-CPU completion_queue and freed by net_tx_action():<br /> <br /> CPU A (xmit) CPU B (USB completion softirq)<br /> ------------ ------------------------------<br /> dev-&gt;tx_skb = skb;<br /> usb_submit_urb() --+<br /> |-------&gt; write_bulk_callback()<br /> | dev_kfree_skb_irq(dev-&gt;tx_skb)<br /> | net_tx_action()<br /> | napi_skb_cache_put() stats.tx_bytes |<br /> += skb-&gt;len; len before submitting the URB and using the<br /> cached value when updating the tx_bytes counter.<br /> <br /> The pre-existing tx_bytes semantics are preserved: the counter tracks<br /> the original frame length (skb-&gt;len), not the ETH_ZLEN/USB-alignment<br /> padded "count" value that is handed to the device. Changing that<br /> would be a user-visible accounting change and is out of scope for<br /> this UAF fix.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> neigh: let neigh_xmit take skb ownership<br /> <br /> neigh_xmit always releases the skb, except when no neighbour table is<br /> found. But even the first added user of neigh_xmit (mpls) relied on<br /> neigh_xmit to release the skb (or queue it for tx).<br /> <br /> sashiko reported:<br /> If neigh_xmit() is called with an uninitialized neighbor table (for<br /> example, NEIGH_ND_TABLE when IPv6 is disabled), it returns -EAFNOSUPPORT<br /> and bypasses its internal out_kfree_skb error path. Because the return<br /> value of neigh_xmit() is ignored here, does this leak the SKB?<br /> <br /> Assume full ownership and remove the last code path that doesn&amp;#39;t<br /> xmit or free skb.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/fair: Clear rel_deadline when initializing forked entities<br /> <br /> A yield-triggered crash can happen when a newly forked sched_entity<br /> enters the fair class with se-&gt;rel_deadline unexpectedly set.<br /> <br /> The failing sequence is:<br /> <br /> 1. A task is forked while se-&gt;rel_deadline is still set.<br /> 2. __sched_fork() initializes vruntime, vlag and other sched_entity<br /> state, but does not clear rel_deadline.<br /> 3. On the first enqueue, enqueue_entity() calls place_entity().<br /> 4. Because se-&gt;rel_deadline is set, place_entity() treats se-&gt;deadline<br /> as a relative deadline and converts it to an absolute deadline by<br /> adding the current vruntime.<br /> 5. However, the forked entity&amp;#39;s deadline is not a valid inherited<br /> relative deadline for this new scheduling instance, so the conversion<br /> produces an abnormally large deadline.<br /> 6. If the task later calls sched_yield(), yield_task_fair() advances<br /> se-&gt;vruntime to se-&gt;deadline.<br /> 7. The inflated vruntime is then used by the following enqueue path,<br /> where the vruntime-derived key can overflow when multiplied by the<br /> entity weight.<br /> 8. This corrupts cfs_rq-&gt;sum_w_vruntime, breaks EEVDF eligibility<br /> calculation, and can eventually make all entities appear ineligible.<br /> pick_next_entity() may then return NULL unexpectedly, leading to a<br /> later NULL dereference.<br /> <br /> A captured trace shows the effect clearly. Before yield, the entity&amp;#39;s<br /> vruntime was around:<br /> <br /> 9834017729983308<br /> <br /> After yield_task_fair() executed:<br /> <br /> se-&gt;vruntime = se-&gt;deadline<br /> <br /> the vruntime jumped to:<br /> <br /> 19668035460670230<br /> <br /> and the deadline was later advanced further to:<br /> <br /> 19668035463470230<br /> <br /> This shows that the deadline had already become abnormally large before<br /> yield_task_fair() copied it into vruntime.<br /> <br /> rel_deadline is only meaningful when se-&gt;deadline really carries a<br /> relative deadline that still needs to be placed against vruntime. A<br /> freshly forked sched_entity should not inherit or retain this state.<br /> Clear se-&gt;rel_deadline in __sched_fork(), together with the other<br /> sched_entity runtime state, so that the first enqueue does not interpret<br /> the new entity&amp;#39;s deadline as a stale relative deadline.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: psp: check for device unregister when creating assoc<br /> <br /> psp_assoc_device_get_locked() obtains a psp_dev reference via<br /> psp_dev_get_for_sock() (which uses psp_dev_tryget() under RCU);<br /> it then acquires psd-&gt;lock and drops the reference. Before<br /> the lock is taken, psp_dev_unregister() can run to completion:<br /> take psd-&gt;lock, clear out state, unlock, drop the registration<br /> reference.<br /> <br /> The expectation is that the lock prevents device unregistration,<br /> but much like with netdevs special care has to be taken when<br /> "upgrading" a reference to a locked device. Add the missing<br /> check if device is still alive. psp_dev_is_registered() exists<br /> already but had no callers, which makes me wonder if I either<br /> forgot to add this or lost the check during refactoring...

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: psp: require admin permission for dev-set and key-rotate<br /> <br /> The dev-set and key-rotate netlink operations modify shared device<br /> state (PSP version configuration and cryptographic key material,<br /> respectively) but do not require CAP_NET_ADMIN. The only access<br /> control is psp_dev_check_access() which merely verifies netns<br /> membership.

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)