CVE-2026-63858

What it actually does

This is a Linux kernel use-after-free flaw in the netfilter nf_tables subsystem involving hook handling during device deletion transactions. The vulnerable logic can break RCU-protected netlink dump readers by moving hook objects between lists during the transaction preparation phase, creating a window where stale kernel memory may be accessed. A local attacker with sufficient privileges to manipulate nftables or related network namespace/netfilter state may be able to trigger kernel memory corruption, potentially causing a denial of service through a kernel crash or, in a successful exploit, local privilege escalation with kernel-level code execution. The CVSS vector indicates local access, low attack complexity, low privileges required, no user interaction, and high confidentiality, integrity, and availability impact.

Why it matters to the business

Successful exploitation could allow a local user or compromised workload to crash affected Linux systems or escalate privileges to gain full control of the host. This is most relevant for multi-user Linux servers, container platforms, CI/CD runners, shared hosting, and systems that allow unprivileged user namespaces or grant containers CAP_NET_ADMIN. Although EPSS is currently low and there is no known KEV listing or reported ransomware use, kernel privilege-escalation vulnerabilities can become operationally significant if exploit code becomes public, especially across large Linux fleets.

How an attack unfolds

An attacker first needs local code execution on an affected Linux system, such as a shell account, compromised service account, container escape foothold, or workload with access to network namespace and nftables functionality. The attacker then manipulates nf_tables state by creating base chains or flowtables with hooks tied to network devices and triggering device deletion or related transaction cleanup while netlink dump readers may still reference the RCU-protected hook list. On vulnerable kernels, the hook object lifecycle can become inconsistent, causing a use-after-free condition. A simple exploitation attempt may only crash the kernel, but a more reliable exploit could shape heap allocations and reclaim the freed object to control kernel memory, potentially escalating privileges to root or executing code in kernel context. Exploitation is local rather than remote, and systems that restrict unprivileged user namespaces and CAP_NET_ADMIN exposure reduce the reachable attack surface.

How to fix it

Upgrade the Linux kernel to a vendor-supported version that includes the nf_tables fix for hook transactions during device deletion. Because no specific fixed package versions were provided, use the relevant distribution security advisory or upstream stable kernel release notes to identify the corrected kernel for each platform. Reboot systems after kernel updates to ensure the patched kernel is running. Where immediate patching is not possible, reduce exposure by disabling unprivileged user namespaces where operationally feasible, avoiding unnecessary CAP_NET_ADMIN grants to containers and services, limiting access to nftables administration, unloading or preventing use of nf_tables where not required, and applying container runtime/seccomp/AppArmor/SELinux controls that restrict namespace and netlink operations. Treat mitigations as temporary; kernel patching is the durable fix.

How to confirm the fix worked

Confirm that affected systems are running a patched kernel, not merely that the package is installed. Validate with commands such as `uname -a`, distribution package tooling, and vendor advisory mappings to ensure the running kernel contains the nf_tables transaction fix. Check whether nf_tables is present or loaded using `lsmod | grep nf_tables` and whether nftables is in active use with `nft list ruleset`. Review whether unprivileged user namespaces are enabled, for example via `/proc/sys/kernel/unprivileged_userns_clone` on distributions that expose it, and audit containers or services granted CAP_NET_ADMIN. For engineering validation, a kernel with KASAN or other sanitizers should no longer report use-after-free conditions when exercising nftables hook creation, device deletion, namespace teardown, and netlink dump paths. After remediation, reboot and verify that no older vulnerable kernel remains selected in the bootloader.

Typical attack path

1. Obtain local execution on an affected Linux host or inside a container with enough namespace/netfilter privileges.
2. Determine whether nf_tables is available, loaded, and usable from the current privilege context.
3. Create or modify nftables base chains or flowtables with hooks associated with network devices.
4. Trigger device deletion, namespace teardown, or related nf_tables transaction cleanup while netlink dump/read paths interact with hook lists.
5. Cause the vulnerable use-after-free condition in the kernel nf_tables hook handling path.
6. Use the memory corruption condition to crash the host or attempt controlled kernel memory corruption for local privilege escalation.
7. If privilege escalation succeeds, establish root-level control, disable defenses, access sensitive data, or pivot to other workloads and systems.

How to detect it

There are no reliable network indicators for this vulnerability because exploitation is local and occurs inside the Linux kernel. To assess possible prior exploitation, review kernel logs and crash artifacts for use-after-free, slab corruption, RCU, nf_tables, nftables, or netfilter-related faults around times when local users or containers manipulated network namespaces or nftables rules. Relevant sources include `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, `/var/crash/`, kdump/vmcore repositories, auditd logs, EDR process telemetry, container runtime logs, and sudo/session logs. Look for suspicious execution of `nft`, `unshare`, `ip netns`, namespace-heavy tooling, or processes that unexpectedly gained root privileges shortly before a kernel crash or privilege escalation event. In container environments, correlate crashes or kernel warnings with containers granted CAP_NET_ADMIN or workloads creating/deleting network namespaces and virtual interfaces. Absence of these artifacts does not prove non-exploitation, because a successful kernel privilege escalation may leave minimal logs or tamper with local evidence.

• BUG: KASAN: use-after-free
• use-after-free
• nf_tables
• nftables
• netfilter
• NFT_HOOK_REMOVE
• nft_trans_chain_hooks
• general protection fault
• kernel NULL pointer dereference
• slab-use-after-free
• RCU-list
• list_del corruption
• kernel BUG at net/netfilter
• nft
• /usr/sbin/nft
• /sbin/nft
• unshare --user
• unshare --net
• ip netns
• CAP_NET_ADMIN
• /proc/sys/kernel/unprivileged_userns_clone
• nf_tables.ko

What your security team should do

• Prioritize patching internet-facing, multi-user, container-hosting, CI/CD, and shared Linux systems even though current EPSS is low and the issue is not listed in CISA KEV.
• Inventory Linux hosts and container platforms where nf_tables is enabled, nftables is used, unprivileged user namespaces are allowed, or workloads receive CAP_NET_ADMIN.
• Upgrade to vendor-fixed kernels and reboot; track systems that have installed but not booted into the patched kernel.
• Temporarily restrict unprivileged user namespaces and remove unnecessary CAP_NET_ADMIN from containers and services until patching is complete.
• Increase monitoring for kernel crashes, KASAN reports, general protection faults, and suspicious local privilege-escalation activity involving nft, unshare, network namespaces, and nf_tables.
• Harden container runtimes with least privilege capabilities, seccomp, AppArmor, or SELinux policies that limit netlink and namespace abuse.
• Because no public exploit maturity is currently reported, monitor vendor advisories, exploit repositories, and threat intelligence for changes in exploit availability or active exploitation.