CVE-2026-98306
seg6: set IPSKB_L3SLAVE from IP6SKB_L3SLAVE on IPIP decapsulation
No known exploitation. EPSS puts it in the 7th percentile. Fixed versions are out.
What to do
Find your product and version, then upgrade to the build on the right.
- LinuxAffected: ≥ 891ef8dd2a8d14e4e73a81dcdb135b574c57f556, < 1d9f5c78903dd25a3556229eb716dd465c5f3573Upgrade to: 1d9f5c78903dd25a3556229eb716dd465c5f3573Affected: ≥ 891ef8dd2a8d14e4e73a81dcdb135b574c57f556, < 72f410616000d21a0a6ec6c93a60301b9c92e95cUpgrade to: 72f410616000d21a0a6ec6c93a60301b9c92e95cAffected: ≥ 891ef8dd2a8d14e4e73a81dcdb135b574c57f556, < e4d7c52f15f572608374947c6c802052e1a2fc82Upgrade to: e4d7c52f15f572608374947c6c802052e1a2fc82Affected: ≥ 891ef8dd2a8d14e4e73a81dcdb135b574c57f556, < 5130afa025c95faa621adf8bac525baeb2b290d2Upgrade to: 5130afa025c95faa621adf8bac525baeb2b290d2 + 4 more branchesStated by: CVE record
Versions as the sources state them. Full version matrix after sign-in
What it is
From the CVE record
In the Linux kernel, the following vulnerability has been resolved: seg6: set IPSKB_L3SLAVE from IP6SKB_L3SLAVE on IPIP decapsulation When an SRv6 packet arrives on an interface enslaved to a VRF, vrf_ip6_rcv() sets IP6SKB_L3SLAVE in IP6CB, but decap_and_validate() has never set IPSKB_L3SLAVE in IPCB. The bit stayed clear in the common case, and with CONFIG_IPV6_MIP6 the leftover frag_max_size of a reassembled outer packet could even set it, with no VRF involved. Commit 44930446dde4 ("ipv6: seg6: clear IPv4 control block on IPIP decapsulation") then made the unreliable bit reliably clear. The effect of the missing flag is visible with End.DX4 when a delivery to a local address of the node reaches the socket lookup. For example, a UDP socket bound to the enslaved ingress interface does not receive any of the decapsulated packets, while an unbound socket outside the VRF does. This contradicts Documentation/networking/vrf.rst: by default the scope of an unbound UDP or TCP socket is limited to the default VRF. Set IPSKB_L3SLAVE for IPv4 in decap_and_validate(), which already does the same for IPv6. The socket lookup then matches the decapsulated packet like any other packet received on that enslaved interface. Such a packet matches an unbound UDP or TCP socket only when udp_l3mdev_accept or tcp_l3mdev_accept is set.
In plain language
No plain-language summary for this CVE yet.
Exploitation
Where each signal puts this CVE on the scale from published to confirmed exploited.
- CISA KEV
Not in the catalog. CISA has not confirmed exploitation.
- Public exploits
No public exploit or proof of concept found in the sources we track.
- EPSS
0.2% chance of exploitation activity in the next 30 days, which ranks it in the 7th percentile of scored CVEs.
Exploit Prediction Scoring System, FIRST.org. A probability, not a confirmation.
Lifecycle
2 events over 0 days, from the signal feeds we watch.
- Publishedrecord updated
Affected products
Sources
References in the record
- git.kernel.org/stable/c/1d9f5c78903dd25a3556229eb716dd465c5f3573
- git.kernel.org/stable/c/72f410616000d21a0a6ec6c93a60301b9c92e95c
- git.kernel.org/stable/c/e4d7c52f15f572608374947c6c802052e1a2fc82
And 5 more references. See all after sign-in
In the news
Watch the software you run.
My Stack ranks new CVEs for your products by real-world exploitation, so the next serious one reaches you without reading every advisory.
We'll flag the next CVE, public exploit or patch for Linux, not every advisory.
A free account adds
- The full version matrix and every affected product
- Exploit links, proofs of concept and Metasploit modules
- Email alerts for the products you watch
- The same data over REST API, MCP and CLI