Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: input: hold netns during deferred transport reinjection<br /> <br /> Transport-mode reinjection stores a struct net pointer in skb-&gt;cb and<br /> uses it later from xfrm_trans_reinject(). That pointer must stay valid<br /> until the deferred callback runs.<br /> <br /> Take a netns reference when queueing deferred reinjection work and drop<br /> it after the callback completes. Use maybe_get_net() so the queueing<br /> path does not revive a namespace that is already being torn down.<br /> <br /> This keeps the existing workqueue design and fixes the netns lifetime<br /> handling in one place for all users of xfrm_trans_queue_net().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: validate extension header length before copying to cmsg<br /> <br /> ip6_datagram_recv_specific_ctl() builds IPV6_{HOPOPTS,DSTOPTS,RTHDR}<br /> cmsgs (and their IPV6_2292* legacy counterparts) by trusting the<br /> on-wire hdrlen byte (ptr[1]) when computing the put_cmsg() length.<br /> The length was validated only at parse time (ipv6_parse_hopopts(),<br /> etc.). An nftables payload-write expression can rewrite hdrlen after<br /> parsing and before the skb reaches recvmsg; the write itself is<br /> in-bounds but put_cmsg() then reads up to ((hdrlen+1)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ip6: vti: Use ip6_tnl.net in vti6_siocdevprivate().<br /> <br /> After patch 1/2 in this series, vti6_update() unlinks and relinks<br /> the tunnel through t-&gt;net. vti6_siocdevprivate() still uses<br /> dev_net(dev) for the collision lookup. For a tunnel moved through<br /> IFLA_NET_NS_FD, dev_net(dev) is the new netns, not t-&gt;net.<br /> <br /> SIOCCHGTUNNEL on a migrated tunnel then runs:<br /> <br /> net = dev_net(dev) /* migrated netns */<br /> t = vti6_locate(net, &amp;p1, false) /* misses target in t-&gt;net */<br /> ...<br /> t = netdev_priv(dev)<br /> vti6_update(t, &amp;p1, false) /* mutates t-&gt;net&amp;#39;s hash */<br /> <br /> A caller in the migrated netns picks params that match a tunnel<br /> in the creation netns. The lookup in dev_net(dev) finds nothing.<br /> vti6_update() prepends the migrated tunnel at the head of the<br /> creation netns hash bucket for those params. Later lookups in<br /> the creation netns resolve to the migrated device. xfrm receive<br /> delivers the matched packets through a device the caller controls.<br /> <br /> Reachable from an unprivileged user namespace (unshare --user<br /> --map-root-user --net). Cross tenant scope on container hosts.<br /> <br /> Switch the SIOCCHGTUNNEL path on a non fallback device to use<br /> t-&gt;net for the lookup. The lookup now matches the netns<br /> vti6_update() operates on.<br /> <br /> Also add ns_capable(self-&gt;net-&gt;user_ns, CAP_NET_ADMIN) before<br /> the lookup. The check at the top of the case is against<br /> dev_net(dev)-&gt;user_ns, which after migration is the attacker&amp;#39;s<br /> netns. A caller there can pick params absent from self-&gt;net,<br /> the lookup returns NULL, t becomes self, and vti6_update()<br /> inserts the device into the creation netns hash. The new check<br /> requires CAP_NET_ADMIN in the creation netns user_ns too.<br /> <br /> SIOCADDTUNNEL and SIOCCHGTUNNEL on the fallback device keep<br /> dev_net(dev), which equals init_net there.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: exthdrs: refresh nh pointer after ipv6_hop_jumbo()<br /> <br /> ipv6_hop_jumbo() calls pskb_trim_rcsum(), which can change skb pointers.<br /> Let&amp;#39;s recompute nh pointer to make sure any change won&amp;#39;t mess things up.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> macsec: fix replay protection at XPN lower-PN wrap<br /> <br /> In macsec_post_decrypt(), when pn is U32_MAX, pn + 1 overflows u32 to 0<br /> and the first branch never fires. If next_pn_halves.lower is also in the<br /> upper half, pn_same_half(pn, lower) is true and the XPN else-if does not<br /> fire either, leaving next_pn_halves unchanged. An attacker that captures<br /> the legitimate frame carrying pn == 0xFFFFFFFF on an XPN association<br /> can then replay it indefinitely, since lowest_pn never rises above<br /> the captured pn and macsec_decrypt() reconstructs the same IV.<br /> <br /> Extend the XPN else-if to also fire when pn + 1 wraps to 0, so receipt<br /> of pn == U32_MAX advances next_pn_halves to (upper + 1, 0).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: sockmap: fix tail fragment offset in bpf_msg_push_data<br /> <br /> When bpf_msg_push_data() inserts data in the middle of a scatterlist<br /> entry, it splits the original entry into a left fragment and a right<br /> fragment.<br /> <br /> The right fragment offset is page-local, but the code advances it with<br /> `start`, which is the message-global insertion point. For inserts into a<br /> non-first SG entry, this over-advances the offset and leaves the split<br /> layout inconsistent.<br /> <br /> Advance the right fragment offset by the fragment-local delta,<br /> `start - offset`, which matches the length removed from the front of the<br /> original entry.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: exthdrs: refresh nh after handling HAO option<br /> <br /> ip6_parse_tlv() caches skb_network_header(skb) in nh while walking<br /> IPv6 TLVs.<br /> <br /> ipv6_dest_hao() may call pskb_expand_head() for a cloned skb, which can<br /> move the skb head and invalidate the cached network header pointer.<br /> Refresh nh after ipv6_dest_hao() returns so any trailing padding or TLVs<br /> are parsed from the current skb head.<br /> <br /> This matches the existing pattern used in ip6_parse_tlv() after helpers<br /> that can modify skb header storage.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> octeontx2-af: validate body pcifunc in rvu_mbox_handler_rep_event_notify<br /> <br /> rvu_mbox_handler_rep_event_notify() in drivers/net/ethernet/marvell/<br /> octeontx2/af/rvu_rep.c queues a sender-controlled REP_EVENT_NOTIFY<br /> request body verbatim, and rvu_rep_up_notify() then forwards<br /> event-&gt;pcifunc (the nested body field, distinct from the<br /> AF-normalised header pcifunc) into rvu_get_pfvf(), rvu_get_pf() and<br /> the AF-&gt;PF mailbox device index without any bounds check.<br /> <br /> A VF attached to a PF that has been put into switchdev<br /> representor mode reaches this path: the VF mailbox handler<br /> otx2_pfvf_mbox_handler() forwards every message id including<br /> MBOX_MSG_REP_EVENT_NOTIFY to AF without an allowlist, and the AF<br /> dispatcher rewrites only msg-&gt;pcifunc, leaving struct<br /> rep_event::pcifunc attacker-controlled. The sibling<br /> rvu_mbox_handler_esw_cfg() refuses requests whose header pcifunc<br /> is not rvu-&gt;rep_pcifunc; this handler has no equivalent gate.<br /> <br /> An out-of-range body pcifunc selects an &amp;rvu-&gt;pf[]/&amp;rvu-&gt;hwvf[]<br /> element past the allocated array and, for RVU_EVENT_MAC_ADDR_CHANGE,<br /> turns into a six-byte attacker-chosen OOB ether_addr_copy() target<br /> inside the queued worker; KASAN reports a slab-out-of-bounds write<br /> in rvu_rep_wq_handler.<br /> <br /> Reject malformed requests at the handler entry by gating on<br /> is_pf_func_valid(), which is already the canonical PF/VF range check<br /> in this driver; expose it via rvu.h so callers in rvu_rep.c can use<br /> it instead of open-coding the same range arithmetic.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: esp: restore combined single-frag length gate<br /> <br /> The ESP out-of-place fast path appends the trailer in esp_output_head()<br /> before esp_output_tail() allocates the destination page frag. The<br /> head-side gate currently checks skb-&gt;data_len and tailen separately, but<br /> the tail code allocates a single destination frag from the combined<br /> post-trailer skb-&gt;data_len.<br /> <br /> Reject the page-frag fast path when the combined aligned length exceeds a<br /> page. Otherwise skb_page_frag_refill() may fall back to a single page while<br /> the destination sg still spans the combined skb-&gt;data_len.<br /> <br /> Restore this combined-length page gate for both IPv4 and IPv6.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: conntrack: tcp: do not force CLOSE on invalid-seq RST without direction check<br /> <br /> An unintended behavior in the TCP conntrack state machine allows a<br /> connection to be forced into the CLOSE state using an RST packet with an<br /> invalid sequence number.<br /> <br /> Specifically, after a SYN packet is observed, an RST with an invalid SEQ<br /> can transition the conntrack entry to TCP_CONNTRACK_CLOSE, regardless of<br /> whether the RST corresponds to the expected reply direction. The relevant<br /> code path assumes the RST is a response to an outgoing SYN, but does not<br /> validate packet direction or ensure that a matching SYN was actually sent<br /> in the opposite direction.<br /> <br /> As a result, a crafted packet sequence consisting of a SYN followed by an<br /> invalid-sequence RST can prematurely terminate an active NAT entry. This<br /> makes connection teardown easier than intended.<br /> <br /> So, tighten the state transition logic to ensure that RST-triggered<br /> CLOSE transitions only occur when the RST is a valid response to a<br /> previously observed SYN in the correct direction.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: route MIGRATE notifications to caller&amp;#39;s netns<br /> <br /> xfrm_send_migrate() in net/xfrm/xfrm_user.c and pfkey_send_migrate()<br /> in net/key/af_key.c both hardcode &amp;init_net for the multicast that<br /> announces a successful XFRM_MSG_MIGRATE / SADB_X_MIGRATE.<br /> <br /> XFRM_MSG_MIGRATE arrives on a per-netns NETLINK_XFRM socket, and the<br /> rest of the xfrm/af_key netlink path was made netns-aware in 2008.<br /> The other 14 multicast paths in xfrm_user.c route their event using<br /> xs_net(x), xp_net(xp) or sock_net(skb-&gt;sk); only the migrate path<br /> was missed.<br /> <br /> Two consequences of the init_net hardcoding:<br /> <br /> 1. The notification (selector, old/new endpoint addresses, and the<br /> km_address) is delivered to listeners on init_net&amp;#39;s<br /> XFRMNLGRP_MIGRATE / pfkey BROADCAST_ALL groups rather than on<br /> the issuing netns. An IKE daemon running in init_net therefore<br /> receives migration notifications originating from any other<br /> netns on the host.<br /> <br /> 2. An IKE daemon running inside a non-init netns and subscribed<br /> to its own XFRMNLGRP_MIGRATE / pfkey groups never receives the<br /> notification of its own migration. IKEv2 MOBIKE / address-update<br /> handling inside a netns is silently broken.<br /> <br /> Thread struct net through km_migrate() and the xfrm_mgr.migrate<br /> function pointer, drop the &amp;init_net override in xfrm_send_migrate()<br /> and pfkey_send_migrate(), and pass the caller&amp;#39;s net (already in<br /> scope in xfrm_migrate() via sock_net(skb-&gt;sk)) all the way down.<br /> struct xfrm_mgr is in-tree only and not exported as a stable API,<br /> so the function-pointer signature change is internal.<br /> <br /> pfkey_broadcast() is already netns-aware via net_generic(net,<br /> pfkey_net_id) since the pernet conversion. The five other<br /> pfkey_broadcast() callers in af_key.c already pass xs_net(x),<br /> sock_net(sk) or a per-netns net, so this only removes the<br /> &amp;init_net outlier.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfc: hci: fix out-of-bounds read in HCP header parsing<br /> <br /> Both nfc_hci_recv_from_llc() and nci_hci_data_received_cb() read<br /> packet-&gt;header from skb-&gt;data at function entry without first checking<br /> that the buffer holds at least one byte. A malicious NFC peer can send<br /> a 0-byte HCP frame that passes through the SHDLC layer and reaches<br /> these functions, causing an out-of-bounds heap read of packet-&gt;header.<br /> The same 0-byte frame, if queued as a non-final fragment, also causes<br /> the reassembly loop to underflow msg_len to UINT_MAX, triggering<br /> skb_over_panic() when the reassembled skb is written.<br /> <br /> Fix this by adding a pskb_may_pull() check at the entry of each<br /> function before packet-&gt;header is first accessed. The existing<br /> pskb_may_pull() checks before the reassembled hcp_skb is cast to<br /> struct hcp_packet remain in place to guard the 2-byte HCP message<br /> header.