CVE-2024-56644 — linux / linux_kernel
In the Linux kernel, the following vulnerability has been resolved:
net/ipv6: release expired exception dst cached in socket
Dst objects get leaked in ip6_negative_advice() when this function is executed for an expired IPv6 route located in the exception table. There are several conditions that must be fulfilled for the leak to occur:
- an ICMPv6 packet indicating a change of the MTU for the path is received, resulting in an exception dst being created
- a TCP connection that uses the exception dst for routing packets must start timing out so that TCP begins retransmissions
- after the exception dst expires, the FIB6 garbage collector must not run before TCP executes ip6_negative_advice() for the expired exception dst
When TCP executes ip6_negative_advice() for an exception dst that has expired and if no other socket holds a reference to the exception dst, the refcount of the exception dst is 2, which corresponds to the increment made by dst_init() and the increment made by the TCP socket for which the connection is timing out. The refcount made by the socket is never released. The refcount of the dst is decremented in sk_dst_reset() but that decrement is counteracted by a dst_hold() intentionally placed just before the sk_dst_reset() in ip6_negative_advice(). After ip6_negative_advice() has finished, there is no other object tied to the dst. The socket lost its reference stored in sk_dst_cache and the dst is no longer in the exception table. The exception dst becomes a leaked object.
As a result of this dst leak, an unbalanced refcount is reported for the loopback device of a net namespace being destroyed under kernels that do not contain e5f80fcf869a ("ipv6: give an IPv6 dev to blackhole_netdev"): unregister_netdevice: waiting for lo to become free. Usage count = 2
Fix the dst leak by removing the dst_hold() in ip6_negative_advice(). The patch that introduced the dst_hold() in ip6_negative_advice() was 92f1655aa2b22 ("net: fix __dst_negative_advice() race"). But 92f1655aa2b22 merely refactored the code with regards to the dst refcount so the issue was present even before 92f1655aa2b22. The bug was introduced in 54c1a859efd9f ("ipv6: Don't drop cache route entry unless timer actually expired.") where the expired cached route is deleted and the sk_dst_cache member of the socket is set to NULL by calling dst_negative_advice() but the refcount belonging to the socket is left unbalanced.
The IPv4 version - ipv4_negative_advice() - is not affected by this bug. When the TCP connection times out ipv4_negative_advice() merely resets the sk_dst_cache of the socket while decrementing the refcount of the exception dst.
| Software | From | Fixed in |
|---|---|---|
| linux / linux_kernel | 5.5 | 5.10.231 |
| linux / linux_kernel | 5.11 | 5.15.174 |
| linux / linux_kernel | 5.16 | 6.1.120 |
| linux / linux_kernel | 6.2 | 6.6.66 |
| linux / linux_kernel | 6.7 | 6.12.5 |
| linux / linux_kernel | 2.6.34 | 2.6.34.x |
| linux / linux_kernel | 2.6.34-rc3 | 2.6.34-rc3.x |
| linux / linux_kernel | 2.6.34-rc4 | 2.6.34-rc4.x |
| linux / linux_kernel | 2.6.34-rc5 | 2.6.34-rc5.x |
| linux / linux_kernel | 2.6.34-rc6 | 2.6.34-rc6.x |
| linux / linux_kernel | 2.6.34-rc7 | 2.6.34-rc7.x |
| linux / linux_kernel | 6.13-rc1 | 6.13-rc1.x |
| linux / linux_kernel | 2.6.33.2 | 2.6.34 |
| linux / linux_kernel | 2.6.34.1 | 5.4.287 |
| debian / debian_linux | 11.0 | 11.0.x |
- https://git.kernel.org/stable/c/0b8903e6c881f72c6849d4952de742c656eb5ab9
- https://git.kernel.org/stable/c/3301ab7d5aeb0fe270f73a3d4810c9d1b6a9f045
- https://git.kernel.org/stable/c/535add1e9f274502209cb997801208bbe1ae6c6f
- https://git.kernel.org/stable/c/8b591bd522b71c42a82898290e35d32b482047e4
- https://git.kernel.org/stable/c/a95808252e8acc0123bacd2dff8b9af10bc145b7
- https://git.kernel.org/stable/c/b90d061345bb8cd51fece561a800bae1c95448a6
- https://git.kernel.org/stable/c/f43d12fd0fa8ee5b9caf8a3927e10d06431764d2
- https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html
- https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html
Deep Security Visibility Without the Complexity
SynScan provides clear, real-time security insights so you can monitor your attack surface, spot risks early, and act fast—without extra complexity.
- No setup fees
- 5-min deployment
- Cancel anytime
Frequently Asked Questions
A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.
CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.
A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.
Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.
Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.
SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.