CVE-2024-36971

What it actually does

This is a Linux kernel use-after-free race in network destination-cache handling. The vulnerable path clears and releases socket routing state in the wrong order inside __dst_negative_advice(), violating RCU lifetime rules for sk->sk_dst_cache. Under the right timing, a local user or process able to exercise affected UDP/network socket behavior can cause the kernel to reference freed dst objects. Successful exploitation can lead to kernel memory corruption, privilege escalation to root/kernel context, information disclosure, or a system crash. Because the flaw is in the kernel networking stack, exploitation impact is system-wide even though the CVSS vector is local and requires low privileges.

Why it matters to the business

A compromised low-privileged account, container escape path, malicious local application, or post-exploitation foothold could be upgraded to full control of a Linux host. This can result in data theft, credential harvesting, disabling security controls, lateral movement, service disruption, and complete host takeover. The issue is listed in CISA KEV with active exploitation in the wild and a remediation deadline of 2024-08-28, so unpatched systems should be treated as high-priority legacy exposure even though the EPSS score is relatively low. Ransomware use is not currently indicated by KEV, but kernel privilege escalation vulnerabilities are commonly chained after initial access.

How an attack unfolds

An attacker first obtains the ability to run code as an unprivileged local user or within a constrained workload on an affected Linux kernel. They then repeatedly exercise network socket operations, particularly UDP-related paths that can trigger negative routing advice and destination-cache updates. By racing the vulnerable cache-clearing and dst_release ordering, the attacker attempts to create a condition where the kernel frees a destination object while another path can still access it through sk->sk_dst_cache. A reliable exploit would shape heap allocations and timing so the freed memory is reclaimed with attacker-influenced data, converting the use-after-free into controlled kernel memory corruption. From there, the attacker may corrupt kernel structures or credentials to gain elevated privileges, bypass isolation boundaries, or crash the system if exploitation is unstable. Public reporting associates this class of issue with active in-the-wild exploitation, including Android/Linux kernel exploitation themes, so defenders should assume it may be used as part of exploit chains rather than as a standalone initial-access vulnerability.

How to fix it

Apply a vendor kernel update that includes the upstream fix for the destination-cache RCU ordering bug. For source-based tracking, the stable Linux kernel git fix is commit 051c0bde9f0450a2ec3d62a86d2a0d2fad117f13. Because kernel fixes require the running kernel image to change, patching is not complete until systems have rebooted into the fixed kernel or live-patching coverage has been explicitly confirmed by the vendor. Prioritize internet-facing Linux hosts that also permit local code execution through services, shared bastions, multi-user systems, container hosts, virtualization hosts, Android-derived devices, and systems handling sensitive data. If immediate patching is not possible, reduce exposure by limiting untrusted local shell access, tightening container isolation, disabling unnecessary workloads, applying seccomp/AppArmor/SELinux policies, restricting unprivileged user namespaces where operationally feasible, and monitoring for kernel instability or suspicious privilege-escalation behavior. Mitigations do not fully remove risk because the vulnerable code is in the kernel networking stack.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, is fixed. Use commands such as uname -a, rpm -q kernel, dpkg -l 'linux-image*', or the platform’s kernel inventory tooling to verify the active kernel build includes the vendor backport or upstream commit 051c0bde9f0450a2ec3d62a86d2a0d2fad117f13. On source-managed or custom kernels, check git history for that commit or an equivalent patch changing __dst_negative_advice()/negative_advice handling to clear sk_dst_cache before releasing the old dst reference. Confirm hosts have rebooted after patch installation by comparing the running kernel version to the latest installed kernel and by checking boot time. For container hosts, validate the host kernel because containers share the host kernel. Vulnerability scanners should be configured to assess the running kernel and distribution-specific backport metadata rather than relying only on upstream version strings.

Typical attack path

1. Gain low-privileged local code execution on an affected Linux system, such as through a compromised account, malicious application, vulnerable service, or containerized workload.
2. Probe the kernel version and configuration to determine whether the vulnerable networking code path is present and unpatched.
3. Create and manipulate network sockets, especially UDP/IPv6 or routing-cache-related activity, to reach the vulnerable negative-advice code path.
4. Trigger a race between socket destination-cache clearing and destination object release so the kernel accesses a freed dst object.
5. Use heap grooming and repeated attempts to turn the use-after-free into controlled kernel memory corruption.
6. Modify privileged kernel state, escape confinement, read sensitive memory, or crash the host depending on exploit reliability.
7. Use elevated privileges for persistence, credential theft, defense evasion, lateral movement, or broader compromise.

How to detect it

There is no single network signature that reliably proves exploitation because this is a local kernel memory-corruption vulnerability. Detection should focus on host telemetry and post-exploitation behavior. Review kernel logs from journalctl, dmesg, /var/log/kern.log, /var/log/messages, and crash dumps for use-after-free, RCU, KASAN, BUG, WARNING, general protection fault, NULL pointer, or panic messages involving __dst_negative_advice, dst_release, sk_dst_reset, ip6_negative_advice, UDP sockets, or dst cache handling. Correlate suspicious kernel faults with local user activity, container workload activity, new process executions, and privilege transitions. Review auditd, EDR, process accounting, and shell history for exploit-like behavior: repeated execution from /tmp, /dev/shm, or container writable paths; sudden uid 0 shells; unexpected setuid file creation; abnormal module loading; changes to security controls; or privilege escalation from service accounts. On systems with KASAN, kdump, pstore, or crashkernel enabled, preserve crash artifacts for forensic analysis. Because active exploitation has been reported, absence of crashes does not rule out compromise; successful kernel exploits may leave only post-exploitation traces.

• __dst_negative_advice
• ip6_negative_advice
• sk_dst_reset
• dst_release
• sk_dst_cache
• use-after-free
• KASAN: use-after-free
• BUG: KASAN
• general protection fault
• kernel BUG at
• RCU stall
• dst_release
• negative_advice
• /var/crash/
• /sys/fs/pstore/
• /var/lib/systemd/pstore/
• /proc/vmcore
• /tmp/
• /dev/shm/

What your security team should do

• Immediately inventory Linux and Android-derived systems for vulnerable running kernels, prioritizing multi-user hosts, container hosts, externally exposed servers, and high-value workloads.
• Patch or live-patch affected systems with vendor kernel updates that include the fix, then reboot where required; treat missed reboot windows as unresolved exposure.
• Because this is in CISA KEV and the due date has passed, escalate remaining vulnerable systems through exception/risk governance and track them to closure.
• Hunt for signs of prior exploitation, including kernel crashes, KASAN use-after-free reports, unexplained privilege escalation, suspicious local exploit execution, and abnormal socket-heavy activity by untrusted users.
• Review EDR, auditd, and shell histories for low-privileged users spawning root shells, modifying kernel-related settings, loading suspicious modules, or executing files from temporary directories.
• Harden local attack surfaces by restricting untrusted shell access, reducing unnecessary local accounts, applying mandatory access controls, limiting container privileges, and disabling unneeded capabilities.
• For container platforms, review privileged containers, hostNetwork usage, CAP_SYS_ADMIN/CAP_NET_ADMIN grants, and workloads that can exercise host kernel networking paths.
• Ensure incident response playbooks include kernel exploitation triage: preserve volatile logs, collect kernel messages, capture suspect binaries, and consider full host reimage if kernel compromise is suspected.