Preprint

Preprint describes two io_uring flaws and three sheaf attack techniques

The source-code study reports a local privilege escalation under modern kernel protections, but both vulnerabilities are described as fixed and patched.

The two paths to failure

A preprint on Linux kernel security reports two previously unknown vulnerabilities in io_uring and three proposed exploitation techniques built around the SLUB sheaf/barn caching mechanism, introduced in Linux 6.18. It also reports a complete local privilege-escalation chain under multiple modern Linux kernel protections.

The two bugs sit in separate kernel paths. The first is an unsynchronized interaction between resizing the CQ/SQ rings and deferred task work. The reported outcome is a null pointer dereference, meaning the code reaches an invalid empty address. The second appears on an error path: after an iovec expansion and an illegal buffer address, kmsg retains a pointer to the old iovec array after that array has been freed. That creates a use-after-free, a condition in which later code still refers to released memory.

Why the allocator matters

To trace the routes, the paper uses source-code and control-flow analysis, proof-of-concept procedures, exploit chains and demonstrations. One described race procedure calls io_uring_enter(GETEVENTS) and then IORING_REGISTER_RESIZE_RINGS on every loop iteration. The work follows allocator state and object movement through specific operations rather than estimating a population-level risk.

That object movement changes when sheaf/barn caching is present. In the described sheaf context, the slab page containing the released use-after-free object cannot be reclaimed by the buddy system, so the intended traditional cross-cache attack cannot succeed. The paper proposes two workarounds: flushing many sheaves through the barn into the slab, or allocating on one NUMA node and freeing on another, where the text reports that remote objects are not cached by sheaf.

The authors also point to gaps in protections inside the sheaf path. They report that repeated frees can leave duplicate references stored in the sheaf without using set_freepointer(), and that later allocations may share the same memory block. Separately, the sheaf object pointer is reported as unencrypted, leaving the allocation location controllable. Together, those observations change both whether a freed object can be reused and where an allocation may land.

Three routes through the sheaf layer

The first proposed technique uses a use-after-free to overwrite the sheaf object array. The paper says this can make allocator returns target a chosen location and provide an arbitrary read/write primitive. Techniques 1 and 2 were verified with a custom kernel driver, an important boundary on what the demonstrations show. The second technique uses an object-array out-of-bounds method with a sheaf size beyond capacity to obtain a single arbitrary pointer write.

The third technique takes a different route. In the RCU-sheaf cross-cache method, a hijacked cache field directs a use-after-free object into an arbitrary kmem_cache without the traditional buddy-system route. Applied to the provided-buffer vulnerability, the sequence is described as moving the object into cred_jar and achieving privilege escalation after heap-spray and fork-based steps. This is the paper's application of the technique to the second bug, not a claim that the same chain has been demonstrated across unrelated vulnerabilities.

A finding with defined limits

The paper's result is therefore narrow but significant for the code it examines. It reports a complete local privilege-escalation chain, but the result is tied to the described kernel protections, procedures and allocator behavior. The supplied evidence does not establish how these techniques behave across all Linux versions, hardware or workloads.

The paper says both vulnerabilities were reported upstream, fixed and patched. That status matters: the preprint is describing a security mechanism and exploitability path, not showing that either issue remains unpatched. Its broader warning concerns the sheaf/barn layer itself, whose caching, object references and pointer handling may warrant scrutiny alongside traditional SLUB defenses.

Paper data and sources

Original title: Harvest Season for SLUB: From io_uring vulnerability to Novel Sheaf-Based Exploitation Techniques
Authors: Hao-Yu Yang, Yu-Ting Lin
Journal/Repository: arXiv
Status: Preprint, not yet peer-reviewed
First online: 2026-09-29
DOI: Not available
Original paper · Full text

Versions and corrections

  1. Published automatically after legal-source, freshness, evidence, and independent-verification gates passed.