Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: capture fast-RX rate before mesh reuses skb-&gt;cb<br /> <br /> ieee80211_invoke_fast_rx() reads RX status through<br /> IEEE80211_SKB_RXCB(skb), which aliases the same skb-&gt;cb storage<br /> that ieee80211_rx_mesh_data() reuses as IEEE80211_TX_INFO. In the<br /> unicast forward path, mesh_data does:<br /> <br /> info = IEEE80211_SKB_CB(fwd_skb);<br /> memset(info, 0, sizeof(*info));<br /> <br /> on the same skb the caller still names via rx-&gt;skb, then either<br /> queues the skb for TX (success) or kfree_skb()&amp;#39;s it (no-route)<br /> before returning RX_QUEUED. The caller&amp;#39;s RX_QUEUED arm then<br /> calls sta_stats_encode_rate(status) on memory that is either<br /> zeroed (success path) or freed (no-route path). The latter is<br /> KASAN slab-use-after-free in ieee80211_prepare_and_rx_handle.<br /> <br /> Fix by encoding the rate from status before invoking<br /> ieee80211_rx_mesh_data(), so the RX_QUEUED arm consumes a value<br /> captured while status was still backed by valid memory.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> qed: fix double free in qed_cxt_tables_alloc()<br /> <br /> If one of the later PF or VF CID bitmap allocations fails,<br /> qed_cid_map_alloc() jumps to cid_map_fail and frees the previously<br /> allocated CID bitmaps before returning an error. qed_cxt_tables_alloc()<br /> then calls qed_cxt_mngr_free(), which invokes qed_cid_map_free()<br /> again.<br /> <br /> Fix this by setting each CID bitmap pointer to NULL after bitmap_free()<br /> to avoid double free.<br /> <br /> The bug was first flagged by an experimental analysis tool we are<br /> developing for kernel memory-management bugs while analyzing<br /> v6.13-rc1. The tool is still under development and is not yet publicly<br /> available. Manual inspection confirms that the bug is still<br /> present in v7.1-rc3.<br /> <br /> Runtime reproduction was not attempted because exercising the failing<br /> allocation path requires device-specific setup.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Fix use-after-free in mlx5e_tx_reporter_timeout_recover<br /> <br /> mlx5e_tx_reporter_timeout_recover() accesses sq-&gt;netdev after<br /> mlx5e_safe_reopen_channels() has torn down and freed the channel (and<br /> its embedded SQs). Replace the three sq-&gt;netdev references with<br /> priv-&gt;netdev which is safe because priv outlives channel teardown.<br /> <br /> The netdev_err() call already used priv-&gt;netdev for this reason; make<br /> the trylock/unlock and health_channel_eq_recover calls consistent.<br /> <br /> This fixes the following KASAN splat:<br /> <br /> BUG: KASAN: use-after-free in mlx5e_tx_reporter_timeout_recover+0x1dd/0x360 [mlx5_core]<br /> Read of size 8 at addr ffff889860ed0b28 by task kworker/u113:2/5277<br /> <br /> Call Trace:<br /> mlx5e_tx_reporter_timeout_recover+0x1dd/0x360 [mlx5_core]<br /> devlink_health_reporter_recover+0xa2/0x150<br /> devlink_health_report+0x254/0x7c0<br /> mlx5e_reporter_tx_timeout+0x297/0x380 [mlx5_core]<br /> mlx5e_tx_timeout_work+0x109/0x170 [mlx5_core]<br /> process_one_work+0x677/0xf20<br /> worker_thread+0x51f/0xd90<br /> kthread+0x3a5/0x810<br /> ret_from_fork+0x208/0x400<br /> ret_from_fork_asm+0x1a/0x30

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hsr: defer node table free until after RCU readers<br /> <br /> HSR node-list and node-status generic-netlink operations run under<br /> rcu_read_lock(). They walk hsr-&gt;node_db through hsr_get_next_node() and<br /> hsr_get_node_data(), but RTM_DELLINK teardown removes the same node table<br /> with plain list_del() and frees each node immediately.<br /> <br /> That lets a generic-netlink reader hold a struct hsr_node pointer across<br /> hsr_dellink(). In a KASAN build, widening the reader window after<br /> hsr_get_next_node() obtains the node reproduces a slab-use-after-free<br /> when the reader copies node-&gt;macaddress_A; the freeing stack is<br /> hsr_del_nodes() from hsr_dellink().<br /> <br /> Use list_del_rcu() and defer the free through the existing<br /> hsr_free_node_rcu() callback. This matches the lifetime rule used by the<br /> HSR prune paths, which already delete nodes with list_del_rcu() and<br /> call_rcu().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> l2tp: use list_del_rcu in l2tp_session_unhash<br /> <br /> An unprivileged local user can pin a host CPU indefinitely in<br /> l2tp_session_get_by_ifname() by issuing L2TP_CMD_SESSION_GET on<br /> L2TP_ATTR_IFNAME concurrently with L2TP_CMD_SESSION_CREATE and<br /> L2TP_CMD_SESSION_DELETE on the same tunnel. All three commands take<br /> GENL_UNS_ADMIN_PERM, so CAP_NET_ADMIN in the netns user namespace<br /> suffices; on any host that has l2tp_core loaded the trigger is<br /> reachable from a standard `unshare -Urn` sandbox.<br /> <br /> l2tp_session_unhash() removes a session from tunnel-&gt;session_list<br /> with list_del_init(), but that list is walked by<br /> l2tp_session_get_by_ifname() with list_for_each_entry_rcu() under<br /> rcu_read_lock_bh(). list_del_init() leaves the deleted entry&amp;#39;s<br /> next/prev self-pointing; a reader that has loaded the entry and<br /> then advances pos-&gt;list.next reads &amp;session-&gt;list, container_of()s<br /> back to the same session, and list_for_each_entry_rcu() never<br /> reaches the list head. The CPU stays in strcmp() inside the<br /> walker, with BH and preemption disabled, so RCU grace periods on<br /> the host stall behind it and the wedged thread cannot be killed<br /> (SIGKILL is delivered on syscall return).<br /> <br /> Use list_del_rcu() to match the existing list_add_rcu() in<br /> l2tp_session_register(); the deleted session remains visible to<br /> in-flight walkers with consistent next/prev pointers until<br /> kfree_rcu() in l2tp_session_free() releases it. tunnel-&gt;session_list<br /> has exactly one list_del_init() call site; the list_del_init<br /> (&amp;session-&gt;clist) at l2tp_core.c:533 operates on the per-collision<br /> list, which is not walked under RCU. list_empty(&amp;session-&gt;list) is<br /> not used anywhere in net/l2tp/ after the unhash point, so dropping<br /> the post-delete self-init is safe; the fix has no userspace-visible<br /> behavior change.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ethtool: fix NULL pointer dereference in phy_reply_size<br /> <br /> In phy_prepare_data(), several strings such as &amp;#39;name&amp;#39;, &amp;#39;drvname&amp;#39;,<br /> &amp;#39;upstream_sfp_name&amp;#39;, and &amp;#39;downstream_sfp_name&amp;#39; are allocated using<br /> kstrdup(). However, these allocations were not checked for failure.<br /> <br /> If kstrdup() fails for &amp;#39;name&amp;#39;, it returns NULL while the function<br /> continues. This leads to a kernel NULL pointer dereference and panic<br /> later in phy_reply_size() when it unconditionally calls strlen() on<br /> the NULL pointer.<br /> <br /> While other strings like &amp;#39;upstream_sfp_name&amp;#39; might be checked before<br /> access in certain code paths, failing to handle these allocations<br /> consistently can lead to incomplete data reporting or hidden bugs.<br /> <br /> Fix this by adding proper NULL checks for all kstrdup() calls in<br /> phy_prepare_data() and implement a centralized error handling path<br /> using goto labels to ensure all previously allocated resources are<br /> freed on failure.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ifb: report ethtool stats over num_tx_queues<br /> <br /> ifb_dev_init() allocates dp-&gt;tx_private to dev-&gt;num_tx_queues<br /> entries via kzalloc_objs(*txp, dev-&gt;num_tx_queues). Both IFB<br /> per-queue RX and TX stats live in those entries: ifb_xmit() updates<br /> txp-&gt;rx_stats using the skb queue mapping, ifb_ri_tasklet() updates<br /> txp-&gt;tx_stats, and ifb_stats64() aggregates both over<br /> dev-&gt;num_tx_queues.<br /> <br /> The ethtool stats callbacks instead size and walk the per-queue<br /> stats with dev-&gt;real_num_rx_queues and dev-&gt;real_num_tx_queues. With<br /> an asymmetric device where the RX queue count exceeds the TX queue<br /> count, for example:<br /> <br /> ip link add name ifb10 numtxqueues 1 numrxqueues 8 type ifb<br /> ethtool -S ifb10<br /> <br /> ifb_get_ethtool_stats() indexes past the tx_private allocation and<br /> copies adjacent slab data through ETHTOOL_GSTATS.<br /> <br /> Use dev-&gt;num_tx_queues consistently for the stats strings, the<br /> stats count, and the stats data walks. This reports one RX stats<br /> group and one TX stats group for each backing ifb_q_private entry,<br /> which is the queue set IFB can actually populate.<br /> <br /> Reproduced under UML+KASAN at v7.1-rc2:<br /> <br /> BUG: KASAN: slab-out-of-bounds in ifb_fill_stats_data+0x3c/0xae<br /> Read of size 8 at addr 0000000062dbd228 by task ethtool/36<br /> ifb_fill_stats_data+0x3c/0xae<br /> ifb_get_ethtool_stats+0xc0/0x129<br /> __dev_ethtool+0x1ca5/0x363c<br /> dev_ethtool+0x123/0x1b3<br /> dev_ioctl+0x56c/0x744<br /> sock_do_ioctl+0x15f/0x1b2<br /> sock_ioctl+0x4d5/0x50a<br /> sys_ioctl+0xd8b/0xde9<br /> <br /> With the patch applied, the same UML+KASAN repro is silent and<br /> ethtool -S ifb10 reports only the stats backed by the single<br /> allocated tx_private entry.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: Fix busy dentry used after unmounting<br /> <br /> Since commit 340cea84f691c ("cifs: open files should not hold ref on<br /> superblock"), cifs file only holds the dentry ref_cnt, the cifs file<br /> close work(cfile-&gt;deferred) could be executed after unmounting, which<br /> will trigger a warning in generic_shutdown_super:<br /> BUG: Dentry 00000000a14a6845{i=c,n=file} still in use (1) [unmount of<br /> cifs cifs]<br /> <br /> The detailed processs is:<br /> process A process B kworker<br /> fd = open(PATH)<br /> vfs_open<br /> file-&gt;__f_path = *path // dentry-&gt;d_lockref.count = 1<br /> cifs_open<br /> cifs_new_fileinfo<br /> cfile-&gt;dentry = dget(dentry) // dentry-&gt;d_lockref.count = 2<br /> close(fd)<br /> __fput<br /> cifs_close<br /> queue_delayed_work(deferredclose_wq, cfile-&gt;deferred)<br /> dput(dentry) // dentry-&gt;d_lockref.count = 1<br /> smb2_deferred_work_close<br /> _cifsFileInfo_put<br /> list_del(&amp;cifs_file-&gt;flist)<br /> umount<br /> cleanup_mnt<br /> deactivate_super<br /> cifs_kill_sb<br /> cifs_close_all_deferred_files_sb<br /> cifs_close_all_deferred_files<br /> // cannot find cfile, skip _cifsFileInfo_put<br /> kill_anon_super<br /> generic_shutdown_super<br /> shrink_dcache_for_umount<br /> umount_check<br /> WARN ! // dentry-&gt;d_lockref.count = 1<br /> cifsFileInfo_put_final<br /> dput(cifs_file-&gt;dentry)<br /> // dentry-&gt;d_lockref.count = 0<br /> <br /> Fix it by flushing &amp;#39;deferredclose_wq&amp;#39; before calling kill_anon_super.<br /> <br /> Fetch a reproducer in https://bugzilla.kernel.org/show_bug.cgi?id=221548.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> af_unix: Fix UAF read of tail-&gt;len in unix_stream_data_wait()<br /> <br /> unix_stream_data_wait() does skb_peek_tail(&amp;sk-&gt;sk_receive_queue) without<br /> holding any lock that prevents SKBs on that queue from being dequeued and<br /> freed.<br /> This has been the case since commit 79f632c71bea ("unix/stream: fix<br /> peeking with an offset larger than data in queue").<br /> The first consequence of this is that the pointer comparison<br /> `tail != last` can be false even if `last` semantically refers to an<br /> already-freed SKB while `tail` is a new SKB allocated at the same address;<br /> which can cause unix_stream_data_wait() to wrongly keep blocking after new<br /> data has arrived, but only in a weird scenario where a peeking recv() and<br /> a normal recv() on the same socket are racing, which is probably not a<br /> real problem.<br /> <br /> But since commit 2b514574f7e8 ("net: af_unix: implement splice for stream<br /> af_unix sockets"), `tail` is actually dereferenced, which can cause UAF in<br /> the following race scenario (where test_setup() runs single-threaded,<br /> and afterwards, test_thread1() and test_thread2() run concurrently in<br /> two threads:<br /> ```<br /> static int socks[2];<br /> void test_setup(void) {<br /> socketpair(AF_UNIX, SOCK_STREAM, 0, socks);<br /> send(socks[1], "A", 1, 0);<br /> int peekoff = 1;<br /> setsockopt(socks[0], SOL_SOCKET, SO_PEEK_OFF, &amp;peekoff, sizeof(peekoff));<br /> }<br /> void test_thread1(void) {<br /> char dummy;<br /> recv(socks[0], &amp;dummy, 1, MSG_PEEK);<br /> }<br /> void test_thread2(void) {<br /> char dummy;<br /> recv(socks[0], &amp;dummy, 1, 0);<br /> shutdown(socks[1], SHUT_WR);<br /> }<br /> ```<br /> <br /> when racing like this:<br /> ```<br /> thread1 thread2<br /> unix_stream_read_generic<br /> mutex_lock(&amp;u-&gt;iolock)<br /> skb_peek(&amp;sk-&gt;sk_receive_queue)<br /> skb_peek_next(skb, &amp;sk-&gt;sk_receive_queue)<br /> mutex_unlock(&amp;u-&gt;iolock)<br /> unix_stream_read_generic<br /> unix_state_lock(sk)<br /> skb_peek(&amp;sk-&gt;sk_receive_queue)<br /> unix_state_unlock(sk)<br /> unix_stream_data_wait<br /> unix_state_lock(sk)<br /> tail = skb_peek_tail(&amp;sk-&gt;sk_receive_queue)<br /> spin_lock(&amp;sk-&gt;sk_receive_queue.lock)<br /> __skb_unlink(skb, &amp;sk-&gt;sk_receive_queue)<br /> spin_unlock(&amp;sk-&gt;sk_receive_queue.lock)<br /> consume_skb(skb) [frees the SKB]<br /> `tail != last`: false<br /> `tail`: true<br /> `tail-&gt;len != last_len` ***UAF***<br /> ```<br /> <br /> Fix the UAF by removing the read of tail-&gt;len; checking tail-&gt;len would<br /> only make sense if SKBs in the receive queue of a UNIX socket could grow,<br /> which can no longer happen.<br /> <br /> Kuniyuki explained:<br /> <br /> &gt; When commit 869e7c62486e ("net: af_unix: implement stream sendpage<br /> &gt; support") added sendpage() support, data could be appended to the last<br /> &gt; skb in the receiver&amp;#39;s queue.<br /> &gt;<br /> &gt; That&amp;#39;s why we needed to check if the length of the last skb was changed<br /> &gt; while waiting for new data in unix_stream_data_wait().<br /> &gt;<br /> &gt; However, commit a0dbf5f818f9 ("af_unix: Support MSG_SPLICE_PAGES") and<br /> &gt; commit 57d44a354a43 ("unix: Convert unix_stream_sendpage() to use<br /> &gt; MSG_SPLICE_PAGES") refactored sendmsg(), and now data is always added<br /> &gt; to a new skb.<br /> <br /> That means this fix is not suitable for kernels before 6.5.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ixgbevf: fix use-after-free in VEPA multicast source pruning<br /> <br /> ixgbevf_clean_rx_irq() prunes frames whose source MAC matches the VF&amp;#39;s<br /> own address (VEPA multicast workaround) by freeing the skb and<br /> continuing to the next descriptor:<br /> <br /> dev_kfree_skb_irq(skb);<br /> continue;<br /> <br /> The skb pointer is declared outside the while loop and persists across<br /> iterations. Because the continue skips the "skb = NULL" reset at the<br /> bottom of the loop, the next iteration enters the "else if (skb)" path<br /> and calls ixgbevf_add_rx_frag() on the freed skb, dereferencing<br /> skb_shinfo(skb)-&gt;nr_frags - a use-after-free in NAPI softirq context.<br /> <br /> The sibling driver iavf already handles this correctly by nulling the<br /> pointer before continuing. Apply the same pattern here.<br /> <br /> I do not have ixgbevf hardware; the bug was found by static analysis<br /> (scan_drop_continue_loops.py + semgrep drop_continue_in_loop, multi-tool<br /> corroboration with the highest score in the scan). The UAF was confirmed<br /> under KASAN by loading a test module that reproduces the exact code<br /> pattern (alloc skb, kfree_skb, then read skb_shinfo(skb)-&gt;nr_frags):<br /> <br /> BUG: KASAN: slab-use-after-free in ixgbevf_uaf_test_init+0x100/0x1000<br /> Read of size 8 at addr 000000006163ae78 by task insmod/30<br /> freed 208-byte region [000000006163adc0, 000000006163ae90)<br /> <br /> QEMU emulates igb (82576) but not ixgbe (82599), and the igbvf VF<br /> driver does not include the VEPA source pruning path, so a full<br /> end-to-end reproduction with emulated hardware was not possible.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv4: raw: reject IP_HDRINCL packets with ihl ihl * 4;<br /> err = -EINVAL;<br /> if (iphlen &gt; length)<br /> goto error_free;<br /> <br /> if (iphlen &gt;= sizeof(*iph)) {<br /> /* fix up saddr, tot_len, id, csum, transport_header */<br /> }<br /> <br /> It does not, however, reject ihl = sizeof(*iph))" branch is skipped, leaving the<br /> crafted iphdr untouched, but the packet is still handed to<br /> __ip_local_out() and onward. Downstream consumers that read<br /> iph-&gt;ihl assume a sane value: net/ipv4/ah4.c:ah_output() in<br /> particular subtracts sizeof(struct iphdr) from top_iph-&gt;ihl * 4<br /> and passes the (signed-int-negative, then cast to size_t)<br /> result to memcpy(), producing an OOB access of length close to<br /> SIZE_MAX and a host kernel panic.<br /> <br /> An IPv4 header with ihl = sizeof(*iph))" wrapper around<br /> the fixup branch becomes redundant; left in place to keep the<br /> patch minimal and backport-friendly. A follow-up can unwrap it.<br /> <br /> Note that commit 86f4c90a1c5c ("ipv4, ipv6: ensure raw socket<br /> message is big enough to hold an IP header") ensures the message<br /> buffer is large enough to hold an iphdr, but does not constrain<br /> the self-reported iph-&gt;ihl.<br /> <br /> Reachability: the malformed packet source is any caller with<br /> CAP_NET_RAW, including an unprivileged process in a user+net<br /> namespace on a kernel with CONFIG_USER_NS=y. The reproduced AH<br /> crash also requires a matching xfrm AH policy on the outgoing<br /> route; a container granted CAP_NET_ADMIN can install that state<br /> and policy in its netns. Loopback bypasses xfrm_output, so the<br /> trigger uses a real netdev.<br /> <br /> Reproduced on UML + KASAN: kernel-mode fault at addr 0x0 with<br /> memcpy_orig at the crash site. Same shape reproduces inside a<br /> rootless Docker container with --cap-add NET_ADMIN on a stock<br /> distro kernel.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vsock/vmci: fix UAF when peer resets connection during handshake<br /> <br /> vmci_transport_recv_connecting_server() returned err = 0 for a peer<br /> RST in its default switch arm:<br /> <br /> err = pkt-&gt;type == VMCI_TRANSPORT_PACKET_TYPE_RST ? 0 : -EINVAL;<br /> <br /> That made vmci_transport_recv_listen() skip vsock_remove_pending(),<br /> leaving the pending socket on the listener&amp;#39;s pending_links with<br /> sk_state = TCP_CLOSE while destroy: still dropped the explicit<br /> reference taken before schedule_delayed_work().<br /> <br /> One second later vsock_pending_work() observed is_pending=true and<br /> performed full cleanup: vsock_remove_pending() then the two trailing<br /> sock_put(sk) calls -- the first reached refcount 0 and __sk_freed<br /> the socket, and the second wrote into the freed object:<br /> <br /> BUG: KASAN: slab-use-after-free in refcount_warn_saturate<br /> Write of size 4 at addr ffff88800b1cac80 by task kworker<br /> Workqueue: events vsock_pending_work<br /> <br /> Treat peer RST like any other unexpected packet type (err = -EINVAL).<br /> All destroy: arms now return err