CVE-2026-97965: vxlan: initialize _md in vxlan_xmit_one()
In the Linux kernel, the following vulnerability has been resolved:
vxlan: initialize md in vxlanxmitone()
If a VXLAN device is configured with both VXLANFCOLLECTMETADATA and VXLANFGBP, and a packet is transmitted through it using an external iptunnelinfo that lacks the IPTUNNELVXLANOPTBIT flag, md is left pointing to the uninitialized md stack variable:
if (testbit(IPTUNNELVXLANOPTBIT, info->key.tunflags)) { if (info->optionslen < sizeof(md)) goto drop; md = iptunnelinfoopts(info); }
Because IPTUNNELVXLANOPTBIT is not set, md is not updated and remains pointing to md. Later, vxlanbuildskb() is called with md, which eventually calls vxlanbuildgbphdr():
if (vxflags & VXLANFGBP) vxlanbuildgbphdr(vxh, md);
Inside vxlanbuildgbphdr(), md->gbp is read:
if (!md->gbp) return; gbp = (struct vxlanhdrgbp )vxh; ... if (md->gbp & VXLANGBPDONTLEARN) gbp->dontlearn = 1;
If the stack contains garbage, this causes: 1) VXLANHFGBP flag to be spuriously set in the VXLAN header. 2) gbp->dontlearn and gbp->policyapplied to be set from stack bits. 3) gbp->policyid to receive 16 bits of uninitialized kernel stack data, leaking it onto the wire.
Fix this by zero-initializing md. If IPTUNNELVXLANOPTBIT is not present, md->gbp remains 0, and vxlanbuildgbphdr() returns early without modifying the VXLAN header.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Zero-initialize the _md stack variable in vxlan_xmit_one() before it is used, preventing uninitialized VXLAN GBP metadata from being transmitted.
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
The affected configuration requires a VXLAN device with both VXLAN_F_COLLECT_METADATA and VXLAN_F_GBP enabled. The problematic transmit path also requires an externally supplied ip_tunnel_info without the IP_TUNNEL_VXLAN_OPT_BIT flag.
What could exploitation or triggering expose?
The issue can cause garbage stack data to influence the VXLAN GBP header. In particular, 16 bits of uninitialized kernel stack data can be placed in the GBP policy_id field and transmitted on the wire; GBP flags may also be set spuriously.
How can I identify potentially affected traffic or configuration?
Check for VXLAN devices configured for both metadata collection and GBP, then determine whether packets are transmitted using external tunnel metadata that does not set IP_TUNNEL_VXLAN_OPT_BIT. Such traffic may carry unexpected GBP header flags, dont_learn or policy_applied bits, or an unintended policy_id.