CVE-2026-53211: Linux Kernel Info Disclosure Vulnerability

CVE-2026-53211 Overview

CVE-2026-53211 is an uninitialized memory disclosure vulnerability in the Linux kernel's netfilter bridge subsystem. The flaw resides in nft_meta_bridge_get_eval(), where the NFT_META_BRI_IIFHWADDR expression copies a 6-byte Ethernet MAC address into a register span that the kernel rounds up to 8 bytes. The remaining 2 bytes retain stale nft_do_chain() stack contents. A downstream load of that register span can leak those uninitialized bytes to userspace, exposing kernel stack data.

Critical Impact
Local users with the ability to load nftables bridge rules can read residual kernel stack bytes, potentially exposing pointers, secrets, or other sensitive data useful for bypassing KASLR or escalating subsequent exploitation.

Affected Products

Linux kernel netfilter subsystem (nft_meta_bridge module)
Bridge-family nftables rulesets using the meta iifhwaddr selector
Distributions shipping kernels prior to the upstream stable backports referenced in the patch series

Discovery Timeline

2026-06-25 - CVE-2026-53211 published to NVD
2026-06-25 - Last updated in NVD database

Technical Details for CVE-2026-53211

Vulnerability Analysis

The vulnerability is an Uninitialized Memory Use flaw [CWE-908] in the Linux kernel's nftables bridge metadata expression. The NFT_META_BRI_IIFHWADDR operation retrieves the hardware address of an incoming bridge interface and stores it into an nftables data register for subsequent matching or logging.

nftables registers are 32-bit wide. When an expression declares a destination of ETH_ALEN (6 bytes), the register-tracking logic rounds the allocation up to the next 32-bit boundary, producing an 8-byte span across two registers. The nft_meta_bridge_get_eval() handler issues memcpy(dest, br_dev->dev_addr, ETH_ALEN), writing only the lower 6 bytes. The upper 2 bytes of the second register are never initialized and retain whatever data previously occupied that location on the nft_do_chain() stack frame.

A subsequent rule that loads the full register span — for example, copying it to a userspace-readable destination such as a set element, an NFLOG payload, or an nft_dynset key — exfiltrates the stale stack bytes. The leaked content may include kernel pointers, function return addresses, or fragments of previously processed packets.

Root Cause

The root cause is a mismatch between the declared register length used for allocation tracking and the actual number of bytes written by the evaluation handler. The fix zeroes the second register before the memcpy so that the full declared span is fully written.

Attack Vector

Exploitation requires the ability to install nftables rules in the bridge family, which typically requires CAP_NET_ADMIN in a user namespace or root privileges. In environments where unprivileged user namespaces are enabled, a local unprivileged attacker can construct a bridge ruleset that loads meta iifhwaddr into a register and then exposes that register's contents through a userspace-observable channel, returning the leaked stack bytes for analysis.

Detection Methods for CVE-2026-53211

Indicators of Compromise

Unexpected creation of bridge-family nftables tables and chains by non-administrative users or containerized workloads
nftables rules combining meta iifhwaddr with set updates, dynset operations, or log payloads that expose register contents
Kernel audit events showing nft_compat or nf_tables netlink operations from low-privileged user namespaces

Detection Strategies

Audit nfnetlink socket activity and correlate rule installations against expected administrative baselines
Inspect loaded nftables rulesets with nft list ruleset and flag bridge-family expressions referencing iifhwaddr from untrusted tenants
Enable kernel KASAN or KMSAN in test environments to surface uninitialized memory reads originating from nft_meta_bridge_get_eval

Monitoring Recommendations

Log all CAP_NET_ADMIN acquisitions inside user namespaces and alert on unexpected sources
Track kernel package versions across the fleet and flag hosts running unpatched netfilter modules
Monitor container runtime configurations for permissive --privileged or --cap-add=NET_ADMIN usage that enables bridge-family rule installation

How to Mitigate CVE-2026-53211

Immediate Actions Required

Apply the upstream stable kernel patches referenced as 07acb9798477, c7d573551f92, and f1e81d571e37 from kernel.org
Rebuild or upgrade distribution kernels to a release that incorporates the netfilter fix and reboot affected systems
Restrict creation of user namespaces with CAP_NET_ADMIN where bridge nftables functionality is not required

Patch Information

The fix zeroes the second 32-bit register before the memcpy(dest, br_dev->dev_addr, ETH_ALEN) call in nft_meta_bridge_get_eval(), ensuring the full 8-byte declared span is initialized. Patches are available in the upstream stable tree: Kernel Patch 07acb9798477, Kernel Patch c7d573551f92, and Kernel Patch f1e81d571e37.

Workarounds

Disable the nft_meta_bridge kernel module on systems that do not require bridge-family nftables expressions
Set kernel.unprivileged_userns_clone=0 (or the equivalent user.max_user_namespaces=0) to block unprivileged user namespace creation
Remove CAP_NET_ADMIN from container security profiles and seccomp policies where bridge filtering is not in use

bash

# Configuration example
# Disable unprivileged user namespaces to limit local attack surface
sysctl -w kernel.unprivileged_userns_clone=0
echo 'kernel.unprivileged_userns_clone=0' > /etc/sysctl.d/99-disable-userns.conf

# Prevent automatic load of the affected module where unused
echo 'install nft_meta_bridge /bin/true' > /etc/modprobe.d/disable-nft_meta_bridge.conf