CVE-2026-53211

What it actually does

This is a Linux kernel information-disclosure flaw in the nftables/netfilter bridge metadata path. The bridge input-interface hardware-address metadata field declares a 6-byte Ethernet address but is tracked internally as an 8-byte register span. The vulnerable code copies only the 6-byte address into the destination register and leaves the remaining 2 bytes populated with stale stack data from nft_do_chain(). If an attacker can cause that register span to be returned or otherwise exposed to userspace through nftables rule evaluation, they may read small fragments of uninitialized kernel stack memory. The flaw does not directly provide code execution or privilege escalation, but kernel memory disclosure can sometimes assist exploitation of other vulnerabilities by exposing layout, pointers, or sensitive transient data.

Why it matters to the business

The primary risk is exposure of small amounts of kernel memory from systems using vulnerable Linux kernels with nftables bridge functionality. By itself, this is likely to have limited operational impact and currently has low exploitation likelihood based on available EPSS data, no known KEV listing, no reported ransomware use, and no public exploit maturity indicated. However, because the issue is in the Linux kernel, it may affect many distributions, appliances, containers hosts, and embedded systems once vendor backports are identified, and it should be remediated through normal kernel patching cycles, with higher priority for multi-tenant, container-hosting, network-security, virtualization, or bridge-heavy environments.

How an attack unfolds

An attacker first needs a way to interact with nftables rules that exercise the bridge metadata expression associated with the input-interface hardware address. In typical hardened deployments, creating or modifying nftables rules requires CAP_NET_ADMIN or equivalent administrative privileges; however, systems that allow unprivileged user namespaces, containerized network administration, or delegated firewall management may expose a narrower path to an otherwise less-privileged user. The attacker crafts nftables bridge rules that read the affected metadata field into an nftables register and then uses a downstream operation that causes the full 8-byte tracked register span to be observable from userspace. Because only 6 bytes are initialized with the interface MAC address, the remaining 2 bytes can contain stale kernel stack data. The attacker repeats this process to collect small memory disclosures. The leak is constrained in size per evaluation, but it may be useful for kernel address disclosure or as a supporting primitive when chained with a separate memory-corruption vulnerability.

How to fix it

Apply the Linux kernel update supplied by the relevant operating-system, appliance, container-host, or embedded vendor that includes the netfilter/nft_meta_bridge fix which zeroes the full destination register span before copying the Ethernet address. No fixed package versions were provided in the input, so remediation should be tracked against vendor advisories for the deployed kernel branch and distribution backport level. Where immediate patching is not possible, reduce exposure by limiting CAP_NET_ADMIN delegation, disabling unneeded unprivileged user namespaces where operationally feasible, restricting container privileges related to network administration, limiting nftables rule-management access to trusted administrators, and avoiding use of bridge-family nftables functionality on systems where it is not required. Reboot into the patched kernel after installation; merely installing a kernel package is insufficient if the running kernel is still vulnerable.

How to confirm the fix worked

Confirm the running kernel, not just the installed kernel package, contains the vendor fix. Validate by checking the active kernel version with uname -r and comparing it to the vendor advisory or package changelog that references the netfilter nft_meta_bridge stale stack leak fix. On source-based or custom kernels, confirm the patch behavior in net/netfilter/nft_meta_bridge.c: the destination register span for the bridge input-interface hardware-address metadata path should be fully zeroed before the 6-byte device address is copied. Review whether nftables bridge-family rules are in use and whether any non-administrative users, containers, or automation systems can modify nftables rules. If a vendor scanner is available, run an authenticated vulnerability scan that checks the running kernel build or livepatch state rather than relying only on package inventory.

Typical attack path

1. Obtain local access, container access with delegated network administration, or another path to issue nftables/netfilter configuration operations.
2. Gain the ability to create or modify nftables bridge-family rules, typically requiring CAP_NET_ADMIN or equivalent privileges in the relevant namespace.
3. Create a bridge nftables rule that evaluates the vulnerable bridge input-interface hardware-address metadata path.
4. Trigger packet processing or rule evaluation so the vulnerable nft_meta_bridge_get_eval() path copies only 6 bytes into an internally tracked 8-byte register span.
5. Use a downstream nftables operation to expose or infer the full register span from userspace.
6. Repeat the process to collect small stale kernel stack disclosures and, if possible, use them to aid further exploitation of another vulnerability.

How to detect it

Retrospective detection is difficult because successful exploitation may not create a distinctive kernel log entry, crash, or file artifact. Focus on evidence that an untrusted or unexpected actor created, modified, listed, or rapidly exercised nftables bridge-family rules. Useful log sources include Linux auditd records for nft/nftables command execution, execve telemetry, sudo logs, shell history where available, EDR process telemetry, container runtime logs showing privileged or CAP_NET_ADMIN containers, and kernel/audit records for NETLINK_NETFILTER activity if enabled. Review for nftables rule changes involving the bridge family, unexpected use of the nft command, firewall-management activity from service accounts or containers, and bursts of rule creation/deletion followed by traffic generation. On systems with syscall or eBPF telemetry, look for processes opening NETLINK_NETFILTER sockets and issuing rule-management operations from unusual users, containers, or paths. Because no public exploit indicators, threat actors, or KEV exploitation are currently known from the supplied data, absence of these artifacts does not prove the flaw was not exploited; combine log review with privilege exposure analysis and kernel patch validation.

• nft_meta_bridge_get_eval
• nft_meta_bridge
• NFT_META_BRI_IIFHWADDR
• IIFHWADDR
• NETLINK_NETFILTER
• NFT_MSG_NEWRULE
• NFT_MSG_DELRULE
• NFT_MSG_GETRULE
• nft add rule bridge
• nft -f
• /usr/sbin/nft
• /sbin/nft
• CAP_NET_ADMIN

What your security team should do

• Prioritize kernel updates on systems that permit containers, user namespaces, delegated network administration, firewall-as-a-service workflows, virtualization networking, or Linux bridge/nftables bridge-family rule management.
• Inventory systems using nftables bridge-family rules and identify where CAP_NET_ADMIN is granted to containers, service accounts, or non-root operators.
• Patch through the appropriate vendor kernel update channel and reboot or livepatch according to vendor instructions; verify the active running kernel contains the fix.
• Where patching is delayed, restrict CAP_NET_ADMIN, disable unnecessary unprivileged user namespaces, remove unnecessary privileged containers, and limit nftables rule changes to trusted administrative paths.
• Enable or review audit logging for nftables rule creation and netfilter netlink activity on high-risk Linux hosts.
• Treat this primarily as an information leak; investigate it more aggressively if observed alongside kernel crashes, suspicious privilege-escalation attempts, unexpected nftables rule changes, or activity by users/processes that should not manage firewall rules.