Full Report
Introduction In early June, I was reviewing a new Linux kernel feature when I learned about the MSG_OOB feature supported by stream-oriented UNIX domain sockets. I reviewed the implementation of MSG_OOB, and discovered a security bug (CVE-2025-38236) affecting Linux >=6.9. I reported the bug to Linux, and it got fixed. Interestingly, while the MSG_OOB feature is not used by Chrome, it was exposed in the Chrome renderer sandbox. (Since then, sending MSG_OOB messages has been blocked in Chrome renderers in response to this issue.) The bug is pretty easy to trigger; the following sequence results in UAF: char dummy; int socks[2]; socketpair(AF_UNIX, SOCK_STREAM, 0, socks); send(socks[1], "A", 1, MSG_OOB); recv(socks[0], &dummy, 1, MSG_OOB); send(socks[1], "A", 1, MSG_OOB); recv(socks[0], &dummy, 1, MSG_OOB); send(socks[1], "A", 1, MSG_OOB); recv(socks[0], &dummy, 1, 0); recv(socks[0], &dummy, 1, MSG_OOB); I was curious to explore how hard it is to actually exploit such a bug from inside the Chrome Linux Desktop renderer sandbox on an x86-64 Debian Trixie system, escalating privileges directly from native code execution in the renderer to the kernel. Even if the bug is reachable, how hard is it to find useful primitives for heap object reallocation, delay injection, and so on? The exploit code is posted on our bugtracker; you may want to reference it while following along with this post.
Analysis Summary
# Vulnerability: Use-After-Free (UAF) in Linux Kernel MSG\_OOB Handling for UNIX Domain Sockets
## CVE Details
- CVE ID: CVE-2025-38236
- CVSS Score: Not explicitly stated in the text, but the context implies High severity due to achievable kernel privilege escalation. (Likely High/Critical)
- CWE: CWE-416: Use After Free (UAF)
## Affected Systems
- Products: Linux Kernel
- Versions: Linux kernel versions $\ge 6.9$ (prior to patch application).
- Configurations: Systems where stream-oriented UNIX domain sockets support `MSG_OOB` is enabled (which is default when `AF_UNIX` is enabled). Specifically relevant in environments like Chrome Linux Desktop renderers that utilize these sockets but were not filtering `send`/`recv` flags.
## Vulnerability Description
The vulnerability is a Use-After-Free (UAF) bug stemming from the implementation of the `MSG_OOB` feature for `AF_UNIX` stream sockets.
When an `MSG_OOB` message (a single byte) is sent, the corresponding socket buffer (`struct sk_buff` or SKB) is placed on the receiver's `sk_receive_queue`, and the receiver's `oob_skb` pointer is updated to point to this specific SKB. The issue arises during the sequence of sending and receiving OOB data, particularly when mismatched flags are used in receive operations, leading to incorrect pointer management. The provided exploitation sequence directly leads to a UAF condition:
c
send(socks[1], "A", 1, MSG_OOB);
recv(socks[0], &dummy, 1, MSG_OOB);
send(socks[1], "A", 1, MSG_OOB);
recv(socks[0], &dummy, 1, MSG_OOB);
send(socks[1], "A", 1, MSG_OOB);
recv(socks[0], &dummy, 1, 0); // Non-OOB receive consumes data, potentially freeing OOB context
recv(socks[0], &dummy, 1, MSG_OOB); // Operations against the now-freed context leads to UAF
## Exploitation
- Status: PoC available. The researcher confirmed exploring the feasibility of exploiting this bug from within the Chrome Linux Desktop renderer sandbox to escalate privileges to the kernel.
- Complexity: Medium to High (Requires specific memory grooming and state manipulation within a restricted sandbox environment to achieve kernel code execution).
- Attack Vector: Local (The attack originates from code executing within the sandbox, attempting a local privilege escalation to the kernel).
## Impact
- Confidentiality: Potential compromise (leading to kernel memory disclosure/read primitives if exploited successfully).
- Integrity: Potential system compromise (leading to arbitrary kernel write primitives).
- Availability: Potential denial of service or system crash (via UAF).
## Remediation
### Patches
- A fix was submitted and merged into the Linux kernel mainline:
- **Kernel Commit ID:** `32ca245464e1479bfea8592b9db227fdc1641705`
### Workarounds
1. **Disable/Block `MSG_OOB` in Userland (Specific to Chrome Context):** Sending `MSG_OOB` messages has been explicitly blocked in Chrome renderers.
2. **Kernel Configuration (Pre-December 2024):** While disabling `CONFIG_AF_UNIX_OOB` might be possible in older kernels (before commit `5155cbcdbf03` introduced prompt), this is not a general operational solution.
## Detection
- **Indicators of Compromise:** Abnormal kernel memory corruption related to UNIX domain socket SKB structures following specific patterns of `MSG_OOB` and standard message interaction.
- **Detection Methods and Tools:** Tracing syscalls related to `send`/`recv` on `AF_UNIX` sockets with flag combinations involving `MSG_OOB` may reveal suspicious activity, although exploitation is highly dependent on kernel state synchronization.
## References
- Vendor Advisory (Reported to Linux): `https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=32ca245464e1479bfea8592b9db227fdc1641705`
- Chrome Mitigation: `https://chromium-review.googlesource.com/c/chromium/src/+/6711812`
- Project Zero Report: `http://projectzero.google/2025/08/from-chrome-renderer-code-exec-to-kernel.html` (Defanged URL format for reference)
- Exploit Attachment/Bug Tracker: `https://project-zero.issues.chromium.org/issues/423023990#attachment67577205` (Defanged URL format for reference)