CVE-2026-52988

What it actually does

This is a race condition in the Linux kernel netfilter nf_tables subsystem. During concurrent nftables ruleset updates and netlink dump traversal, newly added hooks for base chains or flowtables were not published to the hook list in an RCU-safe way. A racing reader could observe an inconsistent list state, potentially causing kernel memory-safety failures such as crashes, warnings, use-after-free-like behavior, or other undefined kernel behavior. Exploitation generally requires local ability to interact with nf_tables through netlink, typically via CAP_NET_ADMIN in the relevant network namespace or equivalent container/network administration privileges.

Why it matters to the business

Successful exploitation can destabilize Linux systems that use nftables, causing host outages or disruption to container and networking workloads. In higher-risk configurations where untrusted users can obtain network-namespace administration capabilities, the issue may increase the risk of local denial of service and potentially broader kernel compromise if the race can be shaped into memory corruption. The available public exploitation signal is currently low: EPSS is 0.00122, no known CISA KEV listing, no ransomware association, and no public exploit maturity reported, so remediation should be prioritized as part of normal kernel patching unless exposed systems grant untrusted users CAP_NET_ADMIN or unprivileged user namespaces.

How an attack unfolds

An attacker first obtains local code execution on a Linux system or inside a container where they can perform nf_tables netlink operations. They then repeatedly start nftables ruleset transactions that add or modify base-chain or flowtable hooks while, in parallel, triggering netlink dumps such as ruleset, chain, or flowtable listing operations. On vulnerable kernels, the commit path can publish new hook-list entries in a way that is unsafe for concurrent RCU readers. With sufficient timing, the dump traversal can observe a partially updated or inconsistent list. The most likely observable outcome is a kernel warning, oops, panic, or networking subsystem crash; depending on kernel build, hardening, and memory layout, unsafe list traversal could potentially be investigated for stronger local privilege-escalation primitives. There is no indication from the provided intelligence that this is being exploited in the wild.

How to fix it

Apply the vendor-provided Linux kernel update that includes the nf_tables fix described as publishing new hooks into the basechain or flowtable hook list using splice_list_rcu() during the commit phase. Because no exact affected products or fixed package versions were provided, use distribution advisories and kernel changelogs to identify the first fixed kernel for each supported platform. Reboot into the fixed kernel after installation; merely installing the package is not sufficient if the running kernel remains vulnerable. Where immediate patching is not possible, reduce exposure by restricting CAP_NET_ADMIN to trusted workloads only, avoiding privileged containers, disabling or tightly controlling unprivileged user namespaces where operationally feasible, limiting access to nftables management interfaces, and monitoring for unexpected nft command use. Disabling nf_tables may mitigate exposure only if the system can safely operate without nftables-backed firewalling, container networking, or orchestration components that depend on it.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, has been updated by checking the active kernel version after reboot and comparing it with the relevant distribution advisory. Review kernel package changelogs or source patches for the nf_tables change referencing RCU-safe hook-list publication, splice_list_rcu(), basechain hooks, or flowtable hooks. Verify whether nf_tables is present or loaded using module and kernel configuration checks, and confirm which systems grant CAP_NET_ADMIN to containers or non-administrative users. In a controlled non-production environment, regression testing can include concurrent nftables ruleset updates and nft list/dump operations to confirm the kernel remains stable; do not attempt race-condition stress testing on production systems. Validate mitigation by confirming untrusted users cannot create network namespaces or issue nf_tables netlink operations.

Typical attack path

1. Gain local execution on a Linux host or in a container with access to nf_tables netlink operations.
2. Obtain or abuse CAP_NET_ADMIN in a network namespace, or rely on a configuration that permits unprivileged user namespaces combined with network namespace creation.
3. Create nftables tables, base chains, or flowtables and prepare transactions that add hooks.
4. Concurrently trigger nftables netlink dump operations, such as listing rulesets, chains, or flowtables, while committing hook-list updates.
5. Repeat the update-and-dump race at high frequency to widen the timing window.
6. Cause the kernel to traverse an inconsistent hook list, leading to a kernel oops, panic, denial of service, or potentially exploitable memory-safety behavior.

How to detect it

Look for evidence of local attempts to race nftables configuration updates with nftables listing or dump operations. Primary sources include kernel logs, journalctl, dmesg, auditd execve records, EDR process telemetry, container runtime logs, and sudo/session logs. Suspicious activity includes repeated or high-frequency execution of nft commands, rapid creation and deletion of nftables tables, chains, flowtables, or hooks, and concurrent listing of nftables rulesets. Kernel telemetry of interest includes oops, panic, RCU, KASAN, lockdep, general-protection-fault, NULL-pointer, or list-corruption messages involving nf_tables, nft_chain, nft_flowtable, or netfilter code paths. For containerized environments, correlate kernel crashes or host instability with containers granted CAP_NET_ADMIN or privileged mode. Because no public exploit-specific indicators are provided, detection should focus on behavioral patterns and kernel failure artifacts rather than fixed signatures.

• nf_tables
• nft list ruleset
• nft add flowtable
• nft add chain
• nft delete flowtable
• nft delete chain
• CAP_NET_ADMIN
• KASAN: use-after-free
• BUG: unable to handle kernel
• general protection fault
• kernel NULL pointer dereference
• list_del corruption
• list_add corruption
• RCU stall
• kernel panic
• Oops:
• netfilter
• nft_chain
• nft_flowtable
• nf_tables_commit
• nf_tables_dump
• /usr/sbin/nft
• /sbin/nft

What your security team should do

• Inventory Linux systems that use nftables, container networking, Kubernetes/container hosts, firewalls, routers, and systems where nf_tables modules are loaded.
• Prioritize patching systems that allow untrusted local users, privileged containers, CAP_NET_ADMIN delegation, or unprivileged user namespaces.
• Update to a vendor kernel containing the nf_tables splice_list_rcu() commit-phase fix and reboot into the fixed kernel.
• Restrict CAP_NET_ADMIN and privileged-container use to trusted workloads; remove unnecessary network namespace creation rights.
• Review audit, EDR, and shell telemetry for unexpected nftables manipulation by non-administrative users.
• Enable or tune kernel crash, oops, and panic log collection so suspected exploitation attempts are retained after reboot.
• If immediate patching is delayed, consider temporary hardening such as disabling unprivileged user namespaces where compatible with business requirements.
• Track vendor advisories because exact fixed package versions vary by distribution and kernel branch.