GCVE-1988-2026-0450
Vulnerability from gna-1988 – Published: 2026-11-02 07:29 – Updated: 2026-11-02 07:29
VLAI
EPSS
VEX
Title
[Bugtraq] UAF Exploitation in the Sheaves Era
Summary
|=------------------------------------------------------------------------=|
|=--------------=[ UAF Exploitation in the Sheaves Era ]=---------------=|
|=------------------------------------------------------------------------=|
|=--------------=[ w1sdom (antonius@bluedragonsec.com) ]=-----------------=|
|=------------------------------------------------------------------------=|
"The greatest trick the Devil ever pulled was convincing the world he didn't exist"
-- Charles Baudelaire
--[ Table of Contents
1 - Introduction
2 - The Sheaves Architecture
2.1 - How Sheaves Work
2.2 - The 3 Main Structures of Sheaves
2.3 - Sheaves Mechanism
2.3.1 - calculate_sheaf_capacity()
2.3.2 - Allocation Path
2.3.3 - Free Path
3 - Related Anti Exploitation
3.1 - KASLR & kptr_restrict
3.2 - HARDENED_USERCOPY
3.3 - RANDOM_KMALLOC_CACHES
3.4 - INIT_ON_ALLOC
3.5 - INIT_ON_FREE
3.6 - CFI, FineIBT
4 - Same Cache Reclaim via Sheaves Architecture
4.1 - Technical Background
4.2 - With Information Leak
4.2.1 - Converting UAF write to provide leak
4.2.2 - Side Channel Attack - EntryBleed
4.3 - SheafJack
4.3.1 - What is SheafJack ?
4.3.2 - SheafJack & Deep Sheaf Poisoning
4.4 - Without Information Leak
4.4.1 - DirtyCred
4.4.2 - PageJack
5 - Cross Cache Exploitation in Sheaves Architecture
5.1 - Technical Background
5.1.1 - Slab Page Order
5.1.2 - From Sheaves to Buddy - The Math
5.1.3 - Cross Cache - Volume Overflow Technique
5.1.4 - Cross Cache - Complete Free Technique
5.1.5 - Cross Cache - Kratnowl 6-pool
5.1.6 - Cross Cache - SheavesSiphon
5.2 - With Information Leak
5.3 - Without Information Leak
6 - Elastic Object
6.1 - Technical Background
6.2 - Elastic Object Lists
7 - Real Life Exploit - CVE-2026-46215
7.1 - The Bug
7.2 - Exploitation
8 - Game Over !!!
8.1 - Final Words
8.2 - About the Author
9 - Thanks
10 - References
11 - Appendix
--[ 1 - Introduction
The sheaves architecture changes the concept of modern slub exploitation.
A freed object is no longer handed straight back to the slab freelist.
Instead, it is parked in a per-cpu sheaf and surplus sheaves are buffered
in a per-node structure called the barn.
This paper is about use after free exploitation techniques specific to the
new slub sheaves architecture in the linux kernel 7 series on
x86_64 architecture.
Please note that the source code analysis in this article is based on the
linux kernel 7.0 source.
So What is Sheaves ?
Sheaves is a concept of an additional caching layer introduced since linux
kernel 6.18 by slab maintainer Vlastimil Babka.
At the time it was merged into linux kernel 6.18, this caching layer was an
opt-in feature for slub allocations.
Since the linux kernel 7 series, sheaves are enabled by default for most heap
allocations inside the linux kernel.
Sheaves are disabled globally when CONFIG_SLUB_TINY is enabled.
Otherwise, sheaves are enabled by default for all caches, with the
exception of some special flag caches.
Caches without sheaves are those with any of the following flags:
- SLAB_DEBUG_FLAGS (when slub_debug is active for the cache)
- SLAB_NO_OBJ_EXT (bootstrap caches)
- SLAB_NOLEAKTRACE (kmemleak's object_cache and scan_area_cache)
This paper makes the following contributions:
[1] First public documentation of SLUB sheaves internals from an offensive perspective.
[2] Live verified capacity tier table for kernel 7.0.
[3] Formal model of return-to-buddy via barn saturation.
[4] Deterministic same cache UAF reclaim recipe.
[5] Linux 7.0 elastic object catalog.
[6] Exotic exploitation technique.
[7] Novel cross-cache techniques.
--[ 2 - The Sheaves Architecture
----[ 2.1 - How Sheaves Work
A sheaf is basically a small structure wrapping a FAM of object pointers,
together with a size counter and a pointer to its owning kmem_cache.
Each CPU owns a slub_percpu_sheaves structure that holds up to three sheaves:
- a main sheaf that allocations are served from.
- a spare sheaf kept ready as a replacement.
- an rcu_free sheaf used to batch kfree_rcu() objects.
Each Node owns a node_barn structure, the barn holds sheaves, the purpose of
this barn is to facilitate sheaf migrations between CPUs inside a node.
There is a condition when an allocation needs a fresh sheaf but a CPU scope
can't provide the fresh sheaf, the per-node barn can be used to provide a fresh
sheaf for that allocation.
When both sheaves (main & spare) are full in slub_percpu_sheaves, the barn will be
used to keep sheaves that are not currently being used for caching by any CPU.
The Diagram that describes the layout and mechanism is shown below.
CPU 0 CPU 1 NUMA node 0
per-cpu sheaves per-cpu sheaves kmem_cache_node
-------------------- ----------------- ----------------------
| lock (trylock) | | lock | | list_lock |
| main ->---------|-- | main ->... | | nr_partial |
| spare -> | | | spare -> | | partial (slab list)|
| rcu_free -> | | | rcu_free -> | | barn ->------------|-
-------------------- | ----------------- ---------------------- |
| |
main points to | v
a sheaf v --------------------
------------------------- refill / flush | node_barn |
| slab_sheaf | whole sheaves | lock (spinlock) |
| union{...} |<------------------------- >| sheaves_full |
| cache | | sheaves_empty |
| size | | nr_full/nr_empty |
| objects[] | --------------------
-------------------------
|
v served from slab pages via partial/barn
-------------------
| slab |
| freelist |
| inuse / objects |
-------------------
Allocation and freeing are pure LIFO operations on the main sheaf's array
that is the objects[] FAM.
To allocate a new object, the kernel takes the last pointer,
pcs->main->objects[pcs->main->size - 1], and decrements size.
To free, it writes the object back as pcs->main->objects[pcs->main->size++].
There is no object metadata, no freelist pointer walk, no pointer
obfuscation, and no cross-CPU interaction occurs on this path.
--2.2 - The 3 Main Structures of Sheaves
Every kmem_cache that qualifies will have its own per-CPU structure called struct
slub_percpu_sheaves.
Understanding these 3 core structures is really important to understand the
mechanism of sheaves. By understanding the mechanism of sheaves we can get some
ideas of how to exploit this mechanism.
There are 3 main structures defined in mm/slub.c in linux kernel 7.0.
These 3 main structures are the core implementation of sheaves.
#1 core struct - struct slab_sheaf
This is the main core struct of sheaves mechanism, this is the object container
that serving for allocations and frees.
By accommodating this sheaf, the allocation or freeing no longer needs to
touch the per-CPU slab freelist.
From mm/slub.c line 404, we can see the definition of slab_sheaf main structure.
---------------------------------------------------------------------------
$ pahole -C slab_sheaf vmlinux
struct slab_sheaf {
union {
struct callback_head callback_head
__attribute__((__aligned__(8))); /* 0 16 */
struct list_head barn_list; /* 0 16 */
struct {
unsigned int capacity; /* 0 4 */
bool pfmemalloc; /* 4 1 */
}; /* 0 8 */
} __attribute__((__aligned__(8))); /* 0 16 */
struct kmem_cache * cache; /* 16 8 */
unsigned int size; /* 24 4 */
int node; /* 28 4 */
void * objects[]; /* 32 0 */
} __attribute__((__aligned__(8)));
---------------------------------------------------------------------------
- The union {...} part is about the state of the sheaf, whether it's in an
rcu queue, inside the barn list, or used as a prefilled sheaf. The size of
this union is 16 bytes located at offset 0-15.
- struct kmem_cache *cache is a back pointer to the kmem_cache that owns
this sheaf.
It is set once when the sheaf is created (sheaf->cache = s) and is later
trusted, not revalidated, when the sheaf is processed.
The size is 8 bytes located at offset 16.
- unsigned int size, this is the number of object pointers currently stored in
objects[].
It is the LIFO counter that drives every allocation and free on the sheaf.
The size is 4 bytes located at offset 24.
- int node, this is the NUMA node id, used only when the sheaf is on the
rcu_free path.
It is written just before the sheaf is handed off to RCU. The size is 4 bytes
located at offset 28.
- void *objects[] is a FAM holding the sheaf's cached object pointers.
Every allocation served from this sheaf returns one of these
pointers directly.
No freelist walk nor pointer obfuscation on the fast path.
The size of each entry inside objects[] FAM is 8 bytes,
objects[] located at offset 32.
#2 core struct - struct slub_percpu_sheaves
From mm/slub.c line 420, we can see the definition of
slub_percpu_sheaves structure.
---------------------------------------------------------------------
$ pahole -C slub_percpu_sheaves vmlinux
struct slub_percpu_sheaves {
local_trylock_t lock; /* 0 1 */
struct slab_sheaf * main; /* 8 8 */
struct slab_sheaf * spare; /* 16 8 */
struct slab_sheaf * rcu_free; /* 24 8 */
};
---------------------------------------------------------------------
This is the per-CPU control structure of the sheaves layer.
This structure is allocated in the
per-CPU area via alloc_percpu() (mm/slub.c line 8478):
----------------------------------------------------------
s->cpu_sheaves = alloc_percpu(struct slub_percpu_sheaves);
----------------------------------------------------------
Every CPU owns its own private copy and the three sheaf pointers below are
reachable only through that per-CPU area.
- local_trylock_t lock, this serializes access to the per-CPU sheaves.
Both the allocation and the free fast paths take this lock before
touching main. The size is 1 byte located at offset 0.
- Offset 1-7 is a hole with the size of 7 bytes, used as padding to make
main fall at offset 8.
- struct slab_sheaf *main, this is the sheaf that allocations are actually
served from. The size is 8 bytes located at offset 8.
- struct slab_sheaf *spare, this is a backup sheaf kept ready so the CPU can
keep serving allocations without immediately going to the barn.
When main is exhausted, the kernel swaps main and spare.
The size is 8 bytes located at offset 16.
- struct slab_sheaf *rcu_free, this is the sheaf that batches objects
freed via kfree_rcu(). When it fills up it is detached and handed to
call_rcu(). The size is 8 bytes located at offset 24.
#3 core struct - struct node_barn
From mm/slub.c line 396, we can see the definition of node_barn structure.
-----------------------------------------------------------------------
$ pahole -C node_barn vmlinux
struct node_barn {
spinlock_t lock __attribute__((__aligned__(4))); /* 0 4 */
/* XXX 4 bytes hole, try to pack */
struct list_head sheaves_full; /* 8 16 */
struct list_head sheaves_empty; /* 24 16 */
unsigned int nr_full; /* 40 4 */
unsigned int nr_empty; /* 44 4 */
} __attribute__((__aligned__(8)));
-----------------------------------------------------------------------
This is the per-node structure that buffers whole sheaves so they can migrate
between CPUs without going all the way back to the page allocator.
- spinlock_t lock, this serializes all barn operations. Note the difference from
the per-CPU layer: the fast paths use a local_trylock on slub_pe
Severity
No CVSS data available.
Assigner
References
35 references
Impacted products
1 product
| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| unknown | UAF Exploitation in |
Affected:
unknown
|
guessed |
Relationships
analysis
GCVE-1988-2026-0450 (this record)
- related CVE-2022-4543
- related CVE-2024-1086
- related CVE-2026-46215
{
"containers": {
"cna": {
"affected": [
{
"product": "UAF Exploitation in",
"vendor": "unknown",
"versions": [
{
"status": "affected",
"version": "unknown"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "antonius\uff20bluedragonsec.com"
}
],
"descriptions": [
{
"lang": "en",
"value": "|=------------------------------------------------------------------------=|\n|=--------------=[ UAF Exploitation in the Sheaves Era ]=---------------=|\n|=------------------------------------------------------------------------=|\n|=--------------=[ w1sdom (antonius@bluedragonsec.com) ]=-----------------=|\n|=------------------------------------------------------------------------=|\n\"The greatest trick the Devil ever pulled was convincing the world he didn\u0027t exist\"\n-- Charles Baudelaire\n--[ Table of Contents\n1 - Introduction\n2 - The Sheaves Architecture\n2.1 - How Sheaves Work\n2.2 - The 3 Main Structures of Sheaves\n2.3 - Sheaves Mechanism\n2.3.1 - calculate_sheaf_capacity()\n2.3.2 - Allocation Path\n2.3.3 - Free Path\n3 - Related Anti Exploitation\n3.1 - KASLR \u0026 kptr_restrict\n3.2 - HARDENED_USERCOPY\n3.3 - RANDOM_KMALLOC_CACHES\n3.4 - INIT_ON_ALLOC\n3.5 - INIT_ON_FREE\n3.6 - CFI, FineIBT\n4 - Same Cache Reclaim via Sheaves Architecture\n4.1 - Technical Background\n4.2 - With Information Leak\n4.2.1 - Converting UAF write to provide leak\n4.2.2 - Side Channel Attack - EntryBleed\n4.3 - SheafJack\n4.3.1 - What is SheafJack ?\n4.3.2 - SheafJack \u0026 Deep Sheaf Poisoning\n4.4 - Without Information Leak\n4.4.1 - DirtyCred\n4.4.2 - PageJack\n5 - Cross Cache Exploitation in Sheaves Architecture\n5.1 - Technical Background\n5.1.1 - Slab Page Order\n5.1.2 - From Sheaves to Buddy - The Math\n5.1.3 - Cross Cache - Volume Overflow Technique\n5.1.4 - Cross Cache - Complete Free Technique\n5.1.5 - Cross Cache - Kratnowl 6-pool\n5.1.6 - Cross Cache - SheavesSiphon\n5.2 - With Information Leak\n5.3 - Without Information Leak\n6 - Elastic Object\n6.1 - Technical Background\n6.2 - Elastic Object Lists\n7 - Real Life Exploit - CVE-2026-46215\n7.1 - The Bug\n7.2 - Exploitation\n8 - Game Over !!!\n8.1 - Final Words\n8.2 - About the Author\n9 - Thanks\n10 - References\n11 - Appendix\n--[ 1 - Introduction\nThe sheaves architecture changes the concept of modern slub exploitation.\nA freed object is no longer handed straight back to the slab freelist.\nInstead, it is parked in a per-cpu sheaf and surplus sheaves are buffered\nin a per-node structure called the barn.\nThis paper is about use after free exploitation techniques specific to the\nnew slub sheaves architecture in the linux kernel 7 series on\nx86_64 architecture.\nPlease note that the source code analysis in this article is based on the\nlinux kernel 7.0 source.\nSo What is Sheaves ?\nSheaves is a concept of an additional caching layer introduced since linux\nkernel 6.18 by slab maintainer Vlastimil Babka.\nAt the time it was merged into linux kernel 6.18, this caching layer was an\nopt-in feature for slub allocations.\nSince the linux kernel 7 series, sheaves are enabled by default for most heap\nallocations inside the linux kernel.\nSheaves are disabled globally when CONFIG_SLUB_TINY is enabled.\nOtherwise, sheaves are enabled by default for all caches, with the\nexception of some special flag caches.\nCaches without sheaves are those with any of the following flags:\n- SLAB_DEBUG_FLAGS (when slub_debug is active for the cache)\n- SLAB_NO_OBJ_EXT (bootstrap caches)\n- SLAB_NOLEAKTRACE (kmemleak\u0027s object_cache and scan_area_cache)\nThis paper makes the following contributions:\n[1] First public documentation of SLUB sheaves internals from an offensive perspective.\n[2] Live verified capacity tier table for kernel 7.0.\n[3] Formal model of return-to-buddy via barn saturation.\n[4] Deterministic same cache UAF reclaim recipe.\n[5] Linux 7.0 elastic object catalog.\n[6] Exotic exploitation technique.\n[7] Novel cross-cache techniques.\n--[ 2 - The Sheaves Architecture\n----[ 2.1 - How Sheaves Work\nA sheaf is basically a small structure wrapping a FAM of object pointers,\ntogether with a size counter and a pointer to its owning kmem_cache.\nEach CPU owns a slub_percpu_sheaves structure that holds up to three sheaves:\n- a main sheaf that allocations are served from.\n- a spare sheaf kept ready as a replacement.\n- an rcu_free sheaf used to batch kfree_rcu() objects.\nEach Node owns a node_barn structure, the barn holds sheaves, the purpose of\nthis barn is to facilitate sheaf migrations between CPUs inside a node.\nThere is a condition when an allocation needs a fresh sheaf but a CPU scope\ncan\u0027t provide the fresh sheaf, the per-node barn can be used to provide a fresh\nsheaf for that allocation.\nWhen both sheaves (main \u0026 spare) are full in slub_percpu_sheaves, the barn will be\nused to keep sheaves that are not currently being used for caching by any CPU.\nThe Diagram that describes the layout and mechanism is shown below.\nCPU 0 CPU 1 NUMA node 0\nper-cpu sheaves per-cpu sheaves kmem_cache_node\n-------------------- ----------------- ----------------------\n| lock (trylock) | | lock | | list_lock |\n| main -\u003e---------|-- | main -\u003e... | | nr_partial |\n| spare -\u003e | | | spare -\u003e | | partial (slab list)|\n| rcu_free -\u003e | | | rcu_free -\u003e | | barn -\u003e------------|-\n-------------------- | ----------------- ---------------------- |\n| |\nmain points to | v\na sheaf v --------------------\n------------------------- refill / flush | node_barn |\n| slab_sheaf | whole sheaves | lock (spinlock) |\n| union{...} |\u003c------------------------- \u003e| sheaves_full |\n| cache | | sheaves_empty |\n| size | | nr_full/nr_empty |\n| objects[] | --------------------\n-------------------------\n|\nv served from slab pages via partial/barn\n-------------------\n| slab |\n| freelist |\n| inuse / objects |\n-------------------\nAllocation and freeing are pure LIFO operations on the main sheaf\u0027s array\nthat is the objects[] FAM.\nTo allocate a new object, the kernel takes the last pointer,\npcs-\u003emain-\u003eobjects[pcs-\u003emain-\u003esize - 1], and decrements size.\nTo free, it writes the object back as pcs-\u003emain-\u003eobjects[pcs-\u003emain-\u003esize++].\nThere is no object metadata, no freelist pointer walk, no pointer\nobfuscation, and no cross-CPU interaction occurs on this path.\n--2.2 - The 3 Main Structures of Sheaves\nEvery kmem_cache that qualifies will have its own per-CPU structure called struct\nslub_percpu_sheaves.\nUnderstanding these 3 core structures is really important to understand the\nmechanism of sheaves. By understanding the mechanism of sheaves we can get some\nideas of how to exploit this mechanism.\nThere are 3 main structures defined in mm/slub.c in linux kernel 7.0.\nThese 3 main structures are the core implementation of sheaves.\n#1 core struct - struct slab_sheaf\nThis is the main core struct of sheaves mechanism, this is the object container\nthat serving for allocations and frees.\nBy accommodating this sheaf, the allocation or freeing no longer needs to\ntouch the per-CPU slab freelist.\nFrom mm/slub.c line 404, we can see the definition of slab_sheaf main structure.\n---------------------------------------------------------------------------\n$ pahole -C slab_sheaf vmlinux\nstruct slab_sheaf {\nunion {\nstruct callback_head callback_head\n__attribute__((__aligned__(8))); /* 0 16 */\nstruct list_head barn_list; /* 0 16 */\nstruct {\nunsigned int capacity; /* 0 4 */\nbool pfmemalloc; /* 4 1 */\n}; /* 0 8 */\n} __attribute__((__aligned__(8))); /* 0 16 */\nstruct kmem_cache * cache; /* 16 8 */\nunsigned int size; /* 24 4 */\nint node; /* 28 4 */\nvoid * objects[]; /* 32 0 */\n} __attribute__((__aligned__(8)));\n---------------------------------------------------------------------------\n- The union {...} part is about the state of the sheaf, whether it\u0027s in an\nrcu queue, inside the barn list, or used as a prefilled sheaf. The size of\nthis union is 16 bytes located at offset 0-15.\n- struct kmem_cache *cache is a back pointer to the kmem_cache that owns\nthis sheaf.\nIt is set once when the sheaf is created (sheaf-\u003ecache = s) and is later\ntrusted, not revalidated, when the sheaf is processed.\nThe size is 8 bytes located at offset 16.\n- unsigned int size, this is the number of object pointers currently stored in\nobjects[].\nIt is the LIFO counter that drives every allocation and free on the sheaf.\nThe size is 4 bytes located at offset 24.\n- int node, this is the NUMA node id, used only when the sheaf is on the\nrcu_free path.\nIt is written just before the sheaf is handed off to RCU. The size is 4 bytes\nlocated at offset 28.\n- void *objects[] is a FAM holding the sheaf\u0027s cached object pointers.\nEvery allocation served from this sheaf returns one of these\npointers directly.\nNo freelist walk nor pointer obfuscation on the fast path.\nThe size of each entry inside objects[] FAM is 8 bytes,\nobjects[] located at offset 32.\n#2 core struct - struct slub_percpu_sheaves\nFrom mm/slub.c line 420, we can see the definition of\nslub_percpu_sheaves structure.\n---------------------------------------------------------------------\n$ pahole -C slub_percpu_sheaves vmlinux\nstruct slub_percpu_sheaves {\nlocal_trylock_t lock; /* 0 1 */\nstruct slab_sheaf * main; /* 8 8 */\nstruct slab_sheaf * spare; /* 16 8 */\nstruct slab_sheaf * rcu_free; /* 24 8 */\n};\n---------------------------------------------------------------------\nThis is the per-CPU control structure of the sheaves layer.\nThis structure is allocated in the\nper-CPU area via alloc_percpu() (mm/slub.c line 8478):\n----------------------------------------------------------\ns-\u003ecpu_sheaves = alloc_percpu(struct slub_percpu_sheaves);\n----------------------------------------------------------\nEvery CPU owns its own private copy and the three sheaf pointers below are\nreachable only through that per-CPU area.\n- local_trylock_t lock, this serializes access to the per-CPU sheaves.\nBoth the allocation and the free fast paths take this lock before\ntouching main. The size is 1 byte located at offset 0.\n- Offset 1-7 is a hole with the size of 7 bytes, used as padding to make\nmain fall at offset 8.\n- struct slab_sheaf *main, this is the sheaf that allocations are actually\nserved from. The size is 8 bytes located at offset 8.\n- struct slab_sheaf *spare, this is a backup sheaf kept ready so the CPU can\nkeep serving allocations without immediately going to the barn.\nWhen main is exhausted, the kernel swaps main and spare.\nThe size is 8 bytes located at offset 16.\n- struct slab_sheaf *rcu_free, this is the sheaf that batches objects\nfreed via kfree_rcu(). When it fills up it is detached and handed to\ncall_rcu(). The size is 8 bytes located at offset 24.\n#3 core struct - struct node_barn\nFrom mm/slub.c line 396, we can see the definition of node_barn structure.\n-----------------------------------------------------------------------\n$ pahole -C node_barn vmlinux\nstruct node_barn {\nspinlock_t lock __attribute__((__aligned__(4))); /* 0 4 */\n/* XXX 4 bytes hole, try to pack */\nstruct list_head sheaves_full; /* 8 16 */\nstruct list_head sheaves_empty; /* 24 16 */\nunsigned int nr_full; /* 40 4 */\nunsigned int nr_empty; /* 44 4 */\n} __attribute__((__aligned__(8)));\n-----------------------------------------------------------------------\nThis is the per-node structure that buffers whole sheaves so they can migrate\nbetween CPUs without going all the way back to the page allocator.\n- spinlock_t lock, this serializes all barn operations. Note the difference from\nthe per-CPU layer: the fast paths use a local_trylock on slub_pe"
}
],
"providerMetadata": {
"dateUpdated": "2026-11-02T07:29:55Z",
"orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"shortName": "VULNARCHIVE"
},
"references": [
{
"tags": [
"technical-description",
"exploit"
],
"url": "https://vuln.freearchive.org/archive/item/3ad1831ab5402636fb89a2bb7b03de634ea027b1d68aacc98f82391180bfe31c"
},
{
"tags": [
"technical-description"
],
"url": "https://lists.securityfocus.com/hyperkitty/list/bugtraq@bugtraq.ai/message/T7TSXPUPYTOBSA6XTX2FFKLQIA4LKTB2/"
},
{
"url": "https://a13xp0p0v.github.io"
},
{
"url": "https://duasynt.com/blog/linux-kernel-heap-feng-shui-2022"
},
{
"url": "https://fosdem.org/2026/schedule/event/DPXVYJ-slub-sheaves-update/"
},
{
"url": "https://git.kernel.org/pub/scm/linux/kernel/git/vbabka"
},
{
"url": "https://github.com/0xCyberstan/CVE-2026-46215-POC"
},
{
"url": "https://github.com/a13xp0p0v/kernel-hack-drill"
},
{
"url": "https://github.com/a13xp0p0v/kernel-hardening-checker"
},
{
"url": "https://github.com/a13xp0p0v/linux-kernel-defence-map"
},
{
"url": "https://github.com/bata24/gef"
},
{
"url": "https://github.com/bluedragonsecurity/sheaf_uaf"
},
{
"url": "https://github.com/khoatran107/sheaf-barn-exploit"
},
{
"url": "https://github.com/markakd/dirtycred"
},
{
"url": "https://github.com/notselwyn/cve-2024-1086"
},
{
"url": "https://github.com/r1ru/linux-kernel-exploitation"
},
{
"url": "https://github.com/torvalds/linux/tree/v7.0"
},
{
"url": "https://github.com/torvalds/linux/tree/v7.0-rc1"
},
{
"url": "https://github.com/xairy/linux-kernel-exploitation"
},
{
"url": "https://grsecurity.net/blog"
},
{
"url": "https://i.blackhat.com/Asia-22/Thursday-Materials/"
},
{
"url": "https://kaist-hacking.github.io/publication/kim-crossx/"
},
{
"url": "https://kaist-hacking.github.io/pubs/2025/kim:crossx.pdf"
},
{
"url": "https://kuzey.rs/posts/Dirty_Page_Table/"
},
{
"url": "https://lkml.org/lkml/2025/9/15/1382"
},
{
"url": "https://lkml.org/lkml/2026/1/23/382"
},
{
"url": "https://lkml.org/lkml/2026/1/26/396"
},
{
"url": "https://lwn.net/Articles/1010667/"
},
{
"url": "https://phrack.org/issues/71/13_md#article"
},
{
"url": "https://pwning.tech/nftables"
},
{
"url": "https://www.usenix.org/system/files/usenixsecurity24-maar-slubstick.pdf"
},
{
"url": "https://www.willsroot.io/2022/12/entrybleed.html"
},
{
"url": "https://www.youtube.com/watch?v=2hYzxsWeNcE"
},
{
"url": "https://www.youtube.com/watch?v=KuUHyAS0Aag"
},
{
"url": "https://yanglingxi1993.github.io/dirty_pagetable/dirty_pagetable.html"
}
],
"source": {
"defect": [
"179154745486.218337.5502349952768722791%40ns3482404.ip-193-70-32.eu"
],
"discovery": "EXTERNAL"
},
"title": "[Bugtraq] UAF Exploitation in the Sheaves Era",
"x_gcve": [
{
"recordType": "analysis",
"relationships": [
{
"destId": "CVE-2022-4543",
"type": "related"
},
{
"destId": "CVE-2024-1086",
"type": "related"
},
{
"destId": "CVE-2026-46215",
"type": "related"
}
],
"vulnId": "GCVE-1988-2026-0450",
"x_vulnarchive": {
"archiveUrl": "https://vuln.freearchive.org/archive/item/3ad1831ab5402636fb89a2bb7b03de634ea027b1d68aacc98f82391180bfe31c",
"automated": true,
"contentSha256": "3ad1831ab5402636fb89a2bb7b03de634ea027b1d68aacc98f82391180bfe31c",
"evidenceScore": 9,
"messageId": "179154745486.218337.5502349952768722791%40ns3482404.ip-193-70-32.eu",
"originalUrl": "https://lists.securityfocus.com/hyperkitty/list/bugtraq@bugtraq.ai/message/T7TSXPUPYTOBSA6XTX2FFKLQIA4LKTB2/",
"policy": "vulnarchive-1",
"sourceFormat": "text/html",
"sourcePublishedAt": "2026-11-02T07:29:55Z"
}
},
{
"recordType": "advisory",
"vulnId": "gcve-1988-2026-0450"
}
]
}
},
"cveMetadata": {
"assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"assignerShortName": "VULNARCHIVE",
"datePublished": "2026-11-02T07:29:55Z",
"dateUpdated": "2026-11-02T07:29:55Z",
"state": "PUBLISHED",
"vulnId": "GCVE-1988-2026-0450"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
Loading…
Loading…
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
Loading…
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Loading…
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.