---
id: "CVE-2026-98802"
kind: "vulnerability"
aliases: ["CVE-2026-98802"]
title: "Linux kernel: SRv6 packet writes can corrupt packets shared with sockets"
severity: "unknown"
cvss: null
epss: null
exploited: false
status: "open"
category: "runtime"
products: []
ecosystems: []
tags: ["linux-kernel", "runtime", "seg6", "self-hosted", "srv6"]
not_affected_if: ["no-srv6-config"]
published_at: "2026-10-18T16:17:34+00:00"
first_seen_at: "2026-10-23T21:57:16+00:00"
updated_at: "2026-10-25T05:15:03+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98802", "first_seen_at": "2026-10-23T21:57:16+00:00"}]
---

# Linux kernel: SRv6 packet writes can corrupt packets shared with sockets

The Linux kernel's seg6 (SRv6) code modifies the Segment Routing Header and IPv6 destination address in packet data without first making it writable, so a cloned packet (for example one captured by an AF_PACKET socket) can be altered. A local process reading from that socket can receive a modified packet instead of the one that arrived.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- unknown

## Fix

- Update to a Linux kernel release that includes the upstream commit adding skb_ensure_writable() to advance_nextseg() and seg6_next_csid_advance_arg(); the sources do not name the fixed version.

## Timeline

- 2026-10-23T21:57:16+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-98802

## From the sources

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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_