CVE-2026-74473

The fix for CVE-2026-74473 in the Linux kernel's VXLAN transmit path addresses more than a missing bounds check — it corrects a semantic confusion between MAC-layer and network-layer offset assumptions that had persisted in production code for years. The vulnerability existed in route_shortcircuit(), which was called from vxlan_xmit() with skb->data positioned at the MAC header rather than the network header. The function then called pskb_may_pull(skb, 20), which checked 20 bytes from the MAC header position — leaving only 6 bytes of actual IP header in linear memory instead of the required 20. This off-by-offset error could cause out-of-bounds reads from skb fragment data, with implications for speculative execution side channels in cloud environments where VXLAN underpins container and multi-tenant networking. The correct API, pskb_network_may_pull(), has existed in the kernel for years precisely to prevent this class of error. Its availability makes this a case of organizational debt rather than organic code decay: the fix was written and waiting while the vulnerable call site went unmigrated. The unsafe function's shorter name and simpler appearance created a pit of success — the path of least resistance favored incorrect usage. This CVE should prompt immediate audit of similar paths in GENEVE, GRE, and other tunneling protocols. The pattern is well-established: pskb_may_pull() calls in *_xmit() functions that weren't updated when the network-aware variant landed. Prioritize hot-path, multi-tenant exposures over dormant low-traffic code. When this fix reaches stable trees and backports, treat the patch announcement as a reconnaissance signal — attackers familiar with the 2015-2017 IPv6 fragment handling cleanup (which produced an identical fix pattern) will search for unmigrated call sites in older kernels that won't receive updates for months.

Reviewed through automated stages and approved by a human before publication.