CVE-2026-98532

What it actually does

ipv6_find_hdr() fails to validate that the offset computed from extension header lengths fits within skb->len, allowing an out-of-bounds value to be installed as the transport header; subsequent callers in openvswitch (update_ipv6_checksum, inet_proto_csum_replace16) then perform reads and writes beyond the allocated skbuff, producing slab use-after-free.

Why it matters to the business

Network traffic processed by systems using Open vSwitch can trigger kernel memory corruption, leading to crashes, potential remote code execution, or service outages on Linux hosts handling IPv6 packets.

How an attack unfolds

An attacker sends a crafted IPv6 packet containing an extension header chain whose declared lengths cause ipv6_find_hdr() to compute an offset beyond the actual packet data; openvswitch stores this invalid offset as the transport header and later invokes checksum replacement functions that dereference memory outside the skbuff, resulting in KASAN-detected slab corruption.

How to fix it

Apply the upstream kernel patch that adds an explicit bounds check inside ipv6_find_hdr() before returning the computed offset; rebuild and reboot to a fixed kernel version. Until patched, restrict IPv6 traffic through Open vSwitch or disable IPv6 extension header processing where feasible.

How to confirm the fix worked

Confirm the running kernel contains the bounds check in ipv6_find_hdr(); attempt to replay a minimal malformed IPv6 packet and verify that -EBADMSG is returned instead of an out-of-bounds offset; monitor for absence of KASAN reports in inet_proto_csum_replace16 during OVS packet execution.

Typical attack path

1. Craft IPv6 packet with malformed extension header lengths that exceed remaining skb data
2. Deliver packet to an interface handled by Open vSwitch
3. ovs_packet_cmd_execute / do_execute_actions calls set_ipv6_addr which invokes ipv6_find_hdr
4. Invalid offset is written into the skbuff metadata
5. inet_proto_csum_replace16 performs out-of-bounds read/write on the freed skbuff region

How to detect it

Search kernel logs and KASAN reports for the exact strings 'ipv6_find_hdr', 'inet_proto_csum_replace16', 'ovs_ipv6_oob', and 'slab-use-after-free' near skbuff_small_head allocations; inspect netlink and OVS packet execution paths for anomalous IPv6 traffic preceding the crash.

• BUG: KASAN: slab-use-after-free in inet_proto_csum_replace16
• ovs_ipv6_oob
• Read of size 2 at addr .* skbuff_small_head
• ipv6_find_hdr.*offset past the packet end

What your security team should do

• Immediately schedule kernel updates for all systems running Open vSwitch with IPv6 enabled
• Add the published patch to internal kernel build pipelines and test in staging
• Temporarily apply network ACLs that drop suspicious IPv6 extension header chains if patching is delayed
• Increase monitoring for kernel oops and KASAN events on OVS hosts