A critical vulnerability was discovered and patched in the Linux kernel’s Netfilter subsystem, specifically involving iptables and its NAT table initialization. Tracked as CVE-2024-42270, this bug could crash your system at boot if triggered — especially on systems where iptables-restore runs as part of early startup scripts.
Let's break down what happened, why it’s serious, how it looked in the wild, and review the patch that fixed it.
The Problem: A Race Condition With Serious Impact
In Linux, the iptables component is responsible for managing firewall rules. It’s often used to NAT (network address translation) connections, especially on servers and cloud virtual machines.
During initialization, the kernel sets up network namespaces (netns) and registers various subsystem structures. However, a hole was discovered: The NAT table for iptables (iptable_nat_table_init()) could be called *by userspace* before the kernel finished initializing all network namespaces.
If this happened, a critical kernel pointer was accessed before being set up, resulting in a null-pointer dereference — a fatal error that crashes the kernel.
A system running on AWS EC2 experienced this at boot. Take a look at part of the panic log
BUG: kernel NULL pointer dereference, address: 0000000000000013
PF: supervisor write access in kernel mode
...
RIP: 001:iptable_nat_table_init (net/ipv4/netfilter/iptable_nat.c:87 net/ipv4/netfilter/iptable_nat.c:121) iptable_nat
Code: 10 4c 89 f6 48 89 ef e8 ...
...
Call Trace:
...
? iptable_nat_table_init (net/ipv4/netfilter/iptable_nat.c:87 net/ipv4/netfilter/iptable_nat.c:121) iptable_nat
This shows that the call to iptable_nat_table_init accessed memory that wasn’t available (*NULL pointer dereference*), taking down the server.
The Cause: A Missed Initialization Order
Looking at the source, the root of the bug was that iptable_nat_table_init() could be exposed — through a user-triggered event — before the kernel had completed crucial setup.
Relevant Pseudocode (pre-fix)
int iptable_nat_init(void)
{
xt_register_template(&iptable_nat);
register_pernet_subsys(&iptable_nat_net_ops); // <-- should be FIRST!
}
This means user actions (like running iptables-restore) could hit the vulnerable section before the kernel was ready.
Patched Code
int iptable_nat_init(void)
{
register_pernet_subsys(&iptable_nat_net_ops); // <-- now called FIRST
xt_register_template(&iptable_nat);
}
Now, the necessary netns internal structures are up before the NAT table is exposed to userspace functions.
Original Commit:
- netfilter: iptables: Fix null-ptr-deref in iptable_nat_table_init()
- LKML report
Exploit Details: How Can It Be Triggered?
While there’s no known full weaponization (like remote code execution), a malicious local user could reliably crash the kernel.
Boot Linux kernel with vulnerable version (e.g., 6.1.92 and earlier).
2. Race a call to iptables-restore or directly invoke NAT table init code before full boot completes.
Kernel dereferences NULL pointer, triggers panic, crashes system.
This is easiest on servers where automated scripts run firewalls at boot, or on multi-user systems where a race could be triggered intentionally.
Test Snippet (could cause crash on vulnerable systems!)
# DANGEROUS: Only run in controlled environments!
while :; do iptables-restore < /dev/null; done
Is It Already Patched?
Yes. If you’re using a Linux kernel after May 2024, you’re almost certainly patched.
Fixed in
- Linux 6.9
- Backported to 6.1.93+ (LTS kernel versions)
Mitigation
- Update your kernel: If you use Netfilter and NAT, ensure your kernel includes the patch referenced above.
Official patch:
netfilter: iptables: Fix null-ptr-deref in iptable_nat_table_init() (kernel.org commit)
Linux Kernel Mailing List discussion:
CVE entry:
Summary
CVE-2024-42270 was a classic Linux "minor timing bug" that could have major consequences — crashing a server at boot or on demand via a local exploit. While there’s no evidence of this being used in the wild for attacks, there’s nothing stopping an unprivileged local user from taking down a vulnerable system, making it a critical stability risk for unpatched kernels.
Timeline
Published on: 08/17/2024 09:15:08 UTC
Last modified on: 08/19/2024 20:01:09 UTC