Linux VXLAN driver (transmit-path header pulls): TENANT ISOLATION: `vxlan_xmit()`, `arp_reduce()`

Impact

TENANT ISOLATION: vxlan_xmit(), arp_reduce() and vxlan_mdb_entry_skb_get() validate header availability with pskb_may_pull(), but on the transmit path skb->data points at the MAC header, so the offset accounting is wrong by the Ethernet header length and the driver reads past the validated region. This is the Linux kernel VXLAN data path — the software VTEP used by Linux-based switch OSes (SONiC, Cumulus), by container overlay networks, and by any host doing VXLAN encapsulation itself. Memory corruption in the encapsulation path of a multi-tenant overlay is as close to the centre of the tenant-isolation boundary as this database gets.

Who can reach it

Traffic traversing the VXLAN transmit path on an affected host or switch — reachable from inside a tenant overlay, since tenants generate the frames being encapsulated.

What to do

Kernel upgrade plus host reboot; on Linux-based switch NOSes it arrives as a NOS image upgrade plus switch reload, so stage across MLAG/ECMP pairs. No config workaround short of not using VXLAN. Part of a 2026 cluster of VXLAN data-path fixes — CVE-2026-74475, CVE-2026-74473, CVE-2026-74406, CVE-2026-63993 — so take the whole batch in one upgrade rather than chasing them individually.

References