PaperlayerView exact revision on arXiv

Source-linked AI summary

Harvest Season for SLUB: From io_uring vulnerability to Novel Sheaf-Based Exploitation Techniques

Hao-Yu Yang, Yu-Ting Lin

arXiv:2609.37608v1cs.CR

TL;DR

The paper examines two io_uring vulnerabilities and how Linux 6.18’s SLUB sheaf/barn layers affect established kernel exploitation techniques. It develops one vulnerability into a local privilege-escalation chain and analyzes allocator behaviors to derive new exploitation techniques, including RCU-sheaf cross-cache. Its findings include an exploit under modern protections and weakened SLUB freelist protection, while the RCU-sheaf approach avoids reliance on buddy-system page reclaim.

  • Problem

    The paper investigates how io_uring vulnerabilities and Linux 6.18’s sheaf/barn allocator layers affect kernel exploitation techniques and protections.

    Source: §7 · p. 28

  • Method

    The authors analyze two io_uring vulnerabilities, develop an exploit chain for one, and study sheaf/barn behavior to construct exploitation techniques.

    Source: §7 · p. 29

  • Results

    The exploit achieves local privilege escalation with modern kernel protections enabled, and the analysis finds that sheaf/barn weakens SLAB_FREELIST_HARDENED.

    Source: §7 · p. 28

  • Takeaways & Limitations

    The RCU-sheaf cross-cache technique avoids dependence on buddy-system page reclaim and permits more flexible object placement across cache pools.

    Source: §7 · p. 29

    The demonstrated escalation was tested with KASLR, KPTI, SMAP, and SMEP enabled.

    Source: §3.2 · p. 9

Abstract

from arXiv · show

The Linux kernel's push for higher I/O performance and more efficient memory management has introduced new mechanisms that, while improving performance, also open new attack surfaces. This research examines two of them together: the io_uring subsystem and the sheaf/barn caching mechanism added to the SLUB allocator in Linux 6.18. In this research, two previously unknown vulnerabilities in io_uring are presented, and one is developed into a complete local privilege escalation chain under a hardened kernel configuration. Building this chain revealed that the sheaf/barn mechanism changes long-standing assumptions behind established exploitation techniques such as cross-cache attack, and that its design also weakens existing SLUB freelist protections. Both observations are analyzed and turned into working primitives. Building on this analysis, three novel sheaf-based exploitation techniques are proposed. Among them, an RCU-sheaf cross-cache technique removes the traditional dependence on the buddy system for moving objects across caches, giving more flexible and reliable control over object migration between cache pools. Together, these results characterize the sheaf/barn layer as a new and largely unexplored attack surface in Linux kernel exploitation.

1 Background

io_uring provides asynchronous I/O through shared submission and completion queues, while Linux 6.18’s SLUB allocator adds sheaf and barn caching layers above slab management.

1.1 io_uring Overview

  • io_uring uses shared submission and completion queues: userspace submits SQEs, and the kernel returns results as CQEs, avoiding a system call for most I/O operations.Source: §1.1 · p. 3, Figure 1 · p. 3

1.2 SLUB and the Sheaf Mechanism

  • Linux 6.18 adds sheaf and barn caching layers to SLUB’s traditional CPU-local and NUMA-node management, forming a three-layer object-management architecture.Source: §1.2 · p. 4
  • Per-CPU sheaves use main for current allocations and frees, spare as a replacement, and rcu_free to batch RCU objects after kfree_rcu.Source: §1.2 · p. 4

1.2.1 Layer 2: the barn layer (node_barn)

  • The NUMA-node barn reserves full and empty sheaves, swapping them with per-CPU sheaves when those are exhausted; the node layer manages slab state and reclamation.Source: §1.2.1 · p. 4, §1.2.2 · p. 5

2 Vulnerability 1: Race Condition Between CQ/SQ Resize and Deferred Task Work

Ring resizing and deferred task work can race because task-work flag updates do not use the resize lock. The proof of concept drives concurrent updates and resizing, with a patch reported and released.

2.1 Root Cause

  • Task work sets IORING_SQ_TASKRUN without the lock used by ring resizing, creating a race while resize temporarily clears and later replaces ring pointers.Source: §2.1 · p. 6

2.2 Proof of Concept

  • A timerfd-driven multishot poll generates deferred task work while a loop alternates IORING_ENTER_GETEVENTS and ring resizing, potentially causing a null pointer dereference.Source: §2.2 · p. 7

Disclosure Timeline

  • The vulnerability was reported upstream with a proposed patch on 2026-03-09, and the patch was merged and released on 2026-03-17.Source: Disclosure Timeline · p. 7

3 Vulnerability 2: Logic Error in the Error-Handling Path of the Provided-Buffer Bundle Expansion Flow

An error path in io_uring’s provided-buffer bundle expansion can leave kmsg pointing to a freed iovec, creating a use-after-free. The paper uses the primitive to leak addresses and overwrite credentials for local privilege escalation.

3.1 Root Cause

  • An illegal provided-buffer address triggers an early error return after the old iovec is freed but before kmsg adopts the replacement, leaving kmsg with a stale pointer.Source: §3.1 · p. 9

3.2.1 Leaking KASLR

  • The resulting UAF primitive permits controlled-size GFP_KERNEL allocation and writes, but CONFIG_MEMCG_KMEM constrains heap-spray targets; cross-cache is offered as an alternative.Source: §3.2.1 · p. 10

First sending

  • The exploit makes iovec expansion reachable by sending a bundle of multiple provided buffers, then uses an illegal address to trigger the stale-pointer error path and a subsequent double free.Source: First sending · p. 10, Second sending · p. 10

Third sending

  • Reading back a corrupted user_key_payload produces an out-of-bounds read that leaks KASLR.Source: Third sending · p. 11

3.2.2 Leaking the task_struct address

  • Overlapping a sprayed key structure with kmalloc-2048 memory allows the current process’s task_struct address to be leaked.Source: §3.2.2 · pp. 11–12

3.2.3 One-shot cred overwrite leading to local privilege escalation

  • An overlapped msg_msg is arranged so list_del writes init_cred into task_struct->cred, completing local privilege escalation to root.Source: §3.2.3 · p. 12

Disclosure Timeline

  • It was reported upstream together with a proposed patch on 2026-07-06, and the patch was merged and released on 2026-07-12.Source: Disclosure Timeline · p. 13

4 The Impact of Sheaf on Traditional Exploitation and the Solutions

SLUB sheaf caching can prevent traditional cross-cache attacks by keeping logically freed objects in use from the slab’s perspective. The paper proposes two ways to restore cross-cache behavior.

4.1 The Impact of the Sheaf Mechanism

  • Sheaf-cached objects remain marked in use by the slab, preventing buddy-system reclamation and blocking traditional cross-cache overlap with another kmem_cache.Source: §4.1 · p. 13

4.2 Solution 1: Flushing Sheaf and Barn Objects Back to the Slab Management Layer

  • Flushing enough objects forces full sheaves through the barn and back to the slab, allowing slab->inuse to fall so the buddy system can reclaim pages.Source: §4.2 · p. 14

4.3 Solution 2: Bypassing the Sheaf Cache Layer via Cross-NUMA Node Allocation

  • A remote-NUMA object is returned directly to its original slab because caching it remotely would reduce later local-node allocation hits and increase overhead.Source: §4.3 · p. 15
  • With two NUMA nodes, freeing an object on a node different from its slab’s node bypasses sheaf caching and falls back to __slab_free, enabling cross-cache flow.Source: §4.3 · p. 16

5 Sheaf Design Flaws: Inconsistency Between the Sheaf and Traditional Slab Implementations

The sheaf layer’s handling differs from traditional SLUB in ways that undermine both CONFIG_SLAB_FREELIST_HARDENED double-free detection and freelist pointer protection.

5 Sheaf Design Flaws: Inconsistency Between the Sheaf and Traditional Slab Implementations

  • Sheaf’s handling diverges from traditional SLUB, leaving both freelist-hardening protections ineffective.The section examines double-free detection and pointer protection separately.Source: §5 · p. 16

5.1 Flaw 1: Bypassing CONFIG_SLAB_FREELIST_HARDENED double free detection

  • Sheaf can store duplicate references to a repeatedly freed object without set_freepointer(), allowing two allocations to share one memory block without triggering SLUB’s double-free check.Sheaf manages objects before they reach the SLUB freelist.Source: §5.1 · p. 17

5.2 Flaw 2: Bypassing CONFIG_SLAB_FREELIST_HARDENED pointer protection

  • Freed-object pointers in the sheaf array are unencrypted, allowing an attacker to hijack them and control the memory location returned by the kmem_cache.Traditional SLUB instead encodes freelist pointers.Source: §5.2 · p. 17

6 Novel Techniques: Sheaf-Based Exploitation

The paper proposes three sheaf-based exploitation techniques after analyzing how the new layer affects kernel exploitation. It details an object-array hijack that uses a UAF to steer allocator results toward attacker-chosen memory.

6 Novel Techniques: Sheaf-Based Exploitation

  • The paper proposes three novel sheaf-based techniques and offers a more detailed, concrete account than prior sheaf-exploitation discussions, which it says include incorrect descriptions.It specifically challenges a prior account of triggering cross-cache flow through refill_sheaf.Source: §6 · p. 18

6.1 Technique 1: Object Array Hijack

  • Freed objects enter the current main sheaf’s pointer array, and allocations are taken from that array; overwriting its object pointers can redirect SLUB allocations.Each kmem_cache has a sheaf layer, and the slab_sheaf backing cache depends on the managed object size.Source: §6.1 · pp. 18–19, Table 1 · p. 19
  • A UAF can hijack the slab_sheaf object array to achieve arbitrary read and write, including by targeting locations such as modprobe_path.The technique heap-sprays slab_sheaf objects in kmalloc-64, kmalloc-128, kmalloc-256, or kmalloc-512 buckets.Source: §6.1 · pp. 20–21, Figure 3 · p. 20

6.2 Technique 2: Object Array Out-of-Bounds Write

The object-array out-of-bounds technique uses corrupted sheaf metadata to write beyond the array and overwrite task credentials, completing privilege escalation.

6.2 Technique 2: Object Array Out-of-Bounds Write

  • A corrupted sheaf size can send a freed-object pointer beyond the object array, producing a single arbitrary pointer write.The described check treats a sheaf as full when size equals capacity, but does not prevent size from exceeding capacity.Source: §6.2 · p. 22
  • Two prepared root-privileged cred structures are freed into successive out-of-bounds slots to overwrite task_struct real_cred and cred, after which the size is restored.Interleaved slab_sheaf and task_struct sprays arrange the target layout.Source: §6.2 · p. 22
  • A subprocess detecting that its uid has become 0 can open a root shell, completing privilege escalation.Figure 4 depicts the out-of-bounds write past the slab_sheaf object array.Source: §6.2 · p. 22, Figure 4 · p. 23

6.3 Technique 3: Cross-Cache via the RCU slab_sheaf

Traditional cross-cache exploitation depends on buddy-system page reclamation, but sheaf caching can keep freed objects in use from the slab’s perspective. The RCU-sheaf technique redirects objects to another cache by manipulating the cache metadata used when the sheaf is flushed.

6.3 Technique 3: Cross-Cache via the RCU slab_sheaf

  • Traditional cross-cache requires mass frees to fill the SLUB partial freelist, and the page holding the UAF object may be reclaimed unpredictably.Operating-system allocation noise and buddy-system merging of adjacent reclaimed pages further complicate obtaining the target page.Source: §6.3 · p. 23
  • Freed RCU objects accumulate in a sheaf until the grace period ends, when a callback processes the batch and flushes it to a barn or slab.The sheaf’s cache field determines the destination cache and barn.Source: §6.3 · pp. 23–24
  • Hijacking the RCU sheaf’s cache field redirects its objects into an arbitrary kmem_cache during the RCU callback.The callback flushes the sheaf after the grace period; the cache field determines which cache’s barn receives it.Source: §6.3 · pp. 24–25, Figure 5 · p. 25
  • This route avoids buddy-system page reclamation, reducing uncertainty and removing the need for the complex free procedure or NUMA-dependent operations.The authors report that these changes simplify execution and improve portability.Source: §6.3 · p. 25

6.4 Applying Technique 3 to Vulnerability 2

The paper applies the RCU-sheaf cross-cache technique to its provided-buffer vulnerability, using an information leak and cache-field corruption to redirect a UAF object into cred_jar. Fork subprocesses then attempt to obtain and overwrite the object, ultimately achieving privilege escalation.

6.4.1 Triple free for information leak and overlapping the RCU slab_sheaf

  • A triple free supplies a reusable pointer; overlapping user_key_payload with the iovec enables an out-of-bounds read to observe sheaf state and leak cred_jar’s address.IPv6 multicast sockets provide the RCU-sheaf heap spray, and exhausting free sheaves forces allocation of a new RCU slab_sheaf that takes the third pointer.Source: §6.4.1 · p. 26

6.4.2 Leaking the cred kmem_cache address

  • The iovec leak is restored, and cred spraying exposes the cred kmem_cache structure near user_key_payload, allowing the cred_jar address to be leaked.Although cred is also kmalloc-192 in size, its cache is independent of the general cache pool and does not disturb the earlier state.Source: §6.4.2 · p. 26

6.4.3 Privilege escalation by poisoning the RCU cache and cross-cache attacking

  • After RCU ends, the UAF object enters the overlapped RCU slab_sheaf; changing its cache field to cred_jar routes the full sheaf into cred’s barn.The technique is applied across kmalloc-192 and kmalloc-512, the sizes of the target object and its slab_sheaf, respectively.Source: §6.4.1 · p. 26, §6.4.3 · p. 27
  • Privilege escalation is achieved after fork subprocesses obtain the UAF object in cred_jar and write through the iovec, overwriting a process’s uid or gid.The subprocesses repeatedly check whether either credential value has changed.Source: §6.4.3 · p. 27

7 Conclusion

The paper reports two io_uring vulnerabilities and a complete local privilege-escalation chain for one of them. Its analysis of Linux 6.18 sheaf/barn caching identifies changes to cross-cache exploitation and SLUB protections, and develops three sheaf-based techniques.

7 Conclusion

  • The first vulnerability is a race between CQ/SQ ring resizing and deferred task work that can cause a null pointer dereference.The race arises from insufficient synchronization when ring state is updated.Source: §7 · p. 27
  • The second provided-buffer vulnerability is a use-after-free, and the paper builds a complete local privilege-escalation chain for it with modern kernel protections enabled.The error path fails to update the iovec pointer after an illegal buffer address triggers rollback.Source: §7 · pp. 27–28
  • Sheaf/barn caching can keep a freed object marked in use, preventing buddy-system reclamation and disrupting traditional cross-cache attacks.The paper proposes mass sheaf flushing or cross-NUMA allocation and freeing as ways to return to the original slab mechanism.Source: §7 · p. 28
  • The sheaf fast path bypasses the SLUB freelist double-free check, while the sheaf object-pointer array is not covered by pointer encryption.The paper also describes object-array hijacking and an out-of-bounds write using sheaf metadata.Source: §7 · p. 28
  • The paper proposes three sheaf-based techniques: object-array hijacking, object-array out-of-bounds writes, and cross-cache routing through an RCU sheaf.The RCU approach avoids dependence on buddy-system page reclamation and allows more flexible, stable steering between cache pools.Source: §7 · pp. 28–29
Loading 2609.37608v1…