CVE-2026-97965

About vulnerability

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.

Affected product:

AlmaLinux 9.2 ESU , Amazon Linux 2 ELS , CentOS 8.4 ELS , CentOS 8.5 ELS , CentOS Stream 8 ELS , Debian 10 ELS , Debian 11 ELS , Oracle Linux 7 ELS , TuxCare 9.6 ESU , TuxCare 9.8 ESU , Ubuntu 16.04 ELS , Ubuntu 18.04 ELS , Ubuntu 20.04 ELS

Affected packages:

linux @ 5.10.259 (+13 more)

Live-patch status from KernelCare for each operating system.