---
id: CVE-2026-97965
title: |-
  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 us…
summary: |-
  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 us…
severity: none
vendor: Linux
product: Linux
affected:
  - >-
    Linux >= ee122c79d4227f6ec642157834b6a90fcffa4382 <
    0d13b5a413bffc8718b3821b78537ccc6596c233
  - >-
    Linux >= ee122c79d4227f6ec642157834b6a90fcffa4382 <
    bfb74c48ac2d31476d5e09cf9658844508d2608a
  - >-
    Linux >= ee122c79d4227f6ec642157834b6a90fcffa4382 <
    081f22177d9d12b1e381b787f203cd5f47508187
  - >-
    Linux >= ee122c79d4227f6ec642157834b6a90fcffa4382 <
    be83178bfc44588f6e3adb827ed874c683193466
  - Linux 4.3
published: '2026-09-25'
updated: '2026-09-25'
sourceUpdated: '2026-09-25T11:17:24.293'
source: NVD
sourceUrl: 'https://nvd.nist.gov/vuln/detail/CVE-2026-97965'
references:
  - url: 'https://git.kernel.org/stable/c/081f22177d9d12b1e381b787f203cd5f47508187'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
  - url: 'https://git.kernel.org/stable/c/0d13b5a413bffc8718b3821b78537ccc6596c233'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
  - url: 'https://git.kernel.org/stable/c/be83178bfc44588f6e3adb827ed874c683193466'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
  - url: 'https://git.kernel.org/stable/c/bfb74c48ac2d31476d5e09cf9658844508d2608a'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
tags:
  - nvd
  - cve.org
ingestedAt: '2026-09-25T11:06:38.873Z'
---

## Overview

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.

## Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.