CVE-2024-56644 uncovers a subtle but impactful resource leak in the Linux kernel's IPv6 networking stack: under specific network circumstances, IPv6 destination (dst) objects can be leaked, leading to reference count imbalances associated with the loopback network device. This post unpacks the mechanics of the vulnerability, illustrates the root cause with code snippets, links to upstream commits, and discusses both risk and remedial action—all explained in simple and accessible language.
What Is CVE-2024-56644?
This vulnerability revolves around the way the Linux kernel manages cached route exceptions (dst entries) for IPv6 traffic, specifically in the context of TCP connections following certain ICMPv6 path change notifications (like a change in Path MTU). When these cached exceptions expire and are not cleaned up properly, a destination object can leak, holding a lingering reference to the network device that will never be freed.
Why Does it Matter?
- Resource Leaks: Leaked references prevent certain kernel objects, like the loopback device, from being released when a network namespace is destroyed.
- DoS Vector: Over time, unremovable network resources could exhaust system capacity or block cleanup.
- No Direct Remote Exploit: This bug, while non-trivial to trigger intentionally, demonstrates how complex kernel logic can lead to subtle yet important resource management failures.
In plain language, here's what needs to happen
1. ICMPv6 Path Change: The system receives an ICMPv6 message (like "Packet Too Big"), so the kernel creates a new "exception dst" entry—a special cached route for the new path.
2. TCP Retransmission: A TCP connection using that exception dst route starts to time out, causing retransmissions (usually after a network hiccup).
3. Route Expires, Not Collected Yet: The cached exception dst expires, but the kernel's garbage collector hasn't cleaned it up yet.
4. Negative Advice Processing: TCP then processes ip6_negative_advice() for the expired dst, altering reference counts incorrectly.
5. Leak Occurs: The reference count is left unbalanced; the dst and its attached resources are never fully freed.
On affected kernels (usually with custom network namespaces), you may see log messages like
unregister_netdevice: waiting for lo to become free. Usage count = 2
This message means the loopback device can’t be deleted because something (the leaked dst object) still references it.
The Technical Gut: Where’s the Bug?
Key File: net/ipv6/route.c
It boils down to this function: ip6_negative_advice().
A dst_hold() was incorrectly added before resetting the socket's dst cache, which together with other increments/decrements, causes the reference count to never hit zero.
Here’s a simplified pseudocode version focusing on the problem
void ip6_negative_advice(struct sock *sk) {
struct dst_entry *dst = sk_dst_get(sk); // Get the cached dst
if (dst && dst_is_expired(dst)) {
dst_hold(dst); // <- Problematic: increments refcount
sk_dst_reset(sk); // calls dst_release(), tries to decrement
// Now, refcount is still high!
}
}
The Patch: Fixing the Leak
The fix is as simple as removing the unnecessary dst_hold(dst); line so the refcount finally zeroes when expected.
- dst_hold(dst); // Remove this line!
+ // No extra hold: let refcount balance correctly!
sk_dst_reset(sk);
Patch Link:
- Actual fix: commit e5f80fcf869ab6b42c47e28ee6f41becc5996c8e
- Vulnerability introduced: commit 54c1a859efd9fb15d3
How Could It Be Abused?
- Attackers could exploit this if they can cause a victim host to process repeated ICMPv6 "Packet Too Big" messages for TCP connections and force the kernel into the right timing window, possibly exhausting kernel resources after repeated leaks.
- Denial-of-Service is the theoretical outcome—rendering network resources or namespaces unable to be cleaned up.
Inject ICMPv6 "Packet Too Big" messages to cause the kernel to install path exceptions.
3. Cause the connection to time out without FIB6 garbage collection running by manipulating connection state/timing.
Destroy the network namespace: witness leak via kernel log message or resource exhaustion.
> Note: Actual exploitation in real-world conditions is complex and timing-dependent, making accidental impact more likely than deliberate attack.
Upstream commit fixing the bug:
Bug origin:
Original discussion:
CVE entry:
Risk Mitigation and Recommendations
- Patch Promptly: If you manage IPv6-enabled, multi-namespace cloud servers or containers, update to a kernel version containing the fix.
Monitor Logs: Keep an eye out for "waiting for lo to become free" type messages.
- Network Hygiene: Avoid unnecessary ICMPv6 messages within your network. Use firewall rules as needed.
- Container Platforms: Test deletion and recreation of network namespaces following high-volume IPv6 traffic.
Conclusion
CVE-2024-56644 is a classic example of how complex reference counting and edge-case logic can lead to hard-to-spot resource leaks in the Linux kernel. While not likely to be the initial vector for cyber intrusion, it can impact server resilience, especially in environments with heavy IPv6 and containerized workloads. Kernel maintainers have acted quickly— all users are encouraged to update soon.
*Stay safe, patch early, and keep watching those kernel logs!*
Timeline
Published on: 12/27/2024 15:15:24 UTC
Last modified on: 05/04/2025 13:00:57 UTC