Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: L2CAP: Fix use-after-free in l2cap_unregister_user<br /> <br /> After commit ab4eedb790ca ("Bluetooth: L2CAP: Fix corrupted list in<br /> hci_chan_del"), l2cap_conn_del() uses conn-&gt;lock to protect access to<br /> conn-&gt;users. However, l2cap_register_user() and l2cap_unregister_user()<br /> don&amp;#39;t use conn-&gt;lock, creating a race condition where these functions can<br /> access conn-&gt;users and conn-&gt;hchan concurrently with l2cap_conn_del().<br /> <br /> This can lead to use-after-free and list corruption bugs, as reported<br /> by syzbot.<br /> <br /> Fix this by changing l2cap_register_user() and l2cap_unregister_user()<br /> to use conn-&gt;lock instead of hci_dev_lock(), ensuring consistent locking<br /> for the l2cap_conn structure.

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 /> netfilter: nf_conntrack_h323: check for zero length in DecodeQ931()<br /> <br /> In DecodeQ931(), the UserUserIE code path reads a 16-bit length from<br /> the packet, then decrements it by 1 to skip the protocol discriminator<br /> byte before passing it to DecodeH323_UserInformation(). If the encoded<br /> length is 0, the decrement wraps to -1, which is then passed as a<br /> large value to the decoder, leading to an out-of-bounds read.<br /> <br /> Add a check to ensure len is positive after the decrement.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_conntrack_h323: fix OOB read in decode_int() CONS case<br /> <br /> In decode_int(), the CONS case calls get_bits(bs, 2) to read a length<br /> value, then calls get_uint(bs, len) without checking that len bytes<br /> remain in the buffer. The existing boundary check only validates the<br /> 2 bits for get_bits(), not the subsequent 1-4 bytes that get_uint()<br /> reads. This allows a malformed H.323/RAS packet to cause a 1-4 byte<br /> slab-out-of-bounds read.<br /> <br /> Add a boundary check for len bytes after get_bits() and before<br /> get_uint().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_conntrack_sip: fix Content-Length u32 truncation in sip_help_tcp()<br /> <br /> sip_help_tcp() parses the SIP Content-Length header with<br /> simple_strtoul(), which returns unsigned long, but stores the result in<br /> unsigned int clen. On 64-bit systems, values exceeding UINT_MAX are<br /> silently truncated before computing the SIP message boundary.<br /> <br /> For example, Content-Length 4294967328 (2^32 + 32) is truncated to 32,<br /> causing the parser to miscalculate where the current message ends. The<br /> loop then treats trailing data in the TCP segment as a second SIP<br /> message and processes it through the SDP parser.<br /> <br /> Fix this by changing clen to unsigned long to match the return type of<br /> simple_strtoul(), and reject Content-Length values that exceed the<br /> remaining TCP payload length.

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 /> 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: 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 /> 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 /> 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 /> 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