CVE-2026-98802: seg6: ensure packet data is writable before modifying SRH and IPv6 DA
In the Linux kernel, the following vulnerability has been resolved:
seg6: ensure packet data is writable before modifying SRH and IPv6 DA
advancenextseg() modifies the SRH Segments Left field and the IPv6 destination address without ensuring the packet data is writable. seg6nextcsidadvancearg() 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 AFPACKET socket receiving on the ingress device. advancenextseg() and seg6nextcsidadvancearg() 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 advancenextseg():
netifreceiveskbonecore netifreceiveskbcore deliverskb [orig: users=2, cloned=0] packetrcv skbclone clone queued to the AFPACKET socket consumeskb(orig) [orig: users=1, cloned=1] ipv6rcv ip6rcvcore skbsharecheck: no-op [orig: users=1] [...] inputactionendcore advancenextseg writes into the data shared with the clone
Call skbensurewritable() in advancenextseg() and in seg6nextcsidadvancearg() before they modify the packet data. skbensurewritable() may reallocate skb->head, which invalidates the pointers into the packet data taken before the call. advancenextseg() now returns a valid SRH pointer, or NULL if skbensurewritable() fails. seg6nextcsidadvancearg() takes the pointer to the destination address from the skb after skbensurewritable(). On failure, the callers drop the packet with SKBDROPREASONNOMEM.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Before modifying packet data, call skb_ensure_writable() in advance_nextseg() and seg6_next_csid_advance_arg(); obtain updated packet-data pointers after the call, and have callers drop the packet with SKB_DROP_REASON_NOMEM if skb_ensure_writable() fails.
Event History
Frequently Asked Questions
Who is exposed to the incorrect packet view?
Systems that process IPv6 Segment Routing Header traffic through the affected seg6 paths and have an AF_PACKET socket receiving on the ingress device can expose the issue. An AF_PACKET reader may receive packet data after the kernel has modified it rather than the packet as originally received.
What condition triggers the shared-data modification?
The skb must be cloned, such as when a packet is queued to an AF_PACKET socket, and then processed by advance_nextseg() or seg6_next_csid_advance_arg(). Those functions modify the SRH Segments Left field or IPv6 destination address while the clone shares packet data.
How can I determine whether a system is affected?
Review the kernel source or applied stable commits to determine whether skb_ensure_writable() is called before packet-data modifications in both advance_nextseg() and seg6_next_csid_advance_arg(). The provided fixes are identified by stable commit references e9141fdb7a2ead48cfcd60c681aba91d3014255b and 8ae3f4067ba4ae3a15581392f6dac422e3d3def0.