Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: teql: Fix double-free in teql_master_xmit<br /> <br /> Whenever a TEQL devices has a lockless Qdisc as root, qdisc_reset should<br /> be called using the seq_lock to avoid racing with the datapath. Failure<br /> to do so may cause crashes like the following:<br /> <br /> [ 238.028993][ T318] BUG: KASAN: double-free in skb_release_data (net/core/skbuff.c:1139)<br /> [ 238.029328][ T318] Free of addr ffff88810c67ec00 by task poc_teql_uaf_ke/318<br /> [ 238.029749][ T318]<br /> [ 238.029900][ T318] CPU: 3 UID: 0 PID: 318 Comm: poc_teql_ke Not tainted 7.0.0-rc3-00149-ge5b31d988a41 #704 PREEMPT(full)<br /> [ 238.029906][ T318] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011<br /> [ 238.029910][ T318] Call Trace:<br /> [ 238.029913][ T318] <br /> [ 238.029916][ T318] dump_stack_lvl (lib/dump_stack.c:122)<br /> [ 238.029928][ T318] print_report (mm/kasan/report.c:379 mm/kasan/report.c:482)<br /> [ 238.029940][ T318] ? skb_release_data (net/core/skbuff.c:1139)<br /> [ 238.029944][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)<br /> ...<br /> [ 238.029957][ T318] ? skb_release_data (net/core/skbuff.c:1139)<br /> [ 238.029969][ T318] kasan_report_invalid_free (mm/kasan/report.c:221 mm/kasan/report.c:563)<br /> [ 238.029979][ T318] ? skb_release_data (net/core/skbuff.c:1139)<br /> [ 238.029989][ T318] check_slab_allocation (mm/kasan/common.c:231)<br /> [ 238.029995][ T318] kmem_cache_free (mm/slub.c:2637 (discriminator 1) mm/slub.c:6168 (discriminator 1) mm/slub.c:6298 (discriminator 1))<br /> [ 238.030004][ T318] skb_release_data (net/core/skbuff.c:1139)<br /> ...<br /> [ 238.030025][ T318] sk_skb_reason_drop (net/core/skbuff.c:1256)<br /> [ 238.030032][ T318] pfifo_fast_reset (./include/linux/ptr_ring.h:171 ./include/linux/ptr_ring.h:309 ./include/linux/skb_array.h:98 net/sched/sch_generic.c:827)<br /> [ 238.030039][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)<br /> ...<br /> [ 238.030054][ T318] qdisc_reset (net/sched/sch_generic.c:1034)<br /> [ 238.030062][ T318] teql_destroy (./include/linux/spinlock.h:395 net/sched/sch_teql.c:157)<br /> [ 238.030071][ T318] __qdisc_destroy (./include/net/pkt_sched.h:328 net/sched/sch_generic.c:1077)<br /> [ 238.030077][ T318] qdisc_graft (net/sched/sch_api.c:1062 net/sched/sch_api.c:1053 net/sched/sch_api.c:1159)<br /> [ 238.030089][ T318] ? __pfx_qdisc_graft (net/sched/sch_api.c:1091)<br /> [ 238.030095][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)<br /> [ 238.030102][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)<br /> [ 238.030106][ T318] ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)<br /> [ 238.030114][ T318] tc_get_qdisc (net/sched/sch_api.c:1529 net/sched/sch_api.c:1556)<br /> ...<br /> [ 238.072958][ T318] Allocated by task 303 on cpu 5 at 238.026275s:<br /> [ 238.073392][ T318] kasan_save_stack (mm/kasan/common.c:58)<br /> [ 238.073884][ T318] kasan_save_track (mm/kasan/common.c:64 (discriminator 5) mm/kasan/common.c:79 (discriminator 5))<br /> [ 238.074230][ T318] __kasan_slab_alloc (mm/kasan/common.c:369)<br /> [ 238.074578][ T318] kmem_cache_alloc_node_noprof (./include/linux/kasan.h:253 mm/slub.c:4542 mm/slub.c:4869 mm/slub.c:4921)<br /> [ 238.076091][ T318] kmalloc_reserve (net/core/skbuff.c:616 (discriminator 107))<br /> [ 238.076450][ T318] __alloc_skb (net/core/skbuff.c:713)<br /> [ 238.076834][ T318] alloc_skb_with_frags (./include/linux/skbuff.h:1383 net/core/skbuff.c:6763)<br /> [ 238.077178][ T318] sock_alloc_send_pskb (net/core/sock.c:2997)<br /> [ 238.077520][ T318] packet_sendmsg (net/packet/af_packet.c:2926 net/packet/af_packet.c:3019 net/packet/af_packet.c:3108)<br /> [ 238.081469][ T318]<br /> [ 238.081870][ T318] Freed by task 299 on cpu 1 at 238.028496s:<br /> [ 238.082761][ T318] kasan_save_stack (mm/kasan/common.c:58)<br /> [ 238.083481][ T318] kasan_save_track (mm/kasan/common.c:64 (discriminator 5) mm/kasan/common.c:79 (discriminator 5))<br /> [ 238.085348][ T318] kasan_save_free_info (mm/kasan/generic.c:587 (discriminator 1))<br /> [ 238.085900][ T318] __kasan_slab_free (mm/<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: fix NULL dereference and UAF in smc_tcp_syn_recv_sock()<br /> <br /> Syzkaller reported a panic in smc_tcp_syn_recv_sock() [1].<br /> <br /> smc_tcp_syn_recv_sock() is called in the TCP receive path<br /> (softirq) via icsk_af_ops-&gt;syn_recv_sock on the clcsock (TCP<br /> listening socket). It reads sk_user_data to get the smc_sock<br /> pointer. However, when the SMC listen socket is being closed<br /> concurrently, smc_close_active() sets clcsock-&gt;sk_user_data<br /> to NULL under sk_callback_lock, and then the smc_sock itself<br /> can be freed via sock_put() in smc_release().<br /> <br /> This leads to two issues:<br /> <br /> 1) NULL pointer dereference: sk_user_data is NULL when<br /> accessed.<br /> 2) Use-after-free: sk_user_data is read as non-NULL, but the<br /> smc_sock is freed before its fields (e.g., queued_smc_hs,<br /> ori_af_ops) are accessed.<br /> <br /> The race window looks like this (the syzkaller crash [1]<br /> triggers via the SYN cookie path: tcp_get_cookie_sock() -&gt;<br /> smc_tcp_syn_recv_sock(), but the normal tcp_check_req() path<br /> has the same race):<br /> <br /> CPU A (softirq) CPU B (process ctx)<br /> <br /> tcp_v4_rcv()<br /> TCP_NEW_SYN_RECV:<br /> sk = req-&gt;rsk_listener<br /> sock_hold(sk)<br /> /* No lock on listener */<br /> smc_close_active():<br /> write_lock_bh(cb_lock)<br /> sk_user_data = NULL<br /> write_unlock_bh(cb_lock)<br /> ...<br /> smc_clcsock_release()<br /> sock_put(smc-&gt;sk) x2<br /> -&gt; smc_sock freed!<br /> tcp_check_req()<br /> smc_tcp_syn_recv_sock():<br /> smc = user_data(sk)<br /> -&gt; NULL or dangling<br /> smc-&gt;queued_smc_hs<br /> -&gt; crash!<br /> <br /> Note that the clcsock and smc_sock are two independent objects<br /> with separate refcounts. TCP stack holds a reference on the<br /> clcsock, which keeps it alive, but this does NOT prevent the<br /> smc_sock from being freed.<br /> <br /> Fix this by using RCU and refcount_inc_not_zero() to safely<br /> access smc_sock. Since smc_tcp_syn_recv_sock() is called in<br /> the TCP three-way handshake path, taking read_lock_bh on<br /> sk_callback_lock is too heavy and would not survive a SYN<br /> flood attack. Using rcu_read_lock() is much more lightweight.<br /> <br /> - Set SOCK_RCU_FREE on the SMC listen socket so that<br /> smc_sock freeing is deferred until after the RCU grace<br /> period. This guarantees the memory is still valid when<br /> accessed inside rcu_read_lock().<br /> - Use rcu_read_lock() to protect reading sk_user_data.<br /> - Use refcount_inc_not_zero(&amp;smc-&gt;sk.sk_refcnt) to pin the<br /> smc_sock. If the refcount has already reached zero (close<br /> path completed), it returns false and we bail out safely.<br /> <br /> Note: smc_hs_congested() has a similar lockless read of<br /> sk_user_data without rcu_read_lock(), but it only checks for<br /> NULL and accesses the global smc_hs_wq, never dereferencing<br /> any smc_sock field, so it is not affected.<br /> <br /> Reproducer was verified with mdelay injection and smc_run,<br /> the issue no longer occurs with this patch applied.<br /> <br /> [1] https://syzkaller.appspot.com/bug?extid=827ae2bfb3a3529333e9

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bonding: prevent potential infinite loop in bond_header_parse()<br /> <br /> bond_header_parse() can loop if a stack of two bonding devices is setup,<br /> because skb-&gt;dev always points to the hierarchy top.<br /> <br /> Add new "const struct net_device *dev" parameter to<br /> (struct header_ops)-&gt;parse() method to make sure the recursion<br /> is bounded, and that the final leaf parse method is called.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PM: runtime: Fix a race condition related to device removal<br /> <br /> The following code in pm_runtime_work() may dereference the dev-&gt;parent<br /> pointer after the parent device has been freed:<br /> <br /> /* Maybe the parent is now able to suspend. */<br /> if (parent &amp;&amp; !parent-&gt;power.ignore_children) {<br /> spin_unlock(&amp;dev-&gt;power.lock);<br /> <br /> spin_lock(&amp;parent-&gt;power.lock);<br /> rpm_idle(parent, RPM_ASYNC);<br /> spin_unlock(&amp;parent-&gt;power.lock);<br /> <br /> spin_lock(&amp;dev-&gt;power.lock);<br /> }<br /> <br /> Fix this by inserting a flush_work() call in pm_runtime_remove().<br /> <br /> Without this patch blktest block/001 triggers the following complaint<br /> sporadically:<br /> <br /> BUG: KASAN: slab-use-after-free in lock_acquire+0x70/0x160<br /> Read of size 1 at addr ffff88812bef7198 by task kworker/u553:1/3081<br /> Workqueue: pm pm_runtime_work<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x61/0x80<br /> print_address_description.constprop.0+0x8b/0x310<br /> print_report+0xfd/0x1d7<br /> kasan_report+0xd8/0x1d0<br /> __kasan_check_byte+0x42/0x60<br /> lock_acquire.part.0+0x38/0x230<br /> lock_acquire+0x70/0x160<br /> _raw_spin_lock+0x36/0x50<br /> rpm_suspend+0xc6a/0xfe0<br /> rpm_idle+0x578/0x770<br /> pm_runtime_work+0xee/0x120<br /> process_one_work+0xde3/0x1410<br /> worker_thread+0x5eb/0xfe0<br /> kthread+0x37b/0x480<br /> ret_from_fork+0x6cb/0x920<br /> ret_from_fork_asm+0x11/0x20<br /> <br /> <br /> Allocated by task 4314:<br /> kasan_save_stack+0x2a/0x50<br /> kasan_save_track+0x18/0x40<br /> kasan_save_alloc_info+0x3d/0x50<br /> __kasan_kmalloc+0xa0/0xb0<br /> __kmalloc_noprof+0x311/0x990<br /> scsi_alloc_target+0x122/0xb60 [scsi_mod]<br /> __scsi_scan_target+0x101/0x460 [scsi_mod]<br /> scsi_scan_channel+0x179/0x1c0 [scsi_mod]<br /> scsi_scan_host_selected+0x259/0x2d0 [scsi_mod]<br /> store_scan+0x2d2/0x390 [scsi_mod]<br /> dev_attr_store+0x43/0x80<br /> sysfs_kf_write+0xde/0x140<br /> kernfs_fop_write_iter+0x3ef/0x670<br /> vfs_write+0x506/0x1470<br /> ksys_write+0xfd/0x230<br /> __x64_sys_write+0x76/0xc0<br /> x64_sys_call+0x213/0x1810<br /> do_syscall_64+0xee/0xfc0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> Freed by task 4314:<br /> kasan_save_stack+0x2a/0x50<br /> kasan_save_track+0x18/0x40<br /> kasan_save_free_info+0x3f/0x50<br /> __kasan_slab_free+0x67/0x80<br /> kfree+0x225/0x6c0<br /> scsi_target_dev_release+0x3d/0x60 [scsi_mod]<br /> device_release+0xa3/0x220<br /> kobject_cleanup+0x105/0x3a0<br /> kobject_put+0x72/0xd0<br /> put_device+0x17/0x20<br /> scsi_device_dev_release+0xacf/0x12c0 [scsi_mod]<br /> device_release+0xa3/0x220<br /> kobject_cleanup+0x105/0x3a0<br /> kobject_put+0x72/0xd0<br /> put_device+0x17/0x20<br /> scsi_device_put+0x7f/0xc0 [scsi_mod]<br /> sdev_store_delete+0xa5/0x120 [scsi_mod]<br /> dev_attr_store+0x43/0x80<br /> sysfs_kf_write+0xde/0x140<br /> kernfs_fop_write_iter+0x3ef/0x670<br /> vfs_write+0x506/0x1470<br /> ksys_write+0xfd/0x230<br /> __x64_sys_write+0x76/0xc0<br /> x64_sys_call+0x213/0x1810

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ti: icssg-prueth: Fix memory leak in XDP_DROP for non-zero-copy mode<br /> <br /> Page recycling was removed from the XDP_DROP path in emac_run_xdp() to<br /> avoid conflicts with AF_XDP zero-copy mode, which uses xsk_buff_free()<br /> instead.<br /> <br /> However, this causes a memory leak when running XDP programs that drop<br /> packets in non-zero-copy mode (standard page pool mode). The pages are<br /> never returned to the page pool, leading to OOM conditions.<br /> <br /> Fix this by handling cleanup in the caller, emac_rx_packet().<br /> When emac_run_xdp() returns ICSSG_XDP_CONSUMED for XDP_DROP, the<br /> caller now recycles the page back to the page pool. The zero-copy<br /> path, emac_rx_packet_zc() already handles cleanup correctly with<br /> xsk_buff_free().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: mana: fix use-after-free in mana_hwc_destroy_channel() by reordering teardown<br /> <br /> A potential race condition exists in mana_hwc_destroy_channel() where<br /> hwc-&gt;caller_ctx is freed before the HWC&amp;#39;s Completion Queue (CQ) and<br /> Event Queue (EQ) are destroyed. This allows an in-flight CQ interrupt<br /> handler to dereference freed memory, leading to a use-after-free or<br /> NULL pointer dereference in mana_hwc_handle_resp().<br /> <br /> mana_smc_teardown_hwc() signals the hardware to stop but does not<br /> synchronize against IRQ handlers already executing on other CPUs. The<br /> IRQ synchronization only happens in mana_hwc_destroy_cq() via<br /> mana_gd_destroy_eq() -&gt; mana_gd_deregister_irq(). Since this runs<br /> after kfree(hwc-&gt;caller_ctx), a concurrent mana_hwc_rx_event_handler()<br /> can dereference freed caller_ctx (and rxq-&gt;msg_buf) in<br /> mana_hwc_handle_resp().<br /> <br /> Fix this by reordering teardown to reverse-of-creation order: destroy<br /> the TX/RX work queues and CQ/EQ before freeing hwc-&gt;caller_ctx. This<br /> ensures all in-flight interrupt handlers complete before the memory they<br /> access is freed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> igc: fix page fault in XDP TX timestamps handling<br /> <br /> If an XDP application that requested TX timestamping is shutting down<br /> while the link of the interface in use is still up the following kernel<br /> splat is reported:<br /> <br /> [ 883.803618] [ T1554] BUG: unable to handle page fault for address: ffffcfb6200fd008<br /> ...<br /> [ 883.803650] [ T1554] Call Trace:<br /> [ 883.803652] [ T1554] <br /> [ 883.803654] [ T1554] igc_ptp_tx_tstamp_event+0xdf/0x160 [igc]<br /> [ 883.803660] [ T1554] igc_tsync_interrupt+0x2d5/0x300 [igc]<br /> ...<br /> <br /> During shutdown of the TX ring the xsk_meta pointers are left behind, so<br /> that the IRQ handler is trying to touch them.<br /> <br /> This issue is now being fixed by cleaning up the stale xsk meta data on<br /> TX shutdown. TX timestamps on other queues remain unaffected.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: aqc111: Do not perform PM inside suspend callback<br /> <br /> syzbot reports "task hung in rpm_resume"<br /> <br /> This is caused by aqc111_suspend calling<br /> the PM variant of its write_cmd routine.<br /> <br /> The simplified call trace looks like this:<br /> <br /> rpm_suspend()<br /> usb_suspend_both() - here udev-&gt;dev.power.runtime_status == RPM_SUSPENDING<br /> aqc111_suspend() - called for the usb device interface<br /> aqc111_write32_cmd()<br /> usb_autopm_get_interface()<br /> pm_runtime_resume_and_get()<br /> rpm_resume() - here we call rpm_resume() on our parent<br /> rpm_resume() - Here we wait for a status change that will never happen.<br /> <br /> At this point we block another task which holds<br /> rtnl_lock and locks up the whole networking stack.<br /> <br /> Fix this by replacing the write_cmd calls with their _nopm variants

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: cdc_ncm: add ndpoffset to NDP32 nframes bounds check<br /> <br /> The same bounds-check bug fixed for NDP16 in the previous patch also<br /> exists in cdc_ncm_rx_verify_ndp32(). The DPE array size is validated<br /> against the total skb length without accounting for ndpoffset, allowing<br /> out-of-bounds reads when the NDP32 is placed near the end of the NTB.<br /> <br /> Add ndpoffset to the nframes bounds check and use struct_size_t() to<br /> express the NDP-plus-DPE-array size more clearly.<br /> <br /> Compile-tested only.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: cdc_ncm: add ndpoffset to NDP16 nframes bounds check<br /> <br /> cdc_ncm_rx_verify_ndp16() validates that the NDP header and its DPE<br /> entries fit within the skb. The first check correctly accounts for<br /> ndpoffset:<br /> <br /> if ((ndpoffset + sizeof(struct usb_cdc_ncm_ndp16)) &gt; skb_in-&gt;len)<br /> <br /> but the second check omits it:<br /> <br /> if ((sizeof(struct usb_cdc_ncm_ndp16) +<br /> ret * (sizeof(struct usb_cdc_ncm_dpe16))) &gt; skb_in-&gt;len)<br /> <br /> This validates the DPE array size against the total skb length as if<br /> the NDP were at offset 0, rather than at ndpoffset. When the NDP is<br /> placed near the end of the NTB (large wNdpIndex), the DPE entries can<br /> extend past the skb data buffer even though the check passes.<br /> cdc_ncm_rx_fixup() then reads out-of-bounds memory when iterating<br /> the DPE array.<br /> <br /> Add ndpoffset to the nframes bounds check and use struct_size_t() to<br /> express the NDP-plus-DPE-array size more clearly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: add NULL checks for idev in SRv6 paths<br /> <br /> __in6_dev_get() can return NULL when the device has no IPv6 configuration<br /> (e.g. MTU

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPI: processor: Fix previous acpi_processor_errata_piix4() fix<br /> <br /> After commi f132e089fe89 ("ACPI: processor: Fix NULL-pointer dereference<br /> in acpi_processor_errata_piix4()"), device pointers may be dereferenced<br /> after dropping references to the device objects pointed to by them,<br /> which may cause a use-after-free to occur.<br /> <br /> Moreover, debug messages about enabling the errata may be printed<br /> if the errata flags corresponding to them are unset.<br /> <br /> Address all of these issues by moving message printing to the points<br /> in the code where the errata flags are set.