CVE-2024-36972 Overview
CVE-2024-36972 is a race condition vulnerability in the Linux kernel's AF_UNIX socket implementation that can lead to a NULL pointer dereference. The vulnerability exists in the handling of out-of-band (OOB) data in Unix domain sockets, specifically in the interaction between the garbage collection mechanism (__unix_gc()) and the OOB message queuing function (queue_oob()).
The race condition occurs when the garbage collector attempts to clean up closed inflight sockets while a peer socket concurrently sends MSG_OOB messages. This concurrent access to unix_sk(sk)->oob_skb without proper synchronization can result in a kernel panic, causing system instability or denial of service.
Critical Impact
Successful exploitation of this race condition can trigger a kernel NULL pointer dereference, leading to system crashes and denial of service. The vulnerability requires network access and low privileges, making it exploitable from remote contexts in certain configurations.
Affected Products
- Linux Kernel (multiple versions)
- Linux-based operating systems and distributions using vulnerable kernel versions
- Systems utilizing AF_UNIX sockets with OOB message handling
Discovery Timeline
- June 10, 2024 - CVE-2024-36972 published to NVD
- April 1, 2025 - Last updated in NVD database
Technical Details for CVE-2024-36972
Vulnerability Analysis
This vulnerability is classified as CWE-476 (NULL Pointer Dereference) and stems from a race condition in the Linux kernel's Unix domain socket subsystem. The flaw affects the out-of-band (OOB) message handling mechanism where the unix_sk(sk)->oob_skb pointer can be accessed concurrently by two different kernel paths without proper locking.
The __unix_gc() function performs garbage collection on closed inflight sockets. When processing a socket that has MSG_OOB data stored in unix_sk(sk)->oob_skb, the garbage collector drops the reference and sets the pointer to NULL without holding the appropriate lock. Simultaneously, a peer socket can invoke queue_oob() to update the same oob_skb pointer, creating a classic time-of-check-time-of-use (TOCTOU) scenario.
The resulting NULL pointer dereference occurs during socket buffer dequeue operations, as evidenced by the crash trace showing the fault in skb_dequeue() when unix_release_sock() attempts to release the socket. The crash occurs at memory address 0x0000000000000008, indicating an attempt to write to a nearly-NULL pointer offset.
Root Cause
The root cause is the lack of synchronization when accessing unix_sk(sk)->oob_skb across different kernel code paths. The garbage collector (__unix_gc()) modifies this pointer locklessly while queue_oob() can concurrently update the same pointer from a different execution context.
The fix involves updating unix_sk(sk)->oob_skb under the sk_receive_queue lock and ensuring this lock is held consistently wherever oob_skb is accessed. Additionally, kfree_skb() calls in manage_oob() are deferred to prevent lockdep false-positives that could arise from the new locking requirements.
Attack Vector
The vulnerability can be triggered through network access by manipulating Unix domain socket connections with OOB messages while triggering socket garbage collection. An attacker with low privileges on a system could:
- Create multiple Unix domain socket pairs with inflight file descriptors
- Send MSG_OOB messages through the socket connections
- Close sockets in a specific pattern to trigger garbage collection
- Race the garbage collector with additional OOB message sends
- Trigger the NULL pointer dereference causing kernel panic
The attack requires precise timing to win the race condition between __unix_gc() and queue_oob(). The crash trace shows the vulnerability manifests in the kernel workqueue handling delayed file release operations, specifically in the unix_release_sock() path called via delayed_fput.
Detection Methods for CVE-2024-36972
Indicators of Compromise
- Unexpected kernel panics with NULL pointer dereference errors at address 0x0000000000000008
- Kernel crash dumps showing stack traces involving skb_dequeue, unix_release_sock, and delayed_fput
- System instability when applications heavily utilize Unix domain sockets with OOB data
- Workqueue events related to events delayed_fput preceding system crashes
Detection Strategies
- Monitor kernel logs for NULL pointer dereference oops messages containing af_unix or unix_release_sock in the call trace
- Implement kernel crash dump analysis to identify exploitation patterns matching the vulnerability signature
- Deploy runtime kernel integrity monitoring to detect unexpected memory access patterns in socket handling code
- Use SentinelOne's behavioral detection to identify suspicious socket manipulation patterns that may indicate exploitation attempts
Monitoring Recommendations
- Enable kernel crash dump collection (kdump) to capture forensic data from any exploitation attempts
- Monitor system stability metrics and correlate with Unix socket usage patterns
- Implement alerting for repeated kernel oops or panics related to network socket operations
- Review audit logs for applications creating high volumes of Unix domain socket connections with OOB message traffic
How to Mitigate CVE-2024-36972
Immediate Actions Required
- Update the Linux kernel to a patched version that includes the fix for CVE-2024-36972
- Prioritize patching on systems where Unix domain sockets are heavily utilized
- Consider temporarily restricting access to systems that cannot be immediately patched
- Monitor systems for signs of exploitation while patches are being deployed
Patch Information
Multiple kernel patches have been released to address this vulnerability. The fix ensures that unix_sk(sk)->oob_skb is updated under the sk_receive_queue lock and that this lock is consistently held wherever oob_skb is accessed.
The following kernel commits contain the fix:
- Kernel Git Commit 4708f49
- Kernel Git Commit 4bf6964
- Kernel Git Commit 518a994
- Kernel Git Commit 9841991
- Kernel Git Commit d59ae93
Check your Linux distribution's security advisories for specific package versions containing these fixes.
Workarounds
- Limit access to Unix domain socket functionality for untrusted users or applications
- Restrict the use of MSG_OOB on Unix domain sockets where possible through application-level controls
- Implement network segmentation to limit exposure of vulnerable systems
- Deploy SentinelOne Singularity Platform for real-time kernel-level threat detection and response capabilities
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.


