CVE-2024-27397 - Linux Kernel netfilter nf_tables Timeout Vulnerability Explained

A recent security issue, tracked as CVE-2024-27397, was found and fixed in the Linux kernel's nf_tables subsystem. This bug deals with set element expiry during control plane transactions, and could potentially let elements expire _improperly_ before a transaction finishes. This flaw, if exploited, could result in issues for systems using nftables for firewall or packet filtering, especially in high load or precision environments.

In this post, we'll break down what went wrong, how it was fixed, include example code, and discuss possible exploitation scenarios in simple terms. This is exclusive, human-readable guidance for users, sysadmins, and Linux enthusiasts.

What is the Issue?

nf_tables is part of the Netfilter framework, which handles packet filtering and processing in Linux. Sets in nf_tables can have elements that _expire_ after a timeout. Normally, the kernel checks if these elements should expire based on the current system time.

However, when performing configuration transactions (like adding/removing elements), there was a race condition: it was possible for an element to reach its expiration time and be deleted in the middle of a transaction. This could cause unexpected behavior, rules vanishing, or incomplete transaction effects.

Technical Root

The core of the problem? The code used real-time checks for expiry _even during transactions_. Transactions can take some time, especially under load. An element could “disappear” unexpectedly if its timeout hit in the middle of a transaction.

The Fix: Adding Transaction Timestamps

To solve this, developers added a timestamp associated with a transaction. This timestamp is set _at the start of the transaction_ and stored in the per-netns (network namespace) data area. Backend logic for operations like .insert, .deactivate, and the garbage collection path now check element timeout against this fixed timestamp. This makes the transaction consistent and predictable.

Packet handling (.lookup, .update): expiry is checked against real current time (for live traffic).

- Other code paths (like async garbage collector): still use real time because they run separately from transactions.

Below, the patch logic has been simplified for demonstration

// Record the transaction timestamp (simplified)
pernet->trans_start = ktime_get_real_seconds();

// When inserting or cleaning up elements in a transaction:
if (now >= elem->expires) {
    // Element has expired relative to the transaction start time
    // Clean it up or skip
}

// For packet path, still use current time:
if (ktime_get_real_seconds() >= elem->expires) {
    // Apply normal expiry processing
}

This change prevents set elements from expiring _during_ a config transaction, even if their timeout technically arrives before the transaction finishes.

Exploitation Potential

While not a classic "remote code execution" bug, CVE-2024-27397 could be abused in the following ways:

- Firewall Bypass: Attackers could trigger mass ruleset updates or timeouts, causing firewall rules to drop when they shouldn’t.
- Denial-of-Service (DoS): By creating many transactions and manipulating timeouts, it might be possible to induce packet drops, network splits, or race-related logic errors.

Example Exploit Scenario

Suppose an attacker or buggy process rapidly adds and removes set elements with very short timeouts, racing against transaction completion. If a rule element expires at just the “wrong” moment, the netfilter subsystem could “forget” to apply or remove a firewall rule as expected.

Here is a pseudo-code example to demonstrate the race

# Add a rule with a 1-second timeout using nft
nft add set inet filter myset { type inet_service; timeout 1s; }

# Rapidly start transactions to insert/remove elements
for i in $(seq 1 100); do
  nft add element inet filter myset { 80 }
  sleep .9  # Wait almost until expiry
  nft delete element inet filter myset { 80 }
done

Previously, if the transaction took long enough, set elements could expire _during_ operations, possibly leading to inconsistencies that would not otherwise happen.

Fix commit:

netfilter: nf_tables: use timestamp to check for set element timeout

CVE Details:

CVE-2024-27397 at MITRE

Linux Kernel Netfilter Project:

Netfilter/nftables Official Site

Am I Vulnerable? How Do I Patch?

- Affected kernels: Linux kernels before the patch in early 2024 (check your distribution’s advisories).

Is it patched?

Run uname -r and check your distro’s security bulletins. The patch is merged upstream and should land in all major distros.

Summary

CVE-2024-27397 is a subtle but important bug affecting Linux netfilter’s nftables sets. It could allow elements to expire during rule transactions, causing unpredictable and possibly insecure behavior. The fix is already available and updates should be applied as soon as possible to keep systems safe and stable.

Timeline

Published on: 05/14/2024 15:12:28 UTC
Last modified on: 05/04/2025 09:04:07 UTC