CVE-2024-44987 Overview
CVE-2024-44987 is a Use-After-Free (UAF) vulnerability discovered in the Linux kernel's IPv6 networking stack, specifically within the ip6_send_skb() function. The vulnerability was reported by syzbot, an automated kernel fuzzing tool, and occurs due to improper handling of route table (rt) references after ip6_local_out() returns. When the route destination structure is freed by another task while still being dereferenced, it leads to a use-after-free condition that can potentially be exploited for local privilege escalation or denial of service.
Critical Impact
A local attacker with low privileges can exploit this memory corruption vulnerability to potentially gain elevated privileges, execute arbitrary code in kernel context, or cause system instability through denial of service attacks targeting the IPv6 networking subsystem.
Affected Products
- Linux Kernel versions prior to 5.4.283
- Linux Kernel versions 5.5.x to 5.10.225
- Linux Kernel versions 5.11.x to 5.15.166
- Linux Kernel versions 5.16.x to 6.1.108
- Linux Kernel versions 6.2.x to 6.6.49
- Linux Kernel versions 6.7.x to 6.10.8
- Linux Kernel 6.11 release candidates (rc1 through rc4)
Discovery Timeline
- 2024-09-04 - CVE-2024-44987 published to NVD
- 2025-11-03 - Last updated in NVD database
Technical Details for CVE-2024-44987
Vulnerability Analysis
This vulnerability exists in the IPv6 packet transmission path within the Linux kernel. The issue manifests in ip6_send_skb() located in net/ipv6/ip6_output.c. After calling ip6_local_out(), the code continues to dereference the route table pointer (rt) without holding proper RCU (Read-Copy-Update) locks. This creates a race condition where another kernel task can free the destination structure via dst_destroy() while the original task still holds a stale reference.
The KASAN (Kernel Address SANitizer) report indicates a slab-use-after-free read of 8 bytes at a memory location that was previously allocated for a blackhole route via ip6_blackhole_route() in the xfrm (IPsec) policy handling path. The memory was subsequently freed through RCU callback processing in rcu_do_batch(), but the original sending path continued to access the now-freed memory.
This is a similar class of vulnerability to the one fixed in commit a688caa34beb which addressed an identical issue in rawv6_send_hdrinc(). The pattern of failing to hold proper RCU locks when accessing route structures after asynchronous operations is a recurring source of memory safety issues in the kernel networking stack.
Root Cause
The root cause is improper synchronization when accessing shared kernel data structures. Specifically, after ip6_local_out() completes, the route table (rt) reference may become invalid if another CPU or kernel thread executes the RCU callback that frees the destination structure. The fix requires holding rcu_read_lock() around the code section that dereferences the route pointer after ip6_local_out() returns, ensuring the RCU grace period prevents premature deallocation.
Attack Vector
The vulnerability requires local access to the system and the ability to send IPv6 packets through raw sockets. An attacker would need to:
- Create conditions that trigger the IPsec/xfrm blackhole route path
- Race the packet transmission with route structure deallocation
- Exploit the use-after-free condition when the freed memory is accessed
The attack leverages the rawv6_sendmsg() and rawv6_push_pending_frames() code paths, which can be triggered by a local user with network socket capabilities. While the exploitation complexity is non-trivial due to the race condition timing requirements, successful exploitation could lead to kernel memory corruption, information disclosure, or privilege escalation.
Detection Methods for CVE-2024-44987
Indicators of Compromise
- KASAN reports showing "slab-use-after-free" in ip6_send_skb() or related IPv6 output functions in kernel logs
- Unexpected kernel crashes or panics in the IPv6 networking stack, particularly involving rawv6_sendmsg() or rawv6_push_pending_frames()
- Suspicious raw IPv6 socket activity from unprivileged processes attempting to trigger race conditions
Detection Strategies
- Enable KASAN (Kernel Address Sanitizer) in development and testing environments to detect use-after-free conditions
- Monitor kernel logs for KASAN reports, NULL pointer dereferences, or general protection faults in the net/ipv6/ code paths
- Deploy kernel runtime monitoring solutions that can detect anomalous memory access patterns in networking subsystems
- Use SentinelOne's kernel-level protection to identify and block exploitation attempts targeting memory corruption vulnerabilities
Monitoring Recommendations
- Configure syslog aggregation to capture and alert on KASAN and kernel oops messages
- Implement real-time kernel log monitoring for patterns matching "use-after-free" combined with "ip6_send_skb" or "rawv6"
- Monitor for unusual IPv6 raw socket usage patterns that could indicate exploitation attempts
How to Mitigate CVE-2024-44987
Immediate Actions Required
- Update affected Linux kernel installations to patched versions immediately
- For systems that cannot be immediately patched, consider restricting access to raw IPv6 sockets via SELinux, AppArmor, or similar mandatory access control mechanisms
- Monitor systems for signs of exploitation attempts and enable enhanced kernel logging
- Review and limit user capabilities related to network socket creation (CAP_NET_RAW)
Patch Information
The Linux kernel maintainers have released patches addressing this vulnerability across multiple stable kernel branches. The fix adds proper rcu_read_lock() protection around the route table dereference in ip6_send_skb(). Patches are available through the following kernel git commits:
- Kernel Git Commit 24e93695b123
- Kernel Git Commit 571567e02770
- Kernel Git Commit 9a3e55afa95e
- Kernel Git Commit af1dde074ee2
- Kernel Git Commit cb5880a0de12
- Kernel Git Commit ce2f6cfab2c6
- Kernel Git Commit e44bd76dd072
- Kernel Git Commit faa389b2fbaa
Distribution-specific patches are also available through Debian LTS Security Announcements.
Workarounds
- Restrict CAP_NET_RAW capability to trusted users only using capabilities management or container isolation
- Use network namespaces to isolate untrusted processes from direct raw socket access
- Implement additional access controls via SELinux or AppArmor policies limiting raw socket operations
- Consider disabling IPv6 on systems where it is not required as a temporary measure
# Restrict raw socket capability for non-root users
# Add to /etc/security/limits.conf or capabilities configuration
# Example: Remove CAP_NET_RAW from unprivileged users
# Verify current kernel version
uname -r
# Check if system is vulnerable (versions prior to patched releases)
# Update kernel through package manager
# Debian/Ubuntu:
apt update && apt upgrade linux-image-$(uname -r)
# RHEL/CentOS:
yum update kernel
# After update, reboot to apply new kernel
reboot
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

