Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: fix double-free of tx_buf skb<br /> <br /> If ice_tso() or ice_tx_csum() fail, the error path in<br /> ice_xmit_frame_ring() frees the skb, but the &amp;#39;first&amp;#39; tx_buf still points<br /> to it and is marked as valid (ICE_TX_BUF_SKB).<br /> &amp;#39;next_to_use&amp;#39; remains unchanged, so the potential problem will<br /> likely fix itself when the next packet is transmitted and the tx_buf<br /> gets overwritten. But if there is no next packet and the interface is<br /> brought down instead, ice_clean_tx_ring() -&gt; ice_unmap_and_free_tx_buf()<br /> will find the tx_buf and free the skb for the second time.<br /> <br /> The fix is to reset the tx_buf type to ICE_TX_BUF_EMPTY in the error<br /> path, so that ice_unmap_and_free_tx_buf().<br /> Move the initialization of &amp;#39;first&amp;#39; up, to ensure it&amp;#39;s already valid in<br /> case we hit the linearization error path.<br /> <br /> The bug was spotted by AI while I had it looking for something else.<br /> It also proposed an initial version of the patch.<br /> <br /> I reproduced the bug and tested the fix by adding code to inject<br /> failures, on a build with KASAN.<br /> <br /> I looked for similar bugs in related Intel drivers and did not find any.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nat: use kfree_rcu to release ops<br /> <br /> Florian Westphal says:<br /> <br /> "Historically this is not an issue, even for normal base hooks: the data<br /> path doesn&amp;#39;t use the original nf_hook_ops that are used to register the<br /> callbacks.<br /> <br /> However, in v5.14 I added the ability to dump the active netfilter<br /> hooks from userspace.<br /> <br /> This code will peek back into the nf_hook_ops that are available<br /> at the tail of the pointer-array blob used by the datapath.<br /> <br /> The nat hooks are special, because they are called indirectly from<br /> the central nat dispatcher hook. They are currently invisible to<br /> the nfnl hook dump subsystem though.<br /> <br /> But once that changes the nat ops structures have to be deferred too."<br /> <br /> Update nf_nat_register_fn() to deal with partial exposition of the hooks<br /> from error path which can be also an issue for nfnetlink_hook.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: conntrack: remove sprintf usage<br /> <br /> Replace it with scnprintf, the buffer sizes are expected to be large enough<br /> to hold the result, no need for snprintf+overflow check.<br /> <br /> Increase buffer size in mangle_content_len() while at it.<br /> <br /> BUG: KASAN: stack-out-of-bounds in vsnprintf+0xea5/0x1270<br /> Write of size 1 at addr [..]<br /> vsnprintf+0xea5/0x1270<br /> sprintf+0xb1/0xe0<br /> mangle_content_len+0x1ac/0x280<br /> nf_nat_sdp_session+0x1cc/0x240<br /> process_sdp+0x8f8/0xb80<br /> process_invite_request+0x108/0x2b0<br /> process_sip_msg+0x5da/0xf50<br /> sip_help_tcp+0x45e/0x780<br /> nf_confirm+0x34d/0x990<br /> [..]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: fix potential NULL pointer deref in error path of ice_set_ringparam()<br /> <br /> ice_set_ringparam nullifies tstamp_ring of temporary tx_rings, without<br /> clearing ICE_TX_RING_FLAGS_TXTIME bit.<br /> When ICE_TX_RING_FLAGS_TXTIME is set and the subsequent<br /> ice_setup_tx_ring() call fails, a NULL pointer dereference could happen<br /> in the unwinding sequence:<br /> <br /> ice_clean_tx_ring()<br /> -&gt; ice_is_txtime_cfg() == true (ICE_TX_RING_FLAGS_TXTIME is set)<br /> -&gt; ice_free_tx_tstamp_ring()<br /> -&gt; ice_free_tstamp_ring()<br /> -&gt; tstamp_ring-&gt;desc (NULL deref)<br /> <br /> Clear ICE_TX_RING_FLAGS_TXTIME bit to avoid the potential issue.<br /> <br /> Note that this potential issue is found by manual code review.<br /> Compile test only since unfortunately I don&amp;#39;t have E830 devices.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: fix OOB write to userspace in sctp_getsockopt_peer_auth_chunks<br /> <br /> sctp_getsockopt_peer_auth_chunks() checks that the caller&amp;#39;s optval<br /> buffer is large enough for the peer AUTH chunk list with<br /> <br /> if (len gauth_chunks, which lives<br /> at offset offsetof(struct sctp_authchunks, gauth_chunks) == 8<br /> inside optval. The check is missing the sizeof(struct<br /> sctp_authchunks) = 8-byte header. When the caller supplies<br /> len == num_chunks (for any num_chunks &gt; 0) the test passes but<br /> copy_to_user() writes sizeof(struct sctp_authchunks) = 8 bytes<br /> past the declared buffer.<br /> <br /> The sibling function sctp_getsockopt_local_auth_chunks() at the<br /> next line already has the correct check:<br /> <br /> if (len

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pppoe: drop PFC frames<br /> <br /> RFC 2516 Section 7 states that Protocol Field Compression (PFC) is NOT<br /> RECOMMENDED for PPPoE. In practice, pppd does not support negotiating<br /> PFC for PPPoE sessions, and the current PPPoE driver assumes an<br /> uncompressed (2-byte) protocol field. However, the generic PPP layer<br /> function ppp_input() is not aware of the negotiation result, and still<br /> accepts PFC frames.<br /> <br /> If a peer with a broken implementation or an attacker sends a frame with<br /> a compressed (1-byte) protocol field, the subsequent PPP payload is<br /> shifted by one byte. This causes the network header to be 4-byte<br /> misaligned, which may trigger unaligned access exceptions on some<br /> architectures.<br /> <br /> To reduce the attack surface, drop PPPoE PFC frames. Introduce<br /> ppp_skb_is_compressed_proto() helper function to be used in both<br /> ppp_generic.c and pppoe.c to avoid open-coding.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: xtables: restrict several matches to inet family<br /> <br /> This is a partial revert of:<br /> <br /> commit ab4f21e6fb1c ("netfilter: xtables: use NFPROTO_UNSPEC in more extensions")<br /> <br /> to allow ipv4 and ipv6 only.<br /> <br /> - xt_mac<br /> - xt_owner<br /> - xt_physdev<br /> <br /> These extensions are not used by ebtables in userspace.<br /> <br /> Moreover, xt_realm is only for ipv4, since dst-&gt;tclassid is ipv4<br /> specific.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> af_unix: Drop all SCM attributes for SOCKMAP.<br /> <br /> SOCKMAP can hide inflight fd from AF_UNIX GC.<br /> <br /> When a socket in SOCKMAP receives skb with inflight fd,<br /> sk_psock_verdict_data_ready() looks up the mapped socket and<br /> enqueue skb to its psock-&gt;ingress_skb.<br /> <br /> Since neither the old nor the new GC can inspect the psock<br /> queue, the hidden skb leaks the inflight sockets. Note that<br /> this cannot be detected via kmemleak because inflight sockets<br /> are linked to a global list.<br /> <br /> In addition, SOCKMAP redirect breaks the Tarjan-based GC&amp;#39;s<br /> assumption that unix_edge.successor is always alive, which<br /> is no longer true once skb is redirected, resulting in<br /> use-after-free below. [0]<br /> <br /> Moreover, SOCKMAP does not call scm_stat_del() properly,<br /> so unix_show_fdinfo() could report an incorrect fd count.<br /> <br /> sk_msg_recvmsg() does not support any SCM attributes in the<br /> first place.<br /> <br /> Let&amp;#39;s drop all SCM attributes before passing skb to the<br /> SOCKMAP layer.<br /> <br /> [0]:<br /> BUG: KASAN: slab-use-after-free in unix_del_edges (net/unix/garbage.c:118 net/unix/garbage.c:181 net/unix/garbage.c:251)<br /> Read of size 8 at addr ffff888125362670 by task kworker/56:1/496<br /> <br /> CPU: 56 UID: 0 PID: 496 Comm: kworker/56:1 Not tainted 7.0.0-rc7-00263-gb9d8b856689d #3 PREEMPT(lazy)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014<br /> Workqueue: events sk_psock_backlog<br /> Call Trace:<br /> <br /> dump_stack_lvl (lib/dump_stack.c:122)<br /> print_report (mm/kasan/report.c:379)<br /> kasan_report (mm/kasan/report.c:597)<br /> unix_del_edges (net/unix/garbage.c:118 net/unix/garbage.c:181 net/unix/garbage.c:251)<br /> unix_destroy_fpl (net/unix/garbage.c:317)<br /> unix_destruct_scm (./include/net/scm.h:80 ./include/net/scm.h:86 net/unix/af_unix.c:1976)<br /> sk_psock_backlog (./include/linux/skbuff.h:?)<br /> process_scheduled_works (kernel/workqueue.c:?)<br /> worker_thread (kernel/workqueue.c:?)<br /> kthread (kernel/kthread.c:438)<br /> ret_from_fork (arch/x86/kernel/process.c:164)<br /> ret_from_fork_asm (arch/x86/entry/entry_64.S:258)<br /> <br /> <br /> Allocated by task 955:<br /> kasan_save_track (mm/kasan/common.c:58 mm/kasan/common.c:78)<br /> __kasan_slab_alloc (mm/kasan/common.c:369)<br /> kmem_cache_alloc_noprof (mm/slub.c:4539)<br /> sk_prot_alloc (net/core/sock.c:2240)<br /> sk_alloc (net/core/sock.c:2301)<br /> unix_create1 (net/unix/af_unix.c:1099)<br /> unix_create (net/unix/af_unix.c:1169)<br /> __sock_create (net/socket.c:1606)<br /> __sys_socketpair (net/socket.c:1811)<br /> __x64_sys_socketpair (net/socket.c:1863 net/socket.c:1860 net/socket.c:1860)<br /> do_syscall_64 (arch/x86/entry/syscall_64.c:?)<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)<br /> <br /> Freed by task 496:<br /> kasan_save_track (mm/kasan/common.c:58 mm/kasan/common.c:78)<br /> kasan_save_free_info (mm/kasan/generic.c:587)<br /> __kasan_slab_free (mm/kasan/common.c:287)<br /> kmem_cache_free (mm/slub.c:6165)<br /> __sk_destruct (net/core/sock.c:2282 net/core/sock.c:2384)<br /> sk_psock_destroy (./include/net/sock.h:?)<br /> process_scheduled_works (kernel/workqueue.c:?)<br /> worker_thread (kernel/workqueue.c:?)<br /> kthread (kernel/kthread.c:438)<br /> ret_from_fork (arch/x86/kernel/process.c:164)<br /> ret_from_fork_asm (arch/x86/entry/entry_64.S:258)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: fix possible UAF in icmpv6_rcv()<br /> <br /> Caching saddr and daddr before pskb_pull() is problematic<br /> since skb-&gt;head can change.<br /> <br /> Remove these temporary variables:<br /> <br /> - We only access &amp;ipv6_hdr(skb)-&gt;saddr and &amp;ipv6_hdr(skb)-&gt;daddr<br /> when net_dbg_ratelimited() is called in the slow path.<br /> <br /> - Avoid potential future misuse after pskb_pull() call.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nfnetlink_osf: fix out-of-bounds read on option matching<br /> <br /> In nf_osf_match(), the nf_osf_hdr_ctx structure is initialized once<br /> and passed by reference to nf_osf_match_one() for each fingerprint<br /> checked. During TCP option parsing, nf_osf_match_one() advances the<br /> shared ctx-&gt;optp pointer.<br /> <br /> If a fingerprint perfectly matches, the function returns early without<br /> restoring ctx-&gt;optp to its initial state. If the user has configured<br /> NF_OSF_LOGLEVEL_ALL, the loop continues to the next fingerprint.<br /> However, because ctx-&gt;optp was not restored, the next call to<br /> nf_osf_match_one() starts parsing from the end of the options buffer.<br /> This causes subsequent matches to read garbage data and fail<br /> immediately, making it impossible to log more than one match or logging<br /> incorrect matches.<br /> <br /> Instead of using a shared ctx-&gt;optp pointer, pass the context as a<br /> constant pointer and use a local pointer (optp) for TCP option<br /> traversal. This makes nf_osf_match_one() strictly stateless from the<br /> caller&amp;#39;s perspective, ensuring every fingerprint check starts at the<br /> correct option offset.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nfnetlink_osf: fix potential NULL dereference in ttl check<br /> <br /> The nf_osf_ttl() function accessed skb-&gt;dev to perform a local interface<br /> address lookup without verifying that the device pointer was valid.<br /> <br /> Additionally, the implementation utilized an in_dev_for_each_ifa_rcu<br /> loop to match the packet source address against local interface<br /> addresses. It assumed that packets from the same subnet should not see a<br /> decrement on the initial TTL. A packet might appear it is from the same<br /> subnet but it actually isn&amp;#39;t especially in modern environments with<br /> containers and virtual switching.<br /> <br /> Remove the device dereference and interface loop. Replace the logic with<br /> a switch statement that evaluates the TTL according to the ttl_check.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: sch_dualpi2: drain both C-queue and L-queue in dualpi2_change()<br /> <br /> Fix dualpi2_change() to correctly enforce updated limit and memlimit<br /> values after a configuration change of the dualpi2 qdisc.<br /> <br /> Before this patch, dualpi2_change() always attempted to dequeue packets<br /> via the root qdisc (C-queue) when reducing backlog or memory usage, and<br /> unconditionally assumed that a valid skb will be returned. When traffic<br /> classification results in packets being queued in the L-queue while the<br /> C-queue is empty, this leads to a NULL skb dereference during limit or<br /> memlimit enforcement.<br /> <br /> This is fixed by first dequeuing from the C-queue path if it is<br /> non-empty. Once the C-queue is empty, packets are dequeued directly from<br /> the L-queue. Return values from qdisc_dequeue_internal() are checked for<br /> both queues. When dequeuing from the L-queue, the parent qdisc qlen and<br /> backlog counters are updated explicitly to keep overall qdisc statistics<br /> consistent.