Description
In the Linux kernel, the following vulnerability has been resolved:

vxlan: initialize _md in vxlan_xmit_one()

If a VXLAN device is configured with both VXLAN_F_COLLECT_METADATA and
VXLAN_F_GBP, and a packet is transmitted through it using an external
ip_tunnel_info that lacks the IP_TUNNEL_VXLAN_OPT_BIT flag, md is left
pointing to the uninitialized _md stack variable:

if (test_bit(IP_TUNNEL_VXLAN_OPT_BIT, info->key.tun_flags)) {
if (info->options_len < sizeof(*md))
goto drop;
md = ip_tunnel_info_opts(info);
}

Because IP_TUNNEL_VXLAN_OPT_BIT is not set, md is not updated and remains
pointing to _md. Later, vxlan_build_skb() is called with md, which
eventually calls vxlan_build_gbp_hdr():

if (vxflags & VXLAN_F_GBP)
vxlan_build_gbp_hdr(vxh, md);

Inside vxlan_build_gbp_hdr(), md->gbp is read:

if (!md->gbp)
return;
gbp = (struct vxlanhdr_gbp *)vxh;
...
if (md->gbp & VXLAN_GBP_DONT_LEARN)
gbp->dont_learn = 1;

If the stack contains garbage, this causes:
1) VXLAN_HF_GBP flag to be spuriously set in the VXLAN header.
2) gbp->dont_learn and gbp->policy_applied to be set from stack bits.
3) gbp->policy_id to receive 16 bits of uninitialized kernel stack data,
leaking it onto the wire.

Fix this by zero-initializing _md. If IP_TUNNEL_VXLAN_OPT_BIT is not
present, md->gbp remains 0, and vxlan_build_gbp_hdr() returns early
without modifying the VXLAN header.
Published: 2026-09-25
Score: n/a
EPSS: n/a
KEV: No
Impact: Information Leakage and unintended flag manipulation via uninitialized VXLAN metadata
Action: Immediate Patch
AI Analysis

Impact

The vulnerability occurs in the Linux kernel’s VXLAN implementation where the metadata pointer _md is left uninitialized when a VXLAN device uses both VXLAN_F_COLLECT_METADATA and VXLAN_F_GBP but the external ip_tunnel_info lacks the IP_TUNNEL_VXLAN_OPT_BIT flag. The uninitialized pointer causes vxlan_build_gbp_hdr() to read garbage data, which can inadvertently set VXLAN header flags, manipulate GBP fields such as dont_learn and policy_applied, and expose 16 bits of kernel stack data over the network. This results in information leakage and potential traffic manipulation, compromising confidentiality and integrity of VXLAN traffic.

Affected Systems

Affected systems: Linux kernel. No specific version range is listed in the CVE data. Hosts running a Linux kernel with VXLAN support and configured with both VXLAN_F_COLLECT_METADATA and VXLAN_F_GBP are potentially affected.

Risk and Exploitability

The CVSS score is not provided, and EPSS is unavailable, indicating limited publicly known exploitation data. The attack vector is inferred to be remote and network-based, requiring an attacker to send crafted VXLAN packets to a vulnerable host. Since the bug manifests during packet processing, it would be exploited by an attacker who can inject malicious VXLAN frames, potentially leaking kernel data and gaining control over VXLAN header flags. No official exploit is documented, and the issue is not listed in CISA’s KEV catalog, suggesting a lower but non-negligible risk compared to higher severity vulnerabilities.

Generated by OpenCVE AI on September 25, 2026 at 17:42 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Update the Linux kernel to a version that includes the fix for this issue, such as the commit referenced in the advisory.
  • If an immediate kernel update is not feasible, modify VXLAN interface configurations to disable either the VXLAN_F_COLLECT_METADATA or VXLAN_F_GBP flag, preventing the uninitialized metadata path from being triggered.
  • Verify that any external ip_tunnel_info used with VXLAN interfaces has the IP_TUNNEL_VXLAN_OPT_BIT flag set, or remove reliance on external tunnel info, to ensure the metadata pointer is initialized correctly.

Generated by OpenCVE AI on September 25, 2026 at 17:42 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Fri, 25 Sep 2026 18:00:00 +0000

Type Values Removed Values Added
Weaknesses CWE-788

Fri, 25 Sep 2026 10:30:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: vxlan: initialize _md in vxlan_xmit_one() If a VXLAN device is configured with both VXLAN_F_COLLECT_METADATA and VXLAN_F_GBP, and a packet is transmitted through it using an external ip_tunnel_info that lacks the IP_TUNNEL_VXLAN_OPT_BIT flag, md is left pointing to the uninitialized _md stack variable: if (test_bit(IP_TUNNEL_VXLAN_OPT_BIT, info->key.tun_flags)) { if (info->options_len < sizeof(*md)) goto drop; md = ip_tunnel_info_opts(info); } Because IP_TUNNEL_VXLAN_OPT_BIT is not set, md is not updated and remains pointing to _md. Later, vxlan_build_skb() is called with md, which eventually calls vxlan_build_gbp_hdr(): if (vxflags & VXLAN_F_GBP) vxlan_build_gbp_hdr(vxh, md); Inside vxlan_build_gbp_hdr(), md->gbp is read: if (!md->gbp) return; gbp = (struct vxlanhdr_gbp *)vxh; ... if (md->gbp & VXLAN_GBP_DONT_LEARN) gbp->dont_learn = 1; If the stack contains garbage, this causes: 1) VXLAN_HF_GBP flag to be spuriously set in the VXLAN header. 2) gbp->dont_learn and gbp->policy_applied to be set from stack bits. 3) gbp->policy_id to receive 16 bits of uninitialized kernel stack data, leaking it onto the wire. Fix this by zero-initializing _md. If IP_TUNNEL_VXLAN_OPT_BIT is not present, md->gbp remains 0, and vxlan_build_gbp_hdr() returns early without modifying the VXLAN header.
Title vxlan: initialize _md in vxlan_xmit_one()
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-09-25T10:23:07.952Z

Reserved: 2026-09-25T10:18:58.206Z

Link: CVE-2026-97965

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-25T11:17:24.293

Modified: 2026-09-25T11:17:24.293

Link: CVE-2026-97965

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-25T17:45:17Z

Weaknesses
  • CWE-788

    Access of Memory Location After End of Buffer