In early 2024, a vulnerability was discovered and quickly patched in the Linux kernel’s netfilter nf_tables subsystem, tracked as CVE-2024-27012. This issue revolves around incorrect state restoration when a set deletion operation fails, leading to potential use-after-free (UAF), resource leakage, or memory corruption. Here, we break down the vulnerability in plain language, review the technical root cause, show code snippets, and explain how an attacker might exploit such a flaw.

What is nf_tables?

nf_tables is a powerful framework providing stateful packet filtering and manipulation in the Linux kernel, widely used for modern firewalls (like in iptables and nftables). It organizes its rule data into sets. Managing these sets correctly is crucial for kernel stability and security.

The Problem

When a set is deleted in nf_tables and the deletion fails part way (due to memory allocation problems or race conditions, for instance), the kernel must revert all affected elements (restore their reference counters and activity state). But due to a logic bug in the restoration/abort path, the kernel used the wrong element-walking logic:

The normal iterator skipped inactive elements (assumed: "skip objects not in use").

- During abort, however, we needed to skip active elements, since those had just been "deactivated" and must now be re-activated.

The code ran the wrong filter, resulting in missing some elements when restoring. This caused elements to be left in the wrong state, potentially leaking objects, corrupting memory management, and triggering warnings like nft_setelem_data_deactivate+xe4/xf [nf_tables].

Here’s a real-world kernel warning that could occur because of this flaw

WARNING: CPU:  PID: 1139 at include/net/netfilter/nf_tables.h:1237 nft_setelem_data_deactivate+xe4/xf [nf_tables]
...
RIP: 001:nft_setelem_data_deactivate+xe4/xf [nf_tables]
...
Call Trace:
nft_mapelem_deactivate+x24/x30 [nf_tables]
nft_rhash_walk+xdd/x180 [nf_tables]
nft_map_deactivate+xdc/x1e [nf_tables]
nft_delset+xff/x110 [nf_tables]
nft_flush_table+x16f/x460 [nf_tables]
nf_tables_deltable+x501/x580 [nf_tables]

Patch Overview

Solution: The patch moved the filtering logic for active/inactive elements out of the set’s iterator and into the iterator callback. That way, which elements are skipped depends on the context (regular walk, or abort path). The logic is reversed for restoration (abort) paths. The patch also toggles the "next generation" bit for set elements properly.

Patch reference:
netfilter: nf_tables: restore set elements when delete set fails
*Linux commit cef5b62b893de9d2bf8c9484c9cb774dab03032 (Feb 2024)*

1. Original Problematic Code (Before Patch)

// Src: net/netfilter/nf_tables_core.c
set->ops->walk(set, ctx, private, nft_set_dump_elem); // misapplied logic!

The set iterator here always skipped "inactive" elements, also in the abort scenario—wrong behavior for restoration.

2. Patched Code Snippet (After Patch)

// New iterator callback: decide inside the callback what to skip
if (activation_case)
    if (is_active(elem)) // skip
        return;
else
    if (is_inactive(elem)) // skip
        return;

//... process restoration on the correct elements
nft_clear(elem);

Key Change:
The filtering (active/inactive) is not hardcoded, but context-dependent. On abort, restoration properly covers only those elements changed during the failed operation.

What Can Go Wrong?

If a privileged program (even root) tried to delete a set and the operation failed mid-way, elements could remain in a half-deleted state:

Use-After-Free: Set element not reactivated, but another operation accesses it

- Kernel panic/crashes: If memory is accessed after it's freed
- Possible privilege escalation: Carefully crafted attacks might get code execution in kernel context (although this needs deeper proof-of-concept and is architecture/timing dependent)

Create a large or fragmented set.

2. Trigger a set deletion while making kernel conditions unstable (low memory, concurrent activity, many rulesets, etc.).

Example (very high-level, not a full exploit)

# Userland nftables rules
table inet filter {
    set badset {
        type ipv4_addr
        elements = { 192..2.1 }
    }
}

With enough iterations and timing (fuzzing), kernel errors can be triggered.

*Note:* Crafting a full working exploit for privilege escalation requires deep kernel knowledge and is not currently public, but this bug provides a theoretical attack path.

Mitigation

- Update your Linux kernel! All major distributions patched this quickly. Check your distro’s security trackers (example from Red Hat, Debian).

Upstream Patch and Discussion:

netfilter: nf_tables: restore set elements when delete set fails (commit)

CVE Details:

CVE-2024-27012 at cve.org

Red Hat Security Tracker:

Red Hat Bugzilla for CVE-2024-27012

Conclusion

CVE-2024-27012 serves as a reminder of the depth of low-level logic issues that can lead to memory corruption in the Linux kernel. If you manage Linux machines—especially those running modern firewall frameworks—patch as soon as possible to stay safe. Even without public exploits, such bugs are attractive for attackers with kernel access.

Stay up to date. Stay secure!

Want to test or learn more?
Check out nftables official documentation and experiment on a test VM—don’t try this on production systems!

Timeline

Published on: 05/01/2024 06:15:19 UTC
Last modified on: 06/14/2024 18:56:19 UTC