Linux Kernel EUVD-2026-103577

Requires the openvswitch kernel datapath to be present and configured with IPv6 modify actions (e.g. set_ipv6_addr), and an attacker-controlled IPv6 packet carrying an extension-header chain whose declared length (ipv6_optlen up to 2048) extends past the actual skb->len; this unbounded skip is what makes ipv6_find_hdr() return an offset past the packet end. The demonstrated path runs through the openvswitch packet-execute netlink interface (ovs_packet_cmd_execute), which on normal systems requires CAP_NET_ADMIN, so a local privileged/administrative context over the OVS datapath is the confirmed trigger. LIMITING FACTORS: no openvswitch, no exposure; exploitation is complex (AC:H) because the stray offset must land in freed slab memory to be useful; the upstream CVSS claims no authentication/UI, but the evidence shows an openvswitch-gated path that likely requires privileged netlink access - defenders without openvswitch are effectively not exposed.

Signals conflict and should be reconciled before prioritizing. The supplied CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, score 8.1) rates this network-reachable and unauthenticated, but the only trigger described in the evidence is openvswitch's packet pipeline reached via the netlink genetlink path (ovs_packet_cmd_execute → do_execute_actions → set_ipv6_addr), demonstrated by a local task (ovs_ipv6_oob, UID 1000) - openvswitch datapath/netlink control normally requires CAP_NET_ADMIN, so the PR:N / AV:N labeling is questionable and should be verified against the demonstrated local, OVS-dependent path. Exploitation probability signals are modest: EPSS is 0.22% (12th percentile), the vulnerability is NOT in CISA KEV, and no public exploit is identified in the input; the vuln.today decision label is 'this_week' rather than act_now/emergency. The flaw is nonetheless a genuine slab-use-after-free with both an out-of-bounds read and write of the transport checksum field (confirmed by the KASAN trace), which is a real memory-corruption primitive, so it is a legitimate patch-this-cycle issue for systems running openvswitch - but it is not a widespread drive-by threat: realistic exploitation is gated on openvswitch being configured and on the attacker being able to feed a crafted IPv6 extension-header chain into its actions. Net: a real but conditional priority, consistent with the 'this_week' label, not a mass-exploitation emergency.

On a host running openvswitch, an attacker supplies an IPv6 packet whose extension-header chain declares a length extending past the actual packet end; ipv6_find_hdr() returns an offset beyond skb->len, openvswitch installs it as the transport header, and update_ipv6_checksum()/inet_proto_csum_replace16() then read and write two bytes out of bounds in freed slab memory (skbuff_small_head), corrupting kernel memory. No public exploit is identified at time of analysis; the KASAN report references a reproducer (ovs_ipv6_oob) but no working exploit code is provided in the input. Reliable exploitation is non-trivial (AC:H) because it depends on crafting the header chain so the stray offset lands in attacker-useful memory.