CVE-2026-98306

Description

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.

Is your site exposed to CVE-2026-98306?

Run a free security scan — no signup, results in seconds.

EPSS — Exploit Prediction

0.0018

Probability of exploitation

0.07%

Percentile rank

EPSS estimates the probability that this vulnerability will be exploited in the wild within the next 30 days. A higher score means more likely to be exploited.

References

Other References

https://git.kernel.org/stable/c/1d9f5c78903dd25a3556229eb716dd465c5f3573 https://git.kernel.org/stable/c/5130afa025c95faa621adf8bac525baeb2b290d2 https://git.kernel.org/stable/c/72f410616000d21a0a6ec6c93a60301b9c92e95c https://git.kernel.org/stable/c/7616242a2b37883f7322aaa1d2bd6cd0fed28315 https://git.kernel.org/stable/c/8c16e1ccc082a3763dfc6bc2d3f658c1a6336f9d https://git.kernel.org/stable/c/ddf60220c925b54a1714c4722fdbdb12833232d0 https://git.kernel.org/stable/c/e4d7c52f15f572608374947c6c802052e1a2fc82 https://git.kernel.org/stable/c/f8fb4738ccef5f9d107845b05734a56352747b1a

Frequently Asked Questions

What is CVE-2026-98306? +

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.

How do I check if I'm vulnerable to CVE-2026-98306? +

You can use Secably's free Website Scanner to check your website for known vulnerabilities. For infrastructure scanning, use the Port Scanner to identify exposed services that may be affected. Check the vendor advisories linked above for specific patch and version information.