CVE-2025-38236 Overview
A use-after-free vulnerability exists in the Linux kernel's AF_UNIX socket implementation within the unix_stream_read_generic() function. This vulnerability arises from improper handling of consecutive consumed Out-of-Band (OOB) socket buffers (skbs), which can lead to memory corruption when an attacker manipulates OOB data reception sequences on Unix domain sockets.
Critical Impact
Local attackers can trigger a use-after-free condition that may result in arbitrary code execution, privilege escalation, or system crashes by exploiting the improper handling of OOB socket buffers in Unix domain stream sockets.
Affected Products
- Linux Kernel (multiple versions including 6.16-rc1, 6.16-rc2, 6.16-rc3)
- Debian Linux 11.0
Discovery Timeline
- July 8, 2025 - CVE-2025-38236 published to NVD
- December 18, 2025 - Last updated in NVD database
Technical Details for CVE-2025-38236
Vulnerability Analysis
This use-after-free vulnerability occurs in the AF_UNIX socket subsystem's handling of out-of-band data. The issue manifests when multiple OOB messages are sent and received in a specific sequence, leaving consumed OOB skbs on the receive queue. The vulnerability was reported by Jann Horn and affects the unix_stream_read_generic() function in net/unix/af_unix.c.
The fundamental problem lies in how consumed OOB skbs are managed on the receive queue. When a user reads OOB data, the skb holding the data remains on the receive queue to mark the OOB boundary and break subsequent receive operations. However, when consecutive consumed OOB skbs accumulate, the manage_oob() function and SO_PEEK_OFF code interact in unexpected ways.
The SO_PEEK_OFF code does not expect unix_skb_len(skb) to return 0, which is the case for consumed OOB skbs. This causes the skip logic to incorrectly traverse the skb queue, leading to a scenario where a not-yet-consumed OOB skb is freed while still being referenced.
Root Cause
The root cause is the failure to properly clean up consecutive consumed OOB skbs from the receive queue. When an OOB skb is received via unix_stream_recv_urg(), the code did not check whether the previous skb was a consumed OOB skb that should be freed. This leads to a queue state where the manage_oob() function returns an incorrect skb reference, and subsequent receive operations access freed memory.
Additionally, the ioctl(SIOCATMARK) operation does not function correctly when consecutive consumed OOB skbs are present, indicating a broader design issue in OOB handling.
Attack Vector
The attack requires local access and low privileges. An attacker must be able to create Unix domain stream sockets and manipulate OOB data transmission and reception sequences. The attack involves:
- Creating a pair of connected Unix domain stream sockets
- Sending multiple OOB messages while leaving consumed OOB skbs on the receive queue
- Triggering a non-OOB receive that incorrectly frees the current OOB skb
- Performing an OOB receive that accesses the freed memory
The exploitation sequence demonstrates the vulnerability through a series of send() and recv() operations with and without the MSG_OOB flag, ultimately triggering a KASAN slab-use-after-free detection in unix_stream_read_actor().
Detection Methods for CVE-2025-38236
Indicators of Compromise
- KASAN (Kernel Address SANitizer) reports showing slab-use-after-free in unix_stream_read_actor or related functions
- Kernel crash dumps or oops messages referencing net/unix/af_unix.c around line 3027
- Unexpected system instability when applications use Unix domain sockets with OOB data
- Abnormal memory access patterns in kernel logs related to socket buffer operations
Detection Strategies
- Enable KASAN in development and testing environments to detect use-after-free conditions early
- Monitor kernel logs for stack traces involving unix_stream_read_generic, unix_stream_recvmsg, and sock_recvmsg functions
- Implement system call tracing to identify unusual patterns of recvfrom calls with MSG_OOB flags on Unix sockets
- Deploy endpoint detection solutions capable of monitoring kernel-level memory corruption attempts
Monitoring Recommendations
- Configure kernel crash dump collection to capture detailed information about exploitation attempts
- Enable audit logging for socket-related system calls to track suspicious Unix domain socket usage patterns
- Monitor for processes making unusual sequences of OOB sends and receives on socketpairs
- Implement SentinelOne's Singularity platform for real-time kernel-level threat detection and response
How to Mitigate CVE-2025-38236
Immediate Actions Required
- Update the Linux kernel to a patched version that includes the fix for consecutive consumed OOB skbs
- For Debian Linux 11.0 users, apply security updates as described in the Debian LTS Announcement
- Prioritize patching systems running applications that utilize Unix domain sockets with OOB data features
- Consider restricting access to socket creation capabilities for untrusted users as a temporary measure
Patch Information
The fix modifies the unix_stream_recv_urg() function to check if the previous skb is a consumed OOB skb and frees it before processing the current OOB message. Multiple patches have been committed to the stable kernel branches:
- Kernel Commit 32ca2454
- Kernel Commit 523edfed
- Kernel Commit 61a9ad7b
- Kernel Commit 8db4d2d0
- Kernel Commit a1223786
- Kernel Commit fad0a2c1
For additional technical details, refer to the Chromium Project Issue 423023990.
Workarounds
- Restrict untrusted users from creating Unix domain sockets using namespace isolation or seccomp filters
- Implement application-level controls to avoid OOB data usage on Unix domain sockets where possible
- Deploy container security policies that limit socket operations for sensitive workloads
- Use SELinux or AppArmor policies to restrict access to Unix domain socket operations for non-essential services
# Example: Restrict socket creation using seccomp (application-specific)
# This requires application modification to drop unnecessary capabilities
# Consult kernel documentation for seccomp BPF filter implementation
# Alternatively, use container runtime security profiles to limit socket syscalls
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
