CVE-2024-36971·Kernel vulnerability
In the Linux kernel, the following vulnerability has been resolved: net: fix __dst_negative_advice() race __dst_negative_advice() does not enforce proper RCU rules when sk->dst_cache must be cleared, leading to possible UAF. RCU rules are that we must first clear sk->sk_dst_cache, then call dst_release(old_dst). Note that sk_dst_reset(sk) is implementing this protocol correctly, while __dst_negative_advice() uses the wrong order. Given that ip6_negative_advice() has special logic against RTF_CACHE, this means each of the three ->negative_advice() existing methods must perform the sk_dst_reset() themselves. Note the check against NULL dst is centralized in __dst_negative_advice(), there is no need to duplicate it in various callbacks. Many thanks to Clement Lecigne for tracking this issue. This old bug became visible after the blamed commit, using UDP sockets.
- Severity
- high
- Software
- Kernel
- Fixed in
- 6.9.4
- Published
- 2024-06-10
Affected versions
From: 6.7
Until: 6.9.4
Fixed in: 6.9.4
How to fix this CVE
Update the Linux kernel to version 6.9.4 or later. For LTS kernels, apply the backported patch from your distribution. If immediate kernel update is not possible, limit local user access and monitor for suspicious network-related syscalls. A reboot is required after kernel update.
sudo apt update && sudo apt install --only-upgrade linux-image-generic
# Verify: uname -r (should show patched version)
sudo reboot
# For specific kernel: apt list --installed 2>/dev/null | grep linux-imageDefensia detects this vulnerability
What an exploitation attempt looks like
Sample log line indicative of exploitation attempts:
This is a local privilege escalation via kernel memory corruption. The attack exploits a race condition in __dst_negative_advice() where sk->sk_dst_cache is released before being cleared, allowing a use-after-free. Exploitation requires local access and typically involves creating UDP sockets with specific routing configurations to trigger the race window.WAF mitigation (if patching is not yet possible)
Add this rule to your WAF to block exploitation attempts while you schedule the patch.
WAF rules cannot mitigate kernel vulnerabilities as they operate at the application layer. Mitigation strategies include: restrict local user access, use kernel hardening (KASLR, SMEP, SMAP), deploy seccomp profiles to limit syscalls, and ensure rapid kernel patching cycles.How to check if you are affected
- Check kernel version: uname -r — vulnerable if 6.7.x through 6.9.3
- Check distribution patch level: apt list --installed 2>/dev/null | grep linux-image || rpm -q kernel
- Monitor for exploitation: dmesg | grep -i 'use.after.free\|kasan\|slab.out.of.bounds'
- Check for suspicious UDP socket activity: ss -unap | grep -v ESTABLISHED
- Audit local users with shell access: awk -F: '$7 ~ /bash|sh/' /etc/passwd
Indicators of compromise
- Kernel KASAN reports mentioning __dst_negative_advice or dst_release
- Unexpected kernel oops/panics related to network routing
- Suspicious processes running with elevated privileges after exploiting local access
- High volume of UDP socket creation/destruction patterns
FAQ
Can this be exploited remotely?
No. CVE-2024-36971 requires local access to the system. The attacker needs to be able to create and manipulate UDP sockets, which requires local user privileges. However, an attacker who has gained initial access through another vulnerability (e.g., a web shell) could use this for privilege escalation.
Does this affect all Linux distributions?
It affects distributions running kernel versions 6.7 through 6.9.3. Many enterprise distributions (RHEL, Ubuntu LTS) may run older LTS kernels that are not affected by this specific commit range, but check your distribution's security advisories for backported patches.
Is a reboot required after patching?
Yes. Kernel updates require a reboot to take effect. Consider using kexec for faster reboots on production servers, or schedule a maintenance window. Live patching services (Canonical Livepatch, RHEL kpatch) may provide a patch without reboot.
Who discovered this vulnerability?
Clement Lecigne of Google's Threat Analysis Group (TAG) reported this vulnerability, which typically indicates it was discovered being exploited in targeted attacks. Google TAG primarily tracks state-sponsored threat actors.
How does this relate to the network stack?
The vulnerability is in the destination cache negative advice handling. When a route becomes invalid, __dst_negative_advice() should safely clear and release the cached destination. The bug is an incorrect ordering of operations — releasing before clearing — that creates a use-after-free race condition exploitable via UDP sockets.
Related Kernel CVEs
References
- https://git.kernel.org/stable/c/051c0bde9f0450a2ec3d62a86d2a0d2fad117f13
- https://git.kernel.org/stable/c/2295a7ef5c8c49241bff769e7826ef2582e532a6
- https://git.kernel.org/stable/c/5af198c387128a9d2ddd620b0f0803564a4d4508
- https://git.kernel.org/stable/c/81dd3c82a456b0015461754be7cb2693991421b4
- https://git.kernel.org/stable/c/92f1655aa2b2294d0b49925f3b875a634bd3b59e
Track CVEs across your fleet automatically
Defensia scans your Linux servers and tells you exactly which ones are running vulnerable versions — including CVE-2024-36971. Free for 1 server.
Get started free