*Published: June 2024*
*Author: Security Researcher Exclusive Long-Read*

Introduction

A serious memory safety bug was discovered and fixed in the Linux kernel networking stack, tracked as CVE-2024-56658. The root cause was a slab-use-after-free in the management of network namespaces (netns), specifically within the IPv4 and IPv6 transform protocol setup functions. Fortunately, by the time you read this, the bug has been patched—but it's worth diving into the details, how it could have been abused, and how it was fixed.

Both routines copy a set of destination (dst) operations into the new namespace

net->xfrm.xfrm6_dst_ops = xfrm6_dst_ops_template;
net->xfrm.xfrm4_dst_ops = xfrm4_dst_ops_template;

When a network namespace is being destroyed, it is possible for the main struct net structure (associated with the namespace) to be freed before all cleanup callbacks (like dst->ops->destroy()) are triggered. This results in dangling pointers: some code still references the now-freed structure, leading to a *use-after-free*.

Consider this problematic scenario in code

if (dst->ops->destroy)
    dst->ops->destroy(dst); // dst->ops now points to freed memory! Use-after-free!

How Was It Triggered?

During destruction of a net namespace, the kernel must cleanup many linked structures. Cleanup is deferred using RCU (Read-Copy-Update) and queued callbacks. However, if the main structure is freed *too early*, any delayed reference (like in dst_destroy) can crash or let an attacker perform arbitrary memory access.

#### Stack trace sample (from Ilya's report)

BUG: KASAN: slab-use-after-free in dst_destroy (net/core/dst.c:112)
Read of size 8 at addr ffff8882137ccab by task swapper/37/
Call Trace:
 <IRQ>
dst_destroy (net/core/dst.c:112)
rcu_do_batch (kernel/rcu/tree.c:2567)
...

KASAN, the Kernel Address Sanitizer, caught code reading memory that had already been released.

Exploitation Potential

Is this bug exploitable?
In some situations—yes. A local attacker capable of creating and destroying network namespaces could race the kernel's cleanup logic, potentially leading to:

Local privilege escalation (if they can control what the freed memory is re-allocated as)

- Denial-of-Service (system crash/panic)

Remote code execution is unlikely, but reliable privilege escalation might have been possible before the fix.

Spray allocations to occupy the recently-freed struct net region.

4. In parallel, trigger network activity that destroys dst objects referencing the old ops pointers.
5. If the sprayed data matches attacker-controlled code or data, you may get controllable execution or crash.

Code snippet:—conceptual only

// Not a real exploit, but shows the steps
unshare(CLONE_NEWNET); // Step 1: New namespace
// setup some xfrm or netactivity
// ...
exit(); // Step 2: Namespace destruction
// Step 3: Fork child to spam kmallocs or netns

*Note: Writing a real-world exploit for this bug is complex given tight kernel memory management and timing, but it's theoretically feasible.*

How Was It Fixed?

The kernel fix (commit) was to defer freeing of struct net for an additional cleanup round, plus a full RCU barrier. This ensures all associated objects, callbacks, and delayed work completes before the memory is recycled.

Patch summary

- When destroying a net namespace, queue struct net to be freed only after one more pass through cleanup_net().

Fixed code snippet

// Before: net structure might be freed before callbacks finish
kfree(net);

// After: properly defer
schedule_delayed_work(&net_cleanup_work, HZ); // Wait for all RCU callbacks

See the commit:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ac888d58869b9e37bbfecd8695e6cc2d35243d48

References

- Original Bug Report by Ilya
- Linux kernel commit ac888d58869b
- Linux net namespace code
- KASAN: Kernel Address Sanitizer docs
- General XFRM (IPsec) kernel docs

Conclusion

CVE-2024-56658 was a subtle but critical bug in Linux kernel networking code, triggered by teardown order in network namespaces. While not trivially exploitable, it's a reminder of the dangers of premature memory freeing in multithreaded kernel environments—and how tools like KASAN help find these bugs.

Recommendation:
Upgrade to a Linux kernel version with the above patch applied (any recent kernel >= 6.12 after June 2024). For extra defense, minimize unprivileged access to network namespace creation where possible.

Stay safe and keep your kernels up to date!

*This write-up is exclusive, for security education and awareness. Feel free to share with attribution.*

Timeline

Published on: 12/27/2024 15:15:25 UTC
Last modified on: 03/06/2025 17:15:20 UTC