Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: ctnetlink: fix use-after-free in ctnetlink_dump_exp_ct()<br /> <br /> ctnetlink_dump_exp_ct() stores a conntrack pointer in cb-&gt;data for the<br /> netlink dump callback ctnetlink_exp_ct_dump_table(), but drops the<br /> conntrack reference immediately after netlink_dump_start(). When the<br /> dump spans multiple rounds, the second recvmsg() triggers the dump<br /> callback which dereferences the now-freed conntrack via nfct_help(ct),<br /> leading to a use-after-free on ct-&gt;ext.<br /> <br /> The bug is that the netlink_dump_control has no .start or .done<br /> callbacks to manage the conntrack reference across dump rounds. Other<br /> dump functions in the same file (e.g. ctnetlink_get_conntrack) properly<br /> use .start/.done callbacks for this purpose.<br /> <br /> Fix this by adding .start and .done callbacks that hold and release the<br /> conntrack reference for the duration of the dump, and move the<br /> nfct_help() call after the cb-&gt;args[0] early-return check in the dump<br /> callback to avoid dereferencing ct-&gt;ext unnecessarily.<br /> <br /> BUG: KASAN: slab-use-after-free in ctnetlink_exp_ct_dump_table+0x4f/0x2e0<br /> Read of size 8 at addr ffff88810597ebf0 by task ctnetlink_poc/133<br /> <br /> CPU: 1 UID: 0 PID: 133 Comm: ctnetlink_poc Not tainted 7.0.0-rc2+ #3 PREEMPTLAZY<br /> Call Trace:<br /> <br /> ctnetlink_exp_ct_dump_table+0x4f/0x2e0<br /> netlink_dump+0x333/0x880<br /> netlink_recvmsg+0x3e2/0x4b0<br /> ? aa_sk_perm+0x184/0x450<br /> sock_recvmsg+0xde/0xf0<br /> <br /> Allocated by task 133:<br /> kmem_cache_alloc_noprof+0x134/0x440<br /> __nf_conntrack_alloc+0xa8/0x2b0<br /> ctnetlink_create_conntrack+0xa1/0x900<br /> ctnetlink_new_conntrack+0x3cf/0x7d0<br /> nfnetlink_rcv_msg+0x48e/0x510<br /> netlink_rcv_skb+0xc9/0x1f0<br /> nfnetlink_rcv+0xdb/0x220<br /> netlink_unicast+0x3ec/0x590<br /> netlink_sendmsg+0x397/0x690<br /> __sys_sendmsg+0xf4/0x180<br /> <br /> Freed by task 0:<br /> slab_free_after_rcu_debug+0xad/0x1e0<br /> rcu_core+0x5c3/0x9c0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ip_tunnel: adapt iptunnel_xmit_stats() to NETDEV_PCPU_STAT_DSTATS<br /> <br /> Blamed commits forgot that vxlan/geneve use udp_tunnel[6]_xmit_skb() which<br /> call iptunnel_xmit_stats().<br /> <br /> iptunnel_xmit_stats() was assuming tunnels were only using<br /> NETDEV_PCPU_STAT_TSTATS.<br /> <br /> @syncp offset in pcpu_sw_netstats and pcpu_dstats is different.<br /> <br /> 32bit kernels would either have corruptions or freezes if the syncp<br /> sequence was overwritten.<br /> <br /> This patch also moves pcpu_stat_type closer to dev-&gt;{t,d}stats to avoid<br /> a potential cache line miss since iptunnel_xmit_stats() needs to read it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/rose: fix NULL pointer dereference in rose_transmit_link on reconnect<br /> <br /> syzkaller reported a bug [1], and the reproducer is available at [2].<br /> <br /> ROSE sockets use four sk-&gt;sk_state values: TCP_CLOSE, TCP_LISTEN,<br /> TCP_SYN_SENT, and TCP_ESTABLISHED. rose_connect() already rejects<br /> calls for TCP_ESTABLISHED (-EISCONN) and TCP_CLOSE with SS_CONNECTING<br /> (-ECONNREFUSED), but lacks a check for TCP_SYN_SENT.<br /> <br /> When rose_connect() is called a second time while the first connection<br /> attempt is still in progress (TCP_SYN_SENT), it overwrites<br /> rose-&gt;neighbour via rose_get_neigh(). If that returns NULL, the socket<br /> is left with rose-&gt;state == ROSE_STATE_1 but rose-&gt;neighbour == NULL.<br /> When the socket is subsequently closed, rose_release() sees<br /> ROSE_STATE_1 and calls rose_write_internal() -&gt;<br /> rose_transmit_link(skb, NULL), causing a NULL pointer dereference.<br /> <br /> Per connect(2), a second connect() while a connection is already in<br /> progress should return -EALREADY. Add this missing check for<br /> TCP_SYN_SENT to complete the state validation in rose_connect().<br /> <br /> [1] https://syzkaller.appspot.com/bug?extid=d00f90e0af54102fb271<br /> [2] https://gist.github.com/mrpre/9e6779e0d13e2c66779b1653fef80516

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.