Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ovpn: fix peer refcount leak in TCP error paths<br /> <br /> When either the TCP RX or TX error path calls ovpn_peer_hold() followed<br /> by schedule_work(&amp;peer-&gt;tcp.defer_del_work), and the work item is already<br /> pending from the other path, schedule_work() returns false and the work<br /> runs only once. Since ovpn_tcp_peer_del_work() calls ovpn_peer_put()<br /> exactly once, the extra reference taken by the losing path is never<br /> dropped, leaking the peer object.<br /> <br /> The race window:<br /> <br /> CPU0 (strparser/RX error): CPU1 (tcp_tx_work/TX error):<br /> ovpn_peer_hold()

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mac802154: hold an interface reference across the scan worker<br /> <br /> mac802154_scan_worker() captures the scanning sub-interface under RCU<br /> and then keeps dereferencing sdata-&gt;dev after rcu_read_unlock() and<br /> outside the rtnl -- in the failure traces, in<br /> mac802154_transmit_beacon_req() (skb-&gt;dev = sdata-&gt;dev), and in the<br /> end_scan cleanup. Nothing keeps that netdev alive across the worker<br /> iteration.<br /> <br /> A concurrent DEL_INTERFACE or PHY removal can unregister the interface<br /> once the worker drops the rtnl between its two drv_set_channel()<br /> sections. unregister_netdevice() frees the netdev asynchronously from<br /> netdev_run_todo() with the rtnl already dropped, so neither holding the<br /> rtnl nor the per-PHY IEEE802154_IS_SCANNING flag prevents a stale worker<br /> iteration from dereferencing the freed netdev -- a KASAN<br /> slab-use-after-free, reachable by racing TRIGGER_SCAN against<br /> DEL_INTERFACE (both CAP_NET_ADMIN).<br /> <br /> Pin the netdev with netdev_hold() while the RCU read lock is still held,<br /> and release it at every worker exit.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pppoe: reload header pointer after dev_hard_header()<br /> <br /> pppoe_sendmsg() saves a pointer to the PPPoE header before calling<br /> dev_hard_header(). Device header callbacks are allowed to reallocate the<br /> skb head, invalidating pointers into it.<br /> <br /> This can happen when a send is blocked in copy_from_user() while the first<br /> non-Ethernet port is added to an empty team device. The team&amp;#39;s delegated<br /> GRE header callback then expands the skb head. PPPoE subsequently writes<br /> six bytes through the stale pointer into the freed head.<br /> <br /> Reload the PPPoE header through the skb&amp;#39;s network-header offset after<br /> device header creation. pskb_expand_head() updates that offset when it<br /> relocates the head.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> openvswitch: fix GSO userspace truncation underflow<br /> <br /> OVS_ACTION_ATTR_TRUNC currently stores a delta from the original skb<br /> length in OVS_CB(skb)-&gt;cutlen. When a later userspace action segments a<br /> GSO skb, queue_gso_packets() reuses that delta for each smaller segment.<br /> A segment can then reach queue_userspace_packet() with cutlen greater<br /> than skb-&gt;len, underflowing the length passed to skb_zerocopy().<br /> <br /> Store the maximum preserved length instead and bound each consumer<br /> against the current skb length. Use U32_MAX as the no-truncation<br /> sentinel so the value remains valid if skb geometry changes before a<br /> consumer handles it.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mctp: serial: handle zero-length frames to prevent rx buffer overflow<br /> <br /> The MCTP serial receive state machine reads a frame length byte in<br /> mctp_serial_push_header() case 2 and validates it upper-bound-only:<br /> <br /> if (c &gt; MCTP_SERIAL_FRAME_MTU) {<br /> dev-&gt;rxstate = STATE_ERR;<br /> } else {<br /> dev-&gt;rxlen = c;<br /> dev-&gt;rxpos = 0;<br /> dev-&gt;rxstate = STATE_DATA;<br /> ...<br /> }<br /> <br /> A length of zero passes this check, so rxlen is set to 0 and the state<br /> machine advances to STATE_DATA. In mctp_serial_push() STATE_DATA, the<br /> incoming byte is stored and rxpos incremented before the terminator is<br /> <br /> dev-&gt;rxbuf[dev-&gt;rxpos] = c;<br /> dev-&gt;rxpos++;<br /> dev-&gt;rxstate = STATE_DATA;<br /> if (dev-&gt;rxpos == dev-&gt;rxlen) {<br /> dev-&gt;rxpos = 0;<br /> dev-&gt;rxstate = STATE_TRAILER;<br /> }<br /> <br /> With rxlen == 0 the "rxpos == rxlen" terminator can never fire (rxpos is<br /> already 1 on the first data byte), so subsequent bytes are written past<br /> the end of the fixed 74-byte rxbuf, which is the last member of the<br /> netdev private area. Every following data byte is an attacker-controlled<br /> 1-byte out-of-bounds heap write, and the overflow continues until a<br /> frame (0x7e) or escape byte resets the parser -- effectively unbounded.<br /> <br /> Reaching this requires CAP_NET_ADMIN to attach the N_MCTP line<br /> discipline and bring the resulting mctpserialN netdev up, after which<br /> the bytes arrive via the tty receive path.<br /> <br /> Route a zero-length frame straight to STATE_TRAILER instead of<br /> STATE_DATA. The trailer/framing bytes are still consumed, and the frame<br /> resolves to a zero-length skb that the MCTP core rejects; the parser<br /> never enters STATE_DATA with rxlen == 0, so the out-of-bounds write can<br /> no longer occur.<br /> <br /> KASAN, on a frame of 0x7e 0x01 0x00 followed by data bytes (before this<br /> change):<br /> <br /> UBSAN: array-index-out-of-bounds in drivers/net/mctp/mctp-serial.c:370<br /> index 74 is out of range for type &amp;#39;u8 [74]&amp;#39;<br /> BUG: KASAN: slab-out-of-bounds in mctp_serial_tty_receive_buf<br /> Write of size 1 at addr ... by task kworker/u16:0<br /> mctp_serial_tty_receive_buf<br /> tty_ldisc_receive_buf<br /> flush_to_ldisc<br /> Allocated by task 152:<br /> alloc_netdev_mqs<br /> mctp_serial_open<br /> <br /> v2: route zero-length frames to STATE_TRAILER instead of STATE_ERR so<br /> the trailer/framing bytes are still consumed (Jeremy Kerr).<br /> <br /> Found by 0sec automated security-research tooling (https://0sec.ai).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mac802154: llsec: reject frames shorter than the authentication tag<br /> <br /> llsec_do_decrypt_auth() computes the associated-data length for the<br /> AEAD request as<br /> <br /> assoclen += datalen - authlen;<br /> <br /> where datalen is the number of bytes after the MAC header and authlen<br /> (4, 8 or 16) is the length of the authentication tag. Nothing verifies<br /> that the frame actually carries at least authlen payload bytes. A<br /> secured frame whose payload is shorter than the tag makes<br /> datalen - authlen negative; assoclen is then passed to<br /> aead_request_set_ad() as an unsigned value close to 4 GiB, so<br /> crypto_aead_decrypt() walks far off the end of the scatterlist that<br /> only spans the real frame.<br /> <br /> The frame is fully attacker-controlled and reaches this path from any<br /> IEEE 802.15.4 peer in radio range. Reject frames whose payload is<br /> shorter than the authentication tag before the subtraction.<br /> <br /> Dynamically reproduced on a KASAN kernel as a general-protection-fault<br /> in the AEAD scatterwalk, and the fix confirmed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ila: reload IPv6 header after pskb_may_pull in checksum adjust<br /> <br /> ila_csum_adjust_transport() caches ip6h = ipv6_hdr(skb) before calling<br /> pskb_may_pull(). On a non-linear skb whose transport header sits in a page<br /> fragment, pskb_may_pull() can call __pskb_pull_tail() / pskb_expand_head()<br /> and free the old skb head, leaving ip6h dangling; the following<br /> get_csum_diff(ip6h, p) then reads freed memory. ila_update_ipv6_locator()<br /> uses ip6h (and the iaddr derived from it) again after the csum-adjust<br /> call and additionally writes the new locator through that pointer.<br /> <br /> Impact: a remote IPv6 packet routed through a configured ILA<br /> csum-adjust-transport route or receive-side mapping triggers a<br /> slab-use-after-free in ila_update_ipv6_locator() (KASAN). The route or<br /> mapping requires CAP_NET_ADMIN to configure, but trigger packets are<br /> unauthenticated once it exists.<br /> <br /> Reload ip6h after each pskb_may_pull() in ila_csum_adjust_transport()<br /> before the csum-diff read. In ila_update_ipv6_locator() only the<br /> ILA_CSUM_ADJUST_TRANSPORT case pulls the skb, so reload ip6h and iaddr in<br /> that case alone before the destination-address write; the neutral-map<br /> modes never pull and keep their cached pointers.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vxlan: mdb: Fix source list corruption on a failed replace<br /> <br /> When replacing the source list of an MDB remote entry, all existing<br /> sources are first marked for deletion and vxlan_mdb_remote_srcs_add()<br /> is then called to add the new source list. Sources present in the new<br /> list have their deletion mark cleared, and any sources left marked<br /> afterwards are removed.<br /> <br /> If vxlan_mdb_remote_srcs_add() fails partway through, its error path<br /> deletes all entries on the remote&amp;#39;s source list. That rollback is only<br /> correct for its other caller, vxlan_mdb_remote_add(), where the remote<br /> was just allocated and the list contains solely entries added during<br /> the call. On the replace path the list also holds pre-existing sources,<br /> so a failed replace tears them down together with their (S, G)<br /> forwarding entries instead of leaving the entry unchanged.<br /> <br /> This is reachable from an existing (*, G) remote. An EXCLUDE filter<br /> that loses sources starts forwarding traffic that should be blocked,<br /> while an INCLUDE filter that loses sources drops traffic that should be<br /> forwarded.<br /> <br /> Mark entries created during the current pass with a new<br /> VXLAN_SGRP_F_NEW flag. On failure, delete only those entries and clear<br /> the deletion mark on the pre-existing ones, so a failed replace leaves<br /> the source list untouched. Retain the flag until the whole operation<br /> succeeds and then clear it. Also stop vxlan_mdb_remote_src_add() from<br /> deleting a pre-existing entry it only looked up when adding that<br /> entry&amp;#39;s forwarding entry fails.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: challenge ACK for non-exact RST in SYN-RECEIVED<br /> <br /> The SYN-RECEIVED request-socket path in tcp_check_req() accepts an<br /> in-window RST without requiring SEG.SEQ to exactly match RCV.NXT. A<br /> non-exact RST therefore removes the request instead of eliciting a<br /> challenge ACK.<br /> <br /> RFC 9293 section 3.10.7.4 applies the RFC 5961 reset check in<br /> SYN-RECEIVED: an exact RST resets the connection, while a non-exact<br /> in-window RST must trigger a challenge ACK and be dropped.<br /> <br /> Apply that check before the ACK-field validation, following the RFC<br /> sequence-number, RST, then ACK processing order. Factor the per-netns<br /> challenge ACK quota out of tcp_send_challenge_ack() so request sockets<br /> can share it. Use the request socket&amp;#39;s send_ack() callback and its own<br /> out-of-window ACK timestamp to send and rate-limit the response.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: initialize standalone TCP-AO response padding<br /> <br /> tcp_v4_send_ack() and tcp_v6_send_response() construct standalone TCP<br /> responses with TCP-AO options. The option length carries the actual MAC<br /> length, but the TCP header length includes the option rounded up to a<br /> four-byte boundary.<br /> <br /> tcp_ao_hash_hdr() writes the MAC only. Thus, when the MAC length is not<br /> four-byte aligned, the one to three bytes after the MAC are left<br /> uninitialized and may be transmitted. For the normal TCP-AO hashing<br /> mode, those bytes also have to be initialized before computing the MAC.<br /> <br /> Initialize only the alignment padding in the TCP-AO branches, before<br /> hashing the header. Use TCPOPT_NOP, as in the normal TCP-AO output path.<br /> This avoids adding work to non-AO TCP responses while preserving a valid<br /> authenticated header.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu/gfx9.4.3: replace BUG_ON() with WARN_ON()<br /> <br /> There&amp;#39;s no need to crash the kernel for these cases.<br /> <br /> (cherry picked from commit 5676593d08998d7a6d9e2d51d6b54b3820e3755c)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu/gfx12: replace BUG_ON() with WARN_ON()<br /> <br /> There&amp;#39;s no need to crash the kernel for these cases.<br /> <br /> (cherry picked from commit f952076f76d62f783e8ba4995a7c400d39354ccf)