CVE-2026-53134

What it actually does

This is a Linux kernel netfilter/nftables information disclosure flaw in the nft_fib expression. When nft_fib is configured to return an output interface name, some failure or mismatch paths initialize only one 32-bit register even though the declared destination spans IFNAMSIZ bytes. A later nftables expression can copy or expose the full register span, allowing uninitialized kernel stack bytes from nft_do_chain() to be leaked to userspace. A related validation issue allowed the NFTA_FIB_F_PRESENT existence check to be used with result types where only a single byte was written, creating another stale-register disclosure path. The impact is read-only kernel memory exposure, not direct code execution or privilege escalation by itself.

Why it matters to the business

Successful exploitation could allow a local attacker with permission to create or modify nftables rules to expose small amounts of kernel stack memory. While the disclosed data is limited and the public exploitation maturity is currently listed as none, kernel memory disclosure bugs can help attackers defeat exploit mitigations or support follow-on local privilege-escalation chains. The issue is not in CISA KEV, has low EPSS at the time of assessment, and should generally be prioritized as part of routine kernel maintenance unless the environment delegates CAP_NET_ADMIN, runs untrusted containers with network administration privileges, or permits users to manipulate nftables.

How an attack unfolds

An attacker first needs local access with the ability to install or alter nftables rules, typically through CAP_NET_ADMIN, root-equivalent privileges inside a network namespace, or a misconfigured container/runtime delegation. They create nftables rules using the fib expression with an output-interface-name result or an invalid/overbroad present-check combination that causes nft_fib evaluation to take a lookup-failure, local-route, or output-interface-mismatch path. On those paths, vulnerable kernels clear only part of the destination register while leaving the rest of the declared register span populated with stale stack data from nft_do_chain(). The attacker then chains another nftables expression that reads, compares, logs, copies, or otherwise returns the register span to userspace through netfilter/nftables behavior, allowing recovery of uninitialized kernel stack bytes. The leak is likely iterative and low-bandwidth, but repeated triggering may reveal addresses or sensitive transient stack values useful for bypassing kernel hardening in a separate exploit chain.

How to fix it

Upgrade to a Linux kernel version or vendor kernel build that includes the nft_fib fix. The corrected behavior pads or fully initializes the IFNAMSIZ-sized output-interface-name destination and restricts NFTA_FIB_F_PRESENT to the valid NFT_FIB_RESULT_OIF case with a one-byte destination. Because exact fixed package versions were not provided, use the relevant distribution or appliance advisory and install the first kernel build that explicitly references this CVE or the upstream netfilter/nft_fib stale stack leak fix. Mitigations where immediate patching is not possible include restricting CAP_NET_ADMIN, avoiding privileged or network-admin containers, limiting access to user namespaces where feasible, auditing who can load nftables rules, and blocking untrusted users from modifying nftables policy. Reboot into the patched kernel after installation; merely installing the package is not sufficient if the running kernel remains vulnerable.

How to confirm the fix worked

Confirm the running kernel, not only the installed kernel package, has been updated to a build containing the fix. Validate with uname -r, distribution package metadata, vendor advisory references, or kernel changelog entries mentioning netfilter, nft_fib, OIFNAME, IFNAMSIZ, NFTA_FIB_F_PRESENT, or stale stack leak. Review nftables rulesets for fib expressions returning output interface names or using fib present checks in unusual combinations. Confirm that only expected administrators and automation can change nftables rules and that containers are not unnecessarily granted CAP_NET_ADMIN. In high-assurance environments, perform a controlled regression test on a non-production system using vendor-provided proof or kernel selftests if available, and verify that crafted fib expressions no longer return uninitialized bytes.

Typical attack path

1. Obtain local access to a Linux system where nftables/netfilter is available.
2. Gain or abuse permission to manage nftables rules, such as CAP_NET_ADMIN, root in a namespace with netfilter access, or an overly privileged container.
3. Install a crafted nftables rule using a fib expression that requests an output interface name result or an unsupported present-check/result combination.
4. Trigger packets or route lookups that drive nft_fib through lookup-failure, RTN_LOCAL, or output-interface-mismatch paths.
5. Use a downstream nftables expression to read or expose the incompletely initialized register span.
6. Collect leaked kernel stack bytes from userspace-visible nftables behavior or logs.
7. Optionally repeat the process to gather enough memory disclosure to aid a separate kernel exploitation attempt.

How to detect it

This vulnerability is difficult to detect from standard network telemetry because exploitation is local and occurs through nftables rule evaluation inside the kernel. Focus detection on evidence that an attacker or unexpected process modified nftables rules, especially rules using fib expressions with output interface name results or present checks. Useful sources include auditd syscall logs for nft command execution and netlink NETFILTER_CFG activity, shell history, process execution telemetry, EDR events, sudo logs, container runtime events granting CAP_NET_ADMIN, Kubernetes pod security context changes, and nftables ruleset snapshots. Investigate unexpected invocations of nft, iptables-nft, firewall automation tools, or processes opening NETLINK_NETFILTER sockets. For forensics, capture `nft list ruleset` output, compare it with known-good configuration, review recent package/kernel update status, and check whether suspicious rule changes occurred before any local privilege-escalation or crash events. There are no reliable remote network indicators, and leaked bytes may not produce kernel logs or crashes.

• fib oifname
• NFTA_FIB_F_PRESENT
• NFT_FIB_RESULT_OIFNAME
• NFT_MSG_NEWRULE
• NETLINK_NETFILTER
• netfilter: nft_fib
• nft_fib4_eval
• nft_fib6_eval
• nft add rule
• nft insert rule
• nft -f
• /usr/sbin/nft
• /sbin/nft
• CAP_NET_ADMIN

What your security team should do

• Inventory Linux systems using nftables/netfilter and identify kernels that predate the vendor fix.
• Prioritize patching internet-facing hosts, multi-tenant systems, container hosts, Kubernetes nodes, CI runners, and systems where untrusted users may obtain CAP_NET_ADMIN or network namespace control.
• Reboot systems after applying fixed kernel packages and verify the active kernel version.
• Remove CAP_NET_ADMIN from containers, services, and users that do not explicitly require it.
• Audit nftables rule-change activity for unexpected fib expressions, especially those involving output interface names or present checks.
• Review sudoers, container runtime profiles, systemd unit capabilities, and orchestration policies for unintended nftables administration rights.
• Monitor for unusual local nft/nftables activity until patching is complete, especially on shared systems.
• Treat any confirmed memory disclosure as a potential precursor to privilege escalation and perform broader host investigation if suspicious nftables manipulation is found.