Linux is widely recognized for its robust networking stack, including powerful packet filtering subsystems like Netfilter and nftables. But even the best code can harbor subtle dangers. In 2023, a vulnerability labeled CVE-2023-1095 was discovered in the Kernel’s nftables implementation, specifically in the nf_tables_updtable function. This long-read will walk you through the root cause, exploitation, and impact of this bug using plain language. We'll also look at code samples and point you to original references.
The Vulnerability In Simple Terms
At its heart, CVE-2023-1095 is a logic error that ends up with a NULL pointer dereference in the kernel. This means a process can crash the system by making it access memory that shouldn’t be accessed – potentially triggering a kernel panic or denial-of-service (DoS).
Where’s the Problem?
The buggy flow exists in net/netfilter/nf_tables_api.c, specifically inside the nf_tables_updtable() function. The code handles updates to nftables tables – which control packet filtering rules. If an internal function, nf_tables_table_enable(), returns an error, the kernel tries to clean up using nft_trans_destroy(). But there’s a catch: nft_trans_destroy() tries to delete a transaction from a kernel linked-list that was never populated.
List head is all zeroes → list_del() receives NULL pointers → kernel tries to dereference NULL memory → Crash!
Let’s look how this happens. Here’s a simplified flow excerpted from upstream kernel sources
int nf_tables_updtable(struct nft_ctx *ctx)
{
struct nft_trans *trans;
int err;
trans = nft_trans_alloc();
if (!trans)
return -ENOMEM;
err = nf_tables_table_enable(ctx, …);
if (err < ) {
nft_trans_destroy(trans); // <-- here's the bug
return err;
}
nft_trans_list_add_tail(&ctx->net->trans_list, trans);
...
}
- Inside nft_trans_destroy()
void nft_trans_destroy(struct nft_trans *trans)
{
list_del(&trans->list); // DANGER: 'trans->list' not initialized!
kfree(trans);
}
Because trans->list is still all zeroes, list_del() tries to operate on a NULL pointer. Boom – kernel crash!
Original References
- Debian Security Tracker summary: https://security-tracker.debian.org/tracker/CVE-2023-1095
- Upstream Linux Kernel Fix: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1d00c29aab96
- Red Hat Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2172097
Exploiting The Vulnerability
This is mainly a Denial-of-Service (DoS) bug. You can't get remote code execution, but local processes (with capability to manage nftables) can reliably crash the kernel. On some Linux systems, that means any user in the "netadmin" group.
Ensure you have the CAP_NET_ADMIN capability (as root or suitable group).
2. Trigger a table update with invalid arguments that makes nf_tables_table_enable() fail for a newly crafted transaction.
Proof of Concept (Python using libmnl or direct Netlink, pseudocode)
import socket
import struct
# This demo only simulates the flow, and should not be run on production.
def send_nfupdate_bad(fd):
# Craft a Netlink message to update a table in a way that triggers the error
# (specifics depend on kernel version and configuration)
msg = b'...' # Carefully crafted bytes
fd.send(msg)
# Expect the kernel to crash if vulnerable
if __name__ == "__main__":
with socket.socket(socket.AF_NETLINK, socket.SOCK_RAW, 12) as fd: # 12 = NETLINK_NETFILTER
send_nfupdate_bad(fd)
Note: In real exploits, you’d use tools like libnftnl/libmnl or the nft command-line tool, and adjust arguments to trigger the error path. Building a valid but malicious table update request is the hard part, but with root or sufficient netfilter privileges, it’s very doable.
Mitigation & Fix
Patch it: Apply kernel security updates delivered after February 2023, or directly backport this patch:
- nft_trans_destroy(trans);
+ kfree(trans);
The fixed code simply frees the transaction without deleting it from a list it was never added to.
Restrict access to netfilter: Ensure only trusted users/groups can manipulate nftables.
Final Words
CVE-2023-1095 is a simple but critical reminder: Kernel list management is tricky and assumptions about initialization are dangerous. Always ensure resources are added to management structures _before_ you attempt to clean up or destroy them!
For more technical details, consult the original Linux kernel fix.
Timeline
Published on: 02/28/2023 23:15:00 UTC
Last modified on: 03/06/2023 14:41:00 UTC