CVE-2026-98573

What it actually does

Integer underflow in skb_maybe_pull_tail during IPv6 extension header parsing converts a large linear skb area into a negative delta passed to __pskb_pull_tail and skb_copy_bits, resulting in an enormous copy length and potential out-of-bounds memory access or corruption in the skbuff subsystem.

Why it matters to the business

Remote attackers may crash kernel network processing or achieve memory corruption on systems handling crafted IPv6 traffic, leading to denial of service, system instability, or potential privilege escalation with minimal attacker effort.

How an attack unfolds

An attacker sends IPv6 packets containing extension headers that force the checksum setup path to encounter an skb whose linear area already exceeds MAX_IPV6_HDR_LEN; the missing bound check allows the underflow, turning the pull request negative and causing skb_copy_bits to access or overwrite arbitrary kernel memory.

How to fix it

Apply the upstream fix that passes the requested length directly as the pull bound at the three extension-header call sites; upgrade to a kernel containing the commit that resolves the underflow; rebuild and reboot affected systems; monitor for new stable releases that include this change.

How to confirm the fix worked

Confirm the patched kernel contains the described skb_checksum_setup_ipv6 bound check; run regression tests that exercise IPv6 extension header parsing with large linear skbs; verify no negative deltas are passed to __pskb_pull_tail in the network stack.

Typical attack path

1. Send crafted IPv6 packet with multiple extension headers to a vulnerable Linux host
2. Trigger skb_checksum_setup_ipv6 while the skb linear area is already large
3. Cause skb_maybe_pull_tail to compute a negative delta from unsigned-to-signed conversion
4. Induce skb_copy_bits to treat the negative value as a huge positive length
5. Achieve out-of-bounds read/write or kernel panic

How to detect it

Monitor kernel logs for skb_copy_bits or __pskb_pull_tail warnings, oops messages, or panics involving IPv6 extension header processing; inspect network captures for unusual IPv6 extension header chains that exceed typical header lengths; correlate with sudden reboots or network stack restarts on exposed hosts.

What your security team should do

• Prioritize kernel updates on all systems that process IPv6 traffic within the next maintenance window
• Enable kernel hardening features such as KASAN and page allocator hardening to limit exploitation impact
• Review network-facing services for exposure to untrusted IPv6 packets and apply ingress filtering where feasible
• Add monitoring for kernel oops or skb-related panics that may indicate attempted exploitation