GHSA-QVVR-RF39-CH86
Vulnerability from github – Published: 2026-09-25 12:31 – Updated: 2026-09-25 12:31In 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.
{
"affected": [],
"aliases": [
"CVE-2026-97965"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-25T11:17:24Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: initialize _md in vxlan_xmit_one()\n\nIf a VXLAN device is configured with both VXLAN_F_COLLECT_METADATA and\nVXLAN_F_GBP, and a packet is transmitted through it using an external\nip_tunnel_info that lacks the IP_TUNNEL_VXLAN_OPT_BIT flag, md is left\npointing to the uninitialized _md stack variable:\n\n if (test_bit(IP_TUNNEL_VXLAN_OPT_BIT, info-\u003ekey.tun_flags)) {\n if (info-\u003eoptions_len \u003c sizeof(*md))\n goto drop;\n md = ip_tunnel_info_opts(info);\n }\n\nBecause IP_TUNNEL_VXLAN_OPT_BIT is not set, md is not updated and remains\npointing to _md. Later, vxlan_build_skb() is called with md, which\neventually calls vxlan_build_gbp_hdr():\n\n if (vxflags \u0026 VXLAN_F_GBP)\n vxlan_build_gbp_hdr(vxh, md);\n\nInside vxlan_build_gbp_hdr(), md-\u003egbp is read:\n\n if (!md-\u003egbp)\n return;\n gbp = (struct vxlanhdr_gbp *)vxh;\n ...\n if (md-\u003egbp \u0026 VXLAN_GBP_DONT_LEARN)\n gbp-\u003edont_learn = 1;\n\nIf the stack contains garbage, this causes:\n1) VXLAN_HF_GBP flag to be spuriously set in the VXLAN header.\n2) gbp-\u003edont_learn and gbp-\u003epolicy_applied to be set from stack bits.\n3) gbp-\u003epolicy_id to receive 16 bits of uninitialized kernel stack data,\n leaking it onto the wire.\n\nFix this by zero-initializing _md. If IP_TUNNEL_VXLAN_OPT_BIT is not\npresent, md-\u003egbp remains 0, and vxlan_build_gbp_hdr() returns early\nwithout modifying the VXLAN header.",
"id": "GHSA-qvvr-rf39-ch86",
"modified": "2026-09-25T12:31:30Z",
"published": "2026-09-25T12:31:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-97965"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/081f22177d9d12b1e381b787f203cd5f47508187"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0d13b5a413bffc8718b3821b78537ccc6596c233"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/be83178bfc44588f6e3adb827ed874c683193466"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bfb74c48ac2d31476d5e09cf9658844508d2608a"
}
],
"schema_version": "1.4.0",
"severity": []
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.