CVE-2024-1086

What it actually does

This is a local privilege-escalation flaw in the Linux kernel netfilter nf_tables subsystem. A low-privileged local user can abuse incorrect handling of positive drop-error values in nft_verdict_init(), causing nf_hook_slow() to free the same object twice. The resulting use-after-free/double-free condition can corrupt kernel memory and, with a reliable exploit, allow execution with kernel privileges, typically resulting in root access. Exploitation generally requires local code execution and access to nftables functionality, often through user and network namespaces that grant CAP_NET_ADMIN inside the namespace.

Why it matters to the business

Successful exploitation can turn an ordinary local account or compromised application user into full administrative control of the Linux host. This can lead to data theft, security tool tampering, lateral movement, container or workload compromise, destructive actions, and ransomware deployment. The issue is listed in CISA KEV, has active in-the-wild exploitation, is associated with ransomware use, and had a CISA remediation deadline of 2024-06-20, making unpatched systems a high-priority operational risk despite requiring local access.

How an attack unfolds

An attacker first needs some way to run code on the target Linux system, such as a compromised low-privileged account, exploited web application, malicious package, container foothold, or post-exploitation shell. The attacker checks whether the running kernel is vulnerable and whether nftables, network namespaces, and unprivileged user namespaces are available. If enabled, they create a user and network namespace to gain CAP_NET_ADMIN inside that namespace, then use crafted nf_tables/netlink rule operations to create a malicious verdict path. By triggering packet processing through the affected hook, the kernel mishandles an NF_DROP verdict with a positive drop error that resembles NF_ACCEPT, causing a double free/use-after-free. The exploit then performs kernel heap grooming to convert the memory corruption into privilege escalation, commonly by modifying process credentials or another kernel control structure. Once root is obtained, the attacker can install persistence, dump credentials, disable defenses, move laterally, or deploy ransomware.

How to fix it

Upgrade the Linux kernel to a version that includes upstream commit f342de4e2f33e0e39165d8639387aa6c19dff660 or the equivalent fix from the Linux distribution or appliance vendor. Because kernel fixes are commonly backported without changing to the newest upstream version number, validate by vendor advisory/package changelog rather than version string alone. Reboot systems after installing the fixed kernel and confirm they are actually running the patched kernel. Where immediate patching is not possible, reduce exploitability by disabling or restricting unprivileged user namespaces where operationally feasible, limiting access to containers and local shells, restricting CAP_NET_ADMIN, preventing untrusted users from using nftables/netlink firewall configuration paths, and applying mandatory access controls such as SELinux or AppArmor. These mitigations reduce exposure but should not be treated as a substitute for patching.

How to confirm the fix worked

Confirm the running kernel is fixed, not just that a fixed package is installed. Use system package tools and vendor advisories to verify the kernel includes the fix for the nf_tables double-free issue or the upstream commit f342de4e2f33e0e39165d8639387aa6c19dff660. Check the active kernel with uname -a after reboot. Review whether nf_tables is loaded or available using lsmod, modinfo, or kernel configuration data. Validate namespace exposure by checking controls such as kernel.unprivileged_userns_clone on distributions that support it and by reviewing container runtime configurations that grant CAP_NET_ADMIN. For source-built kernels, confirm the fixed commit is present in the kernel tree. For fleets, inventory all Linux kernels, including container hosts, virtualization hosts, appliances, CI runners, and developer workstations, because local privilege-escalation bugs are often used after an initial foothold.

Typical attack path

1. Gain local code execution on a Linux host through an existing account, application compromise, container foothold, or malware execution.
2. Identify the running kernel version and confirm that the kernel is missing the upstream fix or equivalent vendor backport.
3. Check whether nf_tables is present and whether user/network namespaces allow access to nftables operations from an unprivileged context.
4. Create a user namespace and network namespace to obtain CAP_NET_ADMIN within the namespace, if required.
5. Send crafted nf_tables/netlink operations that create a vulnerable verdict condition involving NF_DROP and a positive drop error.
6. Trigger packet traversal through the affected netfilter hook to cause the double-free/use-after-free in kernel memory.
7. Use heap grooming and kernel memory corruption primitives to overwrite security-relevant kernel state.
8. Escalate to root or kernel-equivalent privileges.
9. Use elevated access to disable controls, steal data, establish persistence, pivot, or deploy ransomware.

How to detect it

This vulnerability is a local privilege-escalation issue and successful exploitation may leave few deterministic artifacts, so detection should focus on behavioral evidence before and after escalation. Review auditd, syslog, journald, EDR telemetry, shell history, process execution logs, container runtime logs, and kernel logs. Look for unprivileged users creating user and network namespaces, invoking nft or netlink-based nf_tables operations, receiving CAP_NET_ADMIN inside a namespace, and then quickly spawning a root shell or modifying privileged files. Kernel logs may show crashes, warnings, use-after-free, double-free, general protection faults, or nf_tables-related oops messages, although reliable exploits may avoid crashing. Hunt for suspicious sequences such as unshare or namespace creation followed by nftables rule manipulation and then root-owned process execution from writable directories such as /tmp, /var/tmp, /dev/shm, or container overlay paths. Because this flaw is known exploited and associated with ransomware activity, also inspect for post-escalation activity: disabling EDR/AV agents, stopping backup services, mass file encryption, credential dumping, new SSH keys, new privileged users, cron/systemd persistence, and unusual outbound connections. Correlate exposure windows against the date patched/rebooted and prioritize hosts that had vulnerable kernels active after public exploitation became known or after the KEV due date.

• nft_verdict_init
• nf_hook_slow
• nf_tables
• nf_tables_api.c
• KASAN: use-after-free
• KASAN: double-free
• BUG: KASAN: use-after-free in nft_verdict_init
• BUG: KASAN: double-free in nf_hook_slow
• kernel BUG at net/netfilter/nf_tables_api.c
• general protection fault
• Oops: 0000
• NETLINK_NETFILTER
• unshare -Ur
• unshare -U -n
• CLONE_NEWUSER
• CLONE_NEWNET
• CAP_NET_ADMIN
• /proc/sys/kernel/unprivileged_userns_clone
• /usr/sbin/nft
• /sbin/nft
• /bin/nft
• /tmp/
• /var/tmp/
• /dev/shm/

What your security team should do

• Prioritize patching internet-facing Linux servers, multi-user systems, container hosts, CI/CD runners, virtualization hosts, and systems that process untrusted workloads.
• Treat systems that were unpatched after the CISA KEV due date of 2024-06-20 as requiring urgent review, especially where local shell access or container workloads are present.
• Reboot after kernel updates and verify the running kernel, because installing a fixed kernel package without rebooting leaves the vulnerable kernel active.
• Temporarily disable or restrict unprivileged user namespaces where feasible, and remove unnecessary CAP_NET_ADMIN grants from containers and service accounts.
• Hunt for evidence of local privilege escalation, suspicious nftables manipulation, namespace creation, kernel crashes, and unexpected root shells on systems that were exposed.
• Review EDR and audit logs for low-privileged processes spawning root shells, modifying security tools, changing firewall rules, loading kernel modules, or writing persistence after local execution.
• Apply least privilege to local accounts, service users, build agents, and containers to reduce the number of principals that can reach the vulnerable code path.
• Monitor vendor advisories for distribution-specific fixed kernel package names and backported fixes rather than relying only on upstream version comparisons.
• If compromise is suspected, preserve volatile evidence quickly, including process lists, kernel logs, audit logs, loaded modules, nftables state, and memory where possible.