*On June 2024, the Linux kernel maintainers disclosed and patched a medium-severity vulnerability affecting nf_tables, impacting kernel releases around v5.x and v6.x lines. Named CVE-2024-42070, this flaw was subtle and technical—but could let attackers leak kernel pointers, opening the door to further attacks like bypassing KASLR (Kernel Address Space Layout Randomization) or even elevating privileges. Let’s break down what happened, how the bug could be exploited, and what code changes fixed it.*

What is nf_tables and Why Does it Matter?

nf_tables is the modern replacement for the classic iptables firewall in Linux. It handles rules related to filtering, NAT, and packet mangling. As such, it's a frequent attack surface for both local and network-based attackers, especially since unprivileged user namespaces could sometimes let local users interact with netfilter.

Data Registers and Verdicts

Inside nf_tables, expressions and actions are handled using "registers". These can be loaded with either plain data (NFT_DATA_VALUE)—things like integers or IP addresses—or with special verdict types (NFT_DATA_VERDICT) that direct packet flow.

The Core Issue

When copying data into nf_tables registers, the code had a conditional check: it validated data types _only_ when the type was explicitly NFT_DATA_VALUE. However, this was insufficient—because every time a value was stored, it was always either a value or a verdict. This meant the check could sometimes be skipped, depending how it was coded.

Why is it dangerous?

Some structures (like chain objects) contain pointers, and if a pointer to a chain is written into a register and later exposed to user space (via dumping or error handling), an attacker could learn the address of the chain object—effectively leaking a kernel pointer.

That might sound small, but kernel pointer leaks are a gold mine for attackers hoping to defeat kernel memory protections.

Threat Model

1. Attacker has access to set up or modify nf_tables (typically CAP_NET_ADMIN, but in some setups, unprivileged user namespaces let normal users access).
2. Attacker sets up a rule, leveraging the insufficient data check, to store a chain pointer into a data register.

Attacker triggers error handling or uses an info-leaking bug to read out the value of the register.

4. Attacker now has a direct kernel address, which can be useful to defeat protections like KASLR or construct further type confusion and use-after-free exploits.

While crafting a minimal PoC is tricky without a deeper kernel understanding, the general idea is

struct nft_expr *expr;
// expr->ops->eval(store_chain_pointer_to_register, ...);
// Later, leak_register_content_to_userspace();

The attacker sets up a rule (using nft command or netlink sockets) that writes a pointer value into a register—one that the validation missed. Then, by reading back error messages or dumping rules, they can get the actual value, and thus, the kernel address.

Before

if (type == NFT_DATA_VALUE) {
    // validate before storing
    ...
}

After (Fixed)

// Always infer register type from set data type
// Always validate, regardless
nft_validate_register_type(data, reg_type);

Explanation:
The fix, merged by Pablo Neira Ayuso, replaces the spot-check with a helper function that always infers register type from the set’s data type, ensuring nothing can slip through. This removes the conditional and always validates, preventing pointer leaks.

Relevant kernel patch (June 5, 2024)

- Kernel Patch
- netfilter mailing list thread

Patch code snippet

static u32 nft_infer_register_type(u32 data_type)
{
    if (data_type == NFT_DATA_VALUE)
        return NFT_REG32_00;
    else /* NFT_DATA_VERDICT */
        return NFT_REG_VERDICT;
}
...
u32 reg_type = nft_infer_register_type(set->data_type);
nft_validate_register_type(data, reg_type);

Conclusion: What Should You Do?

- If you run a vulnerable kernel (check your distribution’s advisories!), patch as soon as an update with this fix is released.
- If you cannot patch: Limit access to user namespaces and CAP_NET_ADMIN as much as possible; restrict who can manipulate firewall/nftables rules.
- For kernel developers: Always assume pointers might leak if you let user data pass through unchecked—small oversights like this can turn data validation bugs into privileged info leaks.

References & Further Reading

- CVE-2024-42070 on cve.org
- Linux Kernel Patch
- netfilter-devel mailing list: Patch discussion
- What is nftables? (wiki)

Timeline

Published on: 07/29/2024 16:15:06 UTC
Last modified on: 08/02/2024 04:54:31 UTC