PT-2026-117021 · Linux · Linux

CVE-2026-98802

·

Published

2026-10-18

·

Updated

2026-10-18

None

No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
In the Linux kernel, the following vulnerability has been resolved:
seg6: ensure packet data is writable before modifying SRH and IPv6 DA
advance nextseg() modifies the SRH Segments Left field and the IPv6 destination address without ensuring the packet data is writable. seg6 next csid advance arg() has the same problem when it advances the NEXT-C-SID argument in the destination address.
The skb may be cloned, for example by an AF PACKET socket receiving on the ingress device. advance nextseg() and seg6 next csid advance arg() then write into the packet data shared with the clone. A read from that socket can return the modified packet instead of the received one. The simplified path below shows this for advance nextseg():
netif receive skb one core netif receive skb core deliver skb [orig: users=2, cloned=0] packet rcv skb clone clone queued to the AF PACKET socket consume skb(orig) [orig: users=1, cloned=1] ipv6 rcv ip6 rcv core skb share check: no-op [orig: users=1] [...] input action end core advance nextseg writes into the data shared with the clone
Call skb ensure writable() in advance nextseg() and in seg6 next csid advance arg() before they modify the packet data. skb ensure writable() may reallocate skb->head, which invalidates the pointers into the packet data taken before the call. advance nextseg() now returns a valid SRH pointer, or NULL if skb ensure writable() fails. seg6 next csid advance arg() takes the pointer to the destination address from the skb after skb ensure writable(). On failure, the callers drop the packet with SKB DROP REASON NOMEM.
Found an issue in the description? Have something to add? Feel free to write us 👾

Related Identifiers

CVE-2026-98802

Affected Products

Linux