New Linux Kernel Vulnerability Exploited Directly From Chrome’s Renderer Sandbox (via a rare socket feature)

By CyberDudeBivash — Cybersecurity & AI

Executive summary

Google Project Zero disclosed a kernel bug (CVE-2025-38236) in the Linux AF_UNIX stack that’s reachable from inside Chrome’s Linux renderer sandbox using the obscure MSG_OOB (out-of-band) flag on UNIX stream sockets. The flaw enables a use-after-free (UAF) that Jann Horn demonstrated can be turned into reliable kernel-privilege escalation from a compromised renderer on Debian/x86-64. Linux has shipped fixes; Chromium also updated its sandbox to block MSG_OOB from renderers. Patch now and consider policy controls that eliminate rarely used kernel features from sandboxed code paths. Project ZeroNVD


What makes this novel

  • Rare feature, big impact: MSG_OOB for UNIX domain stream sockets was added in 5.15, is almost unused (notably by some Oracle software), yet was exposed by default wherever AF_UNIX is enabled. Chrome didn’t filter send/recv flags, so renderers could access it. Project Zero
  • Renderer ➜ kernel in one hop: No browser sandbox escape needed—renderer code execution alone could hit the kernel and escalate. Project Zero
  • Fast mitigation upstream: Kernel patches landed; Chromium blocked MSG_OOB in renderers to shrink attack surface. Project Zerochromium-review.googlesource.com

Vulnerability deep dive (CVE-2025-38236)

Component: Linux kernel net/unix/af_unix.c (AF_UNIX stream sockets with MSG_OOB)
Type: Use-after-free due to mishandling of consecutive consumed OOB sk_buffs on a socket’s receive queue.
Trigger (simplified): Alternating send(..., MSG_OOB) and recv(..., MSG_OOB) leaves multiple “consumed” OOB SKBs; a subsequent normal recv() frees the real OOB SKB while it’s still reachable, producing UAF, then another recv(..., MSG_OOB) touches freed memory. NVD reproducer confirms the sequence. NVD

Where it came from: A mid-2024 change fixing a spurious recv() behavior introduced logic that allowed back-to-back consumed OOB SKBs, opening the UAF. Project Zero notes the buggy fix was only backported to 6.9.x series, not older LTS branches. Project Zero

Fix status: Kernel stable commits (e.g., 32ca2454…61a9ad7b…8db4d2d…a122378…fad0a2c…) adjust OOB handling to avoid leaving consecutive consumed OOB SKBs. See CVE references for exact patches and backports. NVD


Exploitation notes (from the renderer sandbox)

Project Zero’s write-up walks through turning the UAF into robust read/write primitives and ultimately privilege escalation, all from Chrome 137 renderer on Debian Trixie:

  • Read primitive: Abuse how copy_to_user() behaves on x86-64 to read kernel memory by crafting SKBs, even probing the IDT to break KASLRProject Zero
  • Write primitive / reallocation: Reallocate the freed page as a kernel stack page (leveraging CONFIG_RANDOMIZE_KSTACK_OFFSET) and steer control flow by corrupting stack contents at predictable offsets. Project Zero
  • Grooming & timing: Use allowed interfaces inside the renderer sandbox—AF_UNIX sockets, pipes, mprotect()/madvise() tricks—to groom heap and delay memory copies without privileged helpers like userfaultfdProject Zero

Why Chrome was reachable: The Linux renderer sandbox allowed UNIX stream sockets and did not filter send/recv flags, so MSG_OOB was usable even though Chrome itself doesn’t need it. Chromium has now blocked MSG_OOB for renderers. Project Zerochromium-review.googlesource.com


Affected footprint

  • Linux kernels: 6.9.x with the buggy OOB handling; refer to your distro’s advisories to map exact builds containing/receiving the fix. (NVD ties CVE-2025-38236 to AF_UNIX MSG_OOB UAF and links the stable patches.) NVD
  • Applications: Anything enabling UNIX stream sockets in unprivileged sandboxes could be exposed; Chrome was the high-value example because renderer RCEs are common. Project Zero

Risk to enterprises

If an attacker achieves renderer RCE (e.g., via a web content bug), this kernel flaw permits one-shot local privilege escalation to root from within the renderer sandbox—bypassing the browser process boundary and OS hardening. Threat actors routinely chain renderer bugs + LPE for full host compromise. Project Zero


Mitigation & hardening checklist

Patch & configuration

  • Update kernels to a release containing the stable fixes for CVE-2025-38236 (see NVD references for commit IDs your vendor backports). Prioritize Linux 6.9.x fleets. NVD
  • Where feasible, disable AF_UNIX OOB at build time (CONFIG_AF_UNIX_OOB introduced a prompt in late 2024) or ensure it’s off—very few workloads need it. Project Zero
  • Update Chromium/Chrome across Linux endpoints; look for builds after Aug 8, 2025 that include the renderer-side MSG_OOB blockchromium-review.googlesource.com

Sandbox & syscall policy

  • If you operate custom sandboxes (containers, flatpaks, Electron), add seccomp-BPF rules that mask MSG_OOB and other esoteric flags for send/recv, not just the syscalls themselves. (PZ highlights multiple past incidents where flags exposed risky ancillary features.) Project Zero

Detect & monitor (interim)

  • Kernel version exposure: inventory Linux hosts by exact kernel build; flag 6.9.x lines without the stable patches applied. (Distro advisories will cite the CVE.) NVD
  • eBPF/tracepoints (advanced): temporarily instrument __sys_sendto/__sys_recvfrom to count MSG_OOB on AF_UNIX, SOCK_STREAM from unprivileged PIDs; any hits in production are suspicious.
  • Browser telemetry: watch for renderer crashes paired with kernel oops/KASAN splats; investigate chains that start from untrusted web content.

For detection engineers (rules & hunts)

Hunt: suspicious OOB usage (host-level audit)

Concept: alert when an unprivileged process uses MSG_OOB on AF_UNIX stream sockets.

  • Approach: eBPF kprobe on unix_stream_recvmsg / unix_stream_sendmsg checking flags & MSG_OOB.
  • Signal: process name = chrome --type=renderer (or your sandboxed app), non-zero rate of OOB ops within short windows.

Hunt: renderer ➜ LPE chain

Correlate renderer code-exec indicators (e.g., GPU/JS crashes, JIT anomalies) with kernel anomalies on the same host (KASAN/BUG/Oops messages) and unusual pipe/socket churn prior to crash—consistent with heap grooming shown in PZ’s exploit. Project Zero


Lessons for platform & kernel teams

  • Policy must filter flags, not just syscalls. Many dangerous behaviors hide behind innocuous syscalls gated by flags (e.g., MSG_OOBMFD_HUGETLB). Project Zero
  • Default-deny esoterica in sandboxes: if the feature isn’t needed, don’t expose it. Chromium’s follow-up change is a good model. chromium-review.googlesource.com
  • Kernel feature hygiene: niche features enabled by default expand attack surface disproportionately to their utility. Make them opt-in (kconfig) and document their security implications. Project Zero

What to do today (priority order)

  1. Patch Linux to a build with CVE-2025-38236 fixes (or vendor backports). NVD
  2. Update Chrome/Chromium on Linux endpoints (versions shipping the MSG_OOB block). chromium-review.googlesource.com
  3. Reduce attack surface: if you control sandboxes, mask MSG_OOB and audit for other exotic flags/features reachable from unprivileged code. Project Zero
  4. Instrument & hunt for AF_UNIX OOB usage until your fleet is fully patched.

References

  • Project Zero technical write-up and exploit notes. Project Zero
  • NVD entry (reproducer and stable patch links). NVD
  • CyberSecurityNews/GBHackers coverage summarizing scope and Chromium mitigation. Cyber Security NewsGBHackers

Leave a comment

Design a site like this with WordPress.com
Get started