Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rbd: Reset positive result codes to zero in object map update path<br /> <br /> In a reply message to an RBD request, a positive result code indicates<br /> a data payload, which is not allowed for writes. While<br /> rbd_osd_req_callback() already resets a positive result code for writes<br /> to zero, rbd_object_map_callback() does not. This allows a corrupted<br /> reply to an object map update to trigger the rbd_assert(*result <br /> __rbd_obj_handle_request() and passes this positive result code. From<br /> __rbd_obj_handle_request(), rbd_obj_advance_write() is called, which<br /> leaves the positive result code unchanged and returns true. Therefore,<br /> the if(done &amp;&amp; *result) branch is executed in __rbd_obj_handle_request()<br /> and the assertion triggers.<br /> <br /> This patch fixes the issue by adjusting the logic in the<br /> rbd_object_map_callback() path. A positive result code for an object map<br /> update is now reset to zero (similar to rbd_osd_req_callback()), and the<br /> message is subsequently handled the same way as if the result code was<br /> zero from the beginning. Additionally, a WARN_ON_ONCE() is added for<br /> this case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hip04: fix RX buffer leak on build_skb failure<br /> <br /> When build_skb() fails in hip04_rx_poll(), the driver jumps to the<br /> refill path without releasing the current RX buffer and its DMA mapping.<br /> Installing a replacement buffer then overwrites the slot references and<br /> leaks both resources.<br /> <br /> Keep the current slot intact and return budget so NAPI retries the same<br /> buffer. Also free a newly allocated RX fragment when dma_map_single()<br /> fails.<br /> <br /> This issue was found by an in-house static analysis tool.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rtase: Workaround for TX hang caused by hardware packet parsing<br /> <br /> The hardware performs packet parsing before packet transmission.<br /> Parsing incomplete IPv4, IPv6, TCP, or UDP headers may trigger a TX<br /> hang because the hardware parser expects additional protocol header<br /> data that is not present in the packet.<br /> <br /> The hardware performs additional PTP parsing on UDP packets identified<br /> by destination ports 319/320 at the expected UDP destination port<br /> offset.<br /> <br /> If such a packet has transport data smaller than RTASE_MIN_PAD_LEN,<br /> the hardware parser expects additional packet data and may trigger a<br /> TX hang.<br /> <br /> To avoid these hardware issues, the driver applies the following<br /> workarounds.<br /> <br /> Drop malformed packets that may trigger this hardware issue before<br /> transmission.<br /> <br /> For IPv4 non-initial fragments, the hardware does not check the<br /> fragment offset before parsing the expected transport header location.<br /> As a result, these packets are still subject to transport header<br /> parsing even though they do not contain a transport header. If the<br /> transport data is shorter than the minimum transport header required<br /> by the hardware parser, pad the transport data to the minimum<br /> transport header length required by the hardware parser. Packets that<br /> also match the hardware PTP parsing conditions continue to follow the<br /> corresponding workaround.<br /> <br /> For IPv6 fragmented packets, neither of the above hardware issues<br /> occurs because the hardware only continues packet parsing when the<br /> IPv6 Base Header Next Header field directly indicates UDP. Packets<br /> carrying a Fragment Header do not continue through the subsequent<br /> packet parsing stages.<br /> <br /> For packets identified for hardware PTP parsing, pad the transport<br /> data so it reaches RTASE_MIN_PAD_LEN before transmission.

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()

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.

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.

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.

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).

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.

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.

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.

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.