Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: taprio: fix use-after-free in advance_sched() on schedule switch<br /> <br /> In advance_sched(), when should_change_schedules() returns true,<br /> switch_schedules() is called to promote the admin schedule to oper.<br /> switch_schedules() queues the old oper schedule for RCU freeing via<br /> call_rcu(), but &amp;#39;next&amp;#39; still points into an entry of the old oper<br /> schedule. The subsequent &amp;#39;next-&gt;end_time = end_time&amp;#39; and<br /> rcu_assign_pointer(q-&gt;current_entry, next) are use-after-free.<br /> <br /> Fix this by selecting &amp;#39;next&amp;#39; from the new oper schedule immediately<br /> after switch_schedules(), and using its pre-calculated end_time.<br /> setup_first_end_time() sets the first entry&amp;#39;s end_time to<br /> base_time + interval when the schedule is installed, so the value<br /> is already correct.<br /> <br /> The deleted &amp;#39;end_time = sched_base_time(admin)&amp;#39; assignment was also<br /> harmful independently: it would overwrite the new first entry&amp;#39;s<br /> pre-calculated end_time with just base_time.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix use-after-free in smb2_open during durable reconnect<br /> <br /> In smb2_open, the call to ksmbd_put_durable_fd(fp) drops the reference<br /> to the durable file descriptor early during the durable reconnect<br /> process. If an error occurs subsequently (eg, ksmbd_iov_pin_rsp fails)<br /> or a scavenger accesses the file, it leads to a use-after-free when<br /> accessing fp properties (eg fp-&gt;create_time).<br /> <br /> Move the single put to the end of the function below err_out2 so fp<br /> stays valid until smb2_open returns.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: fix race condition in TX timestamp ring cleanup<br /> <br /> Fix a race condition between ice_free_tx_tstamp_ring() and ice_tx_map()<br /> that can cause a NULL pointer dereference.<br /> <br /> ice_free_tx_tstamp_ring currently clears the ICE_TX_FLAGS_TXTIME flag<br /> after NULLing the tstamp_ring. This could allow a concurrent ice_tx_map<br /> call on another CPU to dereference the tstamp_ring, which could lead to<br /> a NULL pointer dereference.<br /> <br /> CPU A:ice_free_tx_tstamp_ring() | CPU B:ice_tx_map()<br /> --------------------------------|---------------------------------<br /> tx_ring-&gt;tstamp_ring = NULL |<br /> | ice_is_txtime_cfg() -&gt; true<br /> | tstamp_ring = tx_ring-&gt;tstamp_ring<br /> | tstamp_ring-&gt;count // NULL deref!<br /> flags &amp;= ~ICE_TX_FLAGS_TXTIME |<br /> <br /> Fix by:<br /> 1. Reordering ice_free_tx_tstamp_ring() to clear the flag before<br /> NULLing the pointer, with smp_wmb() to ensure proper ordering.<br /> 2. Adding smp_rmb() in ice_tx_map() after the flag check to order the<br /> flag read before the pointer read, using READ_ONCE() for the<br /> pointer, and adding a NULL check as a safety net.<br /> 3. Converting tx_ring-&gt;flags from u8 to DECLARE_BITMAP() and using<br /> atomic bitops (set_bit(), clear_bit(), test_bit()) for all flag<br /> operations throughout the driver:<br /> - ICE_TX_RING_FLAGS_XDP<br /> - ICE_TX_RING_FLAGS_VLAN_L2TAG1<br /> - ICE_TX_RING_FLAGS_VLAN_L2TAG2<br /> - ICE_TX_RING_FLAGS_TXTIME

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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 /> [..]

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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)

*** Pendiente de traducción *** 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.