bluedragonsecurity/cve-2026-31429-poc# POC für CVE-2026-31429 (Linux Kernel >= 6.3 < 6.12.82 Slab Cross-Cache Confusion) – Schwachstelle entdeckt von Antonius – w1sdom – bluedragonsec.com
bpf_prog_test_run_skbSchweregrad: Mittel (CWE-763: Freigabe eines ungültigen Zeigers oder einer ungültigen Referenz)
Veröffentlicht: 2026-04-20
Betroffenes Subsystem: net/core/skbuff.c — skb_kfree_head()
Forscher: Antonius / w1sdom — Blue Dragon Security
Kontakt: [email protected]
Lore-Thread: https://lore.kernel.org/netdev/CAK8a0jxC5L5N7hq-DT2_NhUyjBxrPocoiDazzsBk4TGgT1r4-A@mail.gmail.com/
Dieses Repository enthält den Proof-of-Concept für CVE-2026-31429 (kein funktionierender Exploit, nur ein POC), einen Slab-Cross-Cache-Konfusionsfehler im Netzwerk-Stack des Linux-Kernels. Der Fehler wird ausgelöst, wenn KFENCE aktiviert ist und ein Aufrufer (insbesondere bpf_test_init in net/bpf/test_run.c) einen SKB-Head-Puffer über kzalloc() mit einer Größe allokiert, die zufällig SKB_SMALL_HEAD_CACHE_SIZE entspricht. Aufgrund der exakten Größenmelde-Semantik von KFENCE gibt die Kernel-Funktion skb_kfree_head() das Objekt fälschlicherweise an den skb_small_head_cache zurück, anstatt an den ursprünglichen kmalloc-1k-Cache, wodurch die Slab-Metadaten beschädigt werden.
| Status | Bereich |
|---|---|
| Betroffen | Linux >= 6.3 (eingeführt durch bf9f1baa279f) |
| Nicht betroffen | < 6.3 |
| Behoben | >= 6.12.82 |
| Behoben | >= 6.18.23 |
| Behoben | >= 6.19.13 |
| Behoben | >= 7.0 (Mainline, Commit 0f42e3f4fe2a) |
Die Schwachstelle wurde durch Commit bf9f1baa279f („net: add dedicated kmem_cache for typical/small skb->head") eingeführt, der skb_small_head_cache und die bedingte Freigabelogik in skb_kfree_head() hinzufügte.
skb_small_head_cacheSKB_SMALL_HEAD_CACHE_SIZE ist absichtlich auf einen Nicht-Zweierpotenz-Wert gesetzt (z. B. 704 Bytes auf x86_64), um Kollisionen mit den generischen kmalloc-Bucket-Größen (immer Zweierpotenzen: 512, 1024, ...) zu vermeiden. Die Heuristik in skb_kfree_head() nutzt diese Eindeutigkeit, um Freigaben nur anhand von skb_end_offset zu leiten:
// net/core/skbuff.c (VERWUNDBAR — vor dem Fix)
static void skb_kfree_head(void *head, unsigned int end_offset)
{
if (end_offset == SKB_SMALL_HEAD_HEADROOM)
kmem_cache_free(net_hotdata.skb_small_head_cache, head);
else
kfree(head);
}
end_offset == SKB_SMALL_HEAD_HEADROOM → angenommen aus skb_small_head_cache → kmem_cache_free()kfree()Diese Heuristik ist nur unter normaler Slab-Semantik korrekt, bei der ksize() die Bucket-Größe zurückgibt (1024 für eine 704-Byte-Anfrage), die niemals gleich SKB_SMALL_HEAD_CACHE_SIZE ist.
KFENCE (Kernel Electric-Fence) fängt eine Teilmenge der Kernel-Allokationen ab und bedient sie aus Guard-Page-Speicher. Sein kritischer Verhaltensunterschied: kfence_ksize() gibt die exakt angeforderte Größe zurück, nicht die Slab-Bucket-Größe.
BPF_PROG_TEST_RUN (Syscall 321, cmd BPF_PROG_TEST_RUN=10)
└─> __sys_bpf()
└─> bpf_prog_test_run_skb()
└─> bpf_test_init()
└─> kzalloc(size, GFP_USER)
│ size == SKB_SMALL_HEAD_CACHE_SIZE (704 auf x86_64)
│ KFENCE fängt ab → Objekt aus kmalloc-1k-Bereich bedient
│
└─> slab_build_skb(data, NULL, size)
└─> ksize(data)
└─> kfence_ksize() ← gibt 704 zurück (exakt!)
└─> skb_end_offset
= ksize(data) - sizeof(skb_shared_info)
= 704 - 320
= 384
= SKB_SMALL_HEAD_HEADROOM ← falsche Übereinstimmung!
[Auf dem SKB-Freigabepfad:]
└─> sk_skb_reason_drop()
└─> skb_release_data()
└─> skb_free_head()
└─> skb_kfree_head(head, skb->end)
└─> (end_offset == SKB_SMALL_HEAD_HEADROOM) == TRUE
└─> kmem_cache_free(skb_small_head_cache, head)
↑ FEHLER: head stammt aus kmalloc-1k, nicht aus skb_small_head_cache!
→ warn_free_bad_obj() → SLUB-Korruption
skb_end_offset = 384?Auf x86_64:
SKB_SMALL_HEAD_CACHE_SIZE = 704 Bytes
sizeof(skb_shared_info) = 320 Bytes
SKB_SMALL_HEAD_HEADROOM = 704 - 320 = 384
Wenn KFENCE die 704-Byte-kzalloc()-Allokation abfängt, gibt kfence_ksize() exakt 704 zurück. Die Arithmetik erzeugt skb_end_offset = 384 = SKB_SMALL_HEAD_HEADROOM, wodurch die Bedingung in skb_kfree_head() erfüllt wird — was den falschen Freigabepfad auslöst.
Der Upstream-Fix von Jiayuan Chen (reviewed von Eric Dumazet, gemerged von Jakub Kicinski) eliminiert die Heuristik vollständig:
// net/core/skbuff.c (BEHOBEN)
static void skb_kfree_head(void *head, unsigned int end_offset)
{
kfree(head); // immer generisch; funktioniert für beide Fälle
}
kfree() ist sowohl für kmalloc-allokierten als auch für skb_small_head_cache-allokierten Speicher sicher, da kmem_cache_free() auf skb_small_head_cache nicht mehr notwendig ist — das generische kfree() löst den korrekten Cache intern über den kmem_cache-Zeiger der Slab-Seite auf.
Der Reproducer (repro_bpf.c) wurde auf Linux 7.0.0-rc5 in einer QEMU-Umgebung (i440FX, BIOS 1.17.0-debian) ausgeführt. Die folgende Kernel-WARNING-Kaskade wurde beobachtet:
[ 3065.322973] ------------[ cut here ]------------
[ 3065.322990] kmem_cache_free(skbuff_small_head, ffff888186d6e000): object belongs to different cache kmalloc-1k
[ 3065.323005] WARNING: mm/slub.c:6258 at warn_free_bad_obj+0x91/0xc0, CPU#0: repro_bpf/2167
[ 3065.323061] CPU: 0 UID: 0 PID: 2167 Comm: repro_bpf Not tainted 7.0.0-rc5 #1 PREEMPT(lazy)
[ 3065.323098] RIP: 0010:warn_free_bad_obj+0x98/0xc0
...
[ 3065.323231] Call Trace:
[ 3065.323247] skb_free_head+0x1ec/0x290
[ 3065.323267] skb_release_data+0x7a6/0x9d0
[ 3065.323308] bpf_prog_test_run_skb+0x14f8/0x3410
[ 3065.323510] __sys_bpf+0x769/0x4b60
[ 3065.323763] __x64_sys_bpf+0x78/0xc0
[ 3065.323794] do_syscall_64+0x111/0x690
[ 3065.323813] entry_SYSCALL_64_after_hwframe+0x77/0x7f
Die WARNING-Kaskade erzeugt 4 separate Splats pro Auslösung:
warn_free_bad_obj — primäre Cross-Cache-Free-Erkennung (mm/slub.c:6258)depot_fetch_stack — Stack-Depot-Pool-Index außerhalb der Grenzen (lib/stackdepot.c:506) bei Allocated-Verfolgungstack_depot_print — korrupter Handle erkannt (lib/stackdepot.c:780)depot_fetch_stack + stack_depot_print — dasselbe Paar wiederholt für Freed-VerfolgungDiese Kaskade zeigt, dass die SLUB-Verfolgungsmetadaten des Objekts (alloc_track / free_track) auf einen Stack-Depot-Handle verweisen, der nach der falschen Cache-Freigabe korrupt wird.