Linux Kernel EUVD-2026-86676

Exploitation requires local access with CAP_NET_ADMIN to configure VXLAN networking, plus a specific non-default topology: at least two VXLAN devices whose FDB entries reference the SAME FDB nexthop id (an EVPN-style load-balancing setup with a user-space control plane and data-plane learning disabled). On vulnerable kernels the attacker must create 'dynamic' FDB entries pointing to that nexthop so they become eligible for aging. The bug then requires winning a race between the aging timer running in softirq context (without RTNL) on one device and a concurrent FDB add/delete on the other device sharing the list. Limiting factors: privileged local access only, an uncommon shared-nexthop configuration, and a timing-dependent race - so it is not reachable in default or single-device deployments and not remotely triggerable.

The NVD CVSS 3.1 base score of 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) overstates real-world risk for this bug. The vector correctly captures local access and low-privilege exploitation, but the description contradicts the C:H/I:H impact: this is a list-corruption / slab-use-after-free in vxlan_fdb_destroy that manifests as a KASAN-reported crash during FDB aging - a denial-of-service, with no evidence of information disclosure or integrity compromise. Two signals conflict here: the CVSS claims full CIA impact while the reproduction is a WARNING/BUG kernel oops (crash-dominant DoS). AC:L is also questionable - triggering requires a race between softirq-context aging on one VXLAN device and a concurrent add/delete on a second device sharing the same FDB nexthop, which is realistically AC:H. There is no EPSS score, no CISA KEV listing, and no public exploit code, so no active-exploitation pressure. My independent assessment is roughly 5.0 (AV:L/AC:H/PR:L/C:N/I:L/A:H). Net: a legitimate kernel memory-safety fix worth patching in the maintenance window, but not an emergency, and not the network-facing high-confidentiality issue the raw score implies.

A local user with CAP_NET_ADMIN configures two VXLAN devices whose FDB entries point to the same shared FDB nexthop and (before the fix) marks those entries 'dynamic', so they are subject to aging. As the aging timer fires in softirq context on one device without holding RTNL, it deletes an entry from the shared per-nexthop list while the second device concurrently adds or removes an entry, corrupting the list and triggering a use-after-free in vxlan_fdb_destroy that panics the kernel. No public proof-of-concept exists; the report includes only a KASAN/WARNING trace from the maintainers.