The Linux kernel is known for its speed and efficiency, but sometimes, things go wrong in subtle ways. In this article, we’ll break down CVE-2023-52433—a vulnerability in the netfilter subsystem—and show why it existed, how it can be abused, and most importantly, how it was fixed. We'll keep things focused and simple, but technically useful.
What is CVE-2023-52433?
CVE-2023-52433 is a race condition bug found in the Linux kernel’s Netfilter subsystems, specifically affecting how nftables manages sets stored as red-black trees (nft_set_rbtree). The core of the problem is that new elements added in a batch (transaction) may expire before the transaction ends. Unfortunately, garbage collection (GC) would sometimes free up memory for those expired elements before other parts of the code were done using them. This could cause a "use-after-free", potentially allowing a local attacker to crash the kernel or execute arbitrary code.
When new elements are added to an nftables set in a transaction, there is a small window of time
- Before the transaction commits, someone else might expire (time-out) one of those elements (perhaps even instantly).
The synchronous garbage collector (GC) could then remove those elements, freeing up their memory.
- When the transaction commits, code might try to reference those newly-expired-but-now-freed elements, causing a crash or unexpected behavior.
The Technical Root Cause
The bug sits in this segment of code around the function responsible for syncing the garbage collection:
/* from net/netfilter/nft_set_rbtree.c, simplified */
static void nft_rbtree_gc_sync(struct nft_set *set)
{
struct nft_set_elem *elem, *tmp;
list_for_each_entry_safe(elem, tmp, &set->list, list) {
if (nft_set_elem_expired(elem)) {
list_del(&elem->list);
kfree(elem);
}
}
}
The problem: If an element was added "right now" (in this transaction), it could be expired and freed by this function before the transaction finishes!
Rapid-fire element creation: A local user creates and adds an element to an nftables set.
2. Set short timeout: The element is crafted to expire very quickly (e.g., with a timeout value of 1 second or even less).
3. Trigger GC: The code path that performs a sync GC is triggered (normally during batch operations).
4. Boom: If timing works out, the just-added element will be expired and freed by sync GC, but later code may still touch its memory—use-after-free has occurred.
An attacker could exploit this to crash the kernel (denial of service). In theory, with careful heap manipulation, it could lead to privilege escalation (code execution), though no working public exploit code is known.
The Patch: How Was It Fixed?
The kernel fix ensures that newly added elements in the current transaction are skipped by sync GC and only collected asynchronously after the transaction is safely finished.
Fixed code snippet (simplified)
/* Only deal with elements that existed before this transaction */
list_for_each_entry_safe(elem, tmp, &set->list, list) {
if (!nft_set_elem_is_new(elem) && nft_set_elem_expired(elem)) {
list_del(&elem->list);
kfree(elem);
}
}
By checking if an element is "new" in this transaction and skipping it, the use-after-free situation is prevented.
Test if you have the patch:
- Look for commit 02a742b91c6f9bd88b71b1cd13a308da63faeba
Here’s a simple demonstration pseudocode (no real exploit, but how the bug can be triggered)
# Requires nft command from nftables
nft add table t
nft add set t dangerous { type ipv4_addr; timeout 1s; }
# Add element to the set
nft add element t dangerous { 1.2.3.4 }
# Rapid batch operations to hit timing
for i in $(seq 1 100); do
nft add element t dangerous { 1.2.3.4 }
sleep .001 # try to expire instantly
# Now, 'nft flush set t dangerous' may trigger GC on just-expired element
done
This race window is tight, but achievable with a determined attacker.
References
- CVE Page on NVD
- Upstream Linux fix commit
- netfilter-devel ML post
Conclusion
CVE-2023-52433 is a subtle race bug but could have severe consequences in unpatched Linux systems using nftables with sets and expirations. If you operate systems exposed to untrusted users, make sure your kernel is updated!
Timeline
Published on: 02/20/2024 13:15:08 UTC
Last modified on: 11/06/2024 22:35:02 UTC