Skip to content
KitploitKITPLOIT
ToolsBlog
Einreichen
ToolsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

··Feeds·Kontakt·Datenschutz·© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
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 | Kitploit
Tools/GitHubGitHub/bluedragonsecurity/cve-2026-31429-poc
SchwachstellenanalyseExploitationLernen & BildungBinary-Exploitation
GitHubbluedragonsecurity/cve-2026-31429-poc

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

Repository anzeigen
1vor 4 MonatenNoch nicht geprüft

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Teilen

CVE-2026-31429 — Linux-Kernel: Cross-Cache-Free von KFENCE-allokiertem SKB-Head über bpf_prog_test_run_skb

Schweregrad: 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/


Mögliche Sicherheitsauswirkungen

  • Umgehung von Mitigations
  • Deaktivierung von LSM
  • Kernel-Rootkit-Implantate
  • Container-Ausbruch
  • Denial of Service

Überblick

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.


Betroffene Versionen

StatusBereich
BetroffenLinux >= 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.


Root-Cause-Analyse

Hintergrund: Designabsicht von skb_small_head_cache

SKB_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:

root@kitploit:~
// 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()
  • andernfalls → generisches 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.

Die KFENCE-Ausnahme

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.

Verwundbare Aufrufkette

root@kitploit:~
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

Warum skb_end_offset = 384?

Auf x86_64:

root@kitploit:~
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 Fix

Der Upstream-Fix von Jiayuan Chen (reviewed von Eric Dumazet, gemerged von Jakub Kicinski) eliminiert die Heuristik vollständig:

root@kitploit:~
// 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.


dmesg-Ausgabe (Reproduktionsnachweis)

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:

root@kitploit:~
[ 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:

  1. warn_free_bad_obj — primäre Cross-Cache-Free-Erkennung (mm/slub.c:6258)
  2. depot_fetch_stack — Stack-Depot-Pool-Index außerhalb der Grenzen (lib/stackdepot.c:506) bei Allocated-Verfolgung
  3. stack_depot_print — korrupter Handle erkannt (lib/stackdepot.c:780)
  4. depot_fetch_stack + stack_depot_print — dasselbe Paar wiederholt für Freed-Verfolgung

Diese 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.


Reproducer

Voraussetzungen

root@kitploit:~
Kernel:  Linux >= 6.3, kompiliert mit:
           CONFIG_KFENCE=y
           CONFIG_BPF_SYSCALL=y
           CONFIG_NET_SCH_INGRESS=y  (oder ein beliebiger SCHED_CLS-fähiger Treiber)
           CONFIG_SLUB_DEBUG=y       (für warn_free_bad_obj-Sichtbarkeit)
           CONFIG_STACKDEPOT=y       (für die vollständige Kaskade)

Berechtigungen: root (uid=0) — erforderlich für BPF_PROG_LOAD

Build

root@kitploit:~
gcc -O2 -o cve-2026-31429-poc-only cve-2026-31429-poc-only.c

Ausführen

root@kitploit:~
sudo ./cve-2026-31429-poc-only
root@kitploit:~
dmesg | grep -E "warn_free_bad_obj|Wrong slab cache|cross-cache"

Auslösemechanismus

Der PoC lädt ein minimales BPF-Programm mit 3 Instruktionen (Typ BPF_PROG_TYPE_SCHED_CLS):

root@kitploit:~
ld_imm64 r0, 0    ; 2 Insns (wide)
exit              ; 1 Insn

Anschließend ruft er BPF_PROG_TEST_RUN (cmd=10) auf mit:

  • data_size_in = 284 Bytes von Syzkaller-abgeleiteten Paketdaten
  • flags = BPF_F_TEST_RUN_ON_CPU (0x4) — pinnt die Ausführung auf CPU 0
  • repeat = 4
  • Gefolgt von einer Schleife mit 50 zusätzlichen Aufrufen für Zuverlässigkeit

Die 284-Byte-Eingabedaten üben den Allokationspfad von bpf_test_init so aus, dass die angeforderte Puffergröße SKB_SMALL_HEAD_CACHE_SIZE entspricht und probabilistisch das KFENCE-Interceptionsfenster trifft.


Fix-Commits

CommitTreeGemerged vonDatum
0f42e3f4fe2amainlineJakub Kicinski2026-04-06
60313768a8edlinux-stableGreg Kroah-Hartman2026-04-18
2d64618ea846linux-stableGreg Kroah-Hartman2026-04-18
474e00b935dblinux-stableGreg Kroah-Hartman2026-04-18

Signed-off-Kette: Jiayuan Chen → Reviewed-by Eric Dumazet (Google) → Jakub Kicinski → Greg Kroah-Hartman
Reported-by-Credit: Antonius <[email protected]> in allen 4 Commits
Eingeführt durch: bf9f1baa279f („net: add dedicated kmem_cache for typical/small skb->head")


Referenzen

  • NVD / CVE-Eintrag: https://www.cve.org/CVERecord?id=CVE-2026-31429
  • Upstream-Patch (Mainline): https://git.kernel.org/stable/c/0f42e3f4fe2a58394e37241d02d9ca6ab7b7d516
  • Stable 6.12.x: https://git.kernel.org/stable/c/60313768a8edc7094435975587c00c2d7b834083
  • Stable 6.18.x: https://git.kernel.org/stable/c/2d64618ea846d8d033477311f805ca487d6a6696
  • Stable 6.19.x: https://git.kernel.org/stable/c/474e00b935db250cac320d10c1d3cf4e44b46721
  • Lore-Bericht: https://lore.kernel.org/netdev/CAK8a0jxC5L5N7hq-DT2_NhUyjBxrPocoiDazzsBk4TGgT1r4-A@mail.gmail.com/
  • Blue Dragon Security: https://bluedragonsec.com

Repository-Inhalt

root@kitploit:~
.
├── README.md         		    — diese Datei
├── cve-2026-31429-poc-only.c       — nur Proof-of-Concept (kein Exploit)
└── dmesg.txt                       — roher Kernel-Splat aus erfolgreicher Reproduktion

Offenlegungszeitplan

DatumEreignis
~Anfang 2026Fehler durch Syzkaller-Fuzzing auf Linux 7.0-rc5 entdeckt
2026-04-03Patch von Jiayuan Chen verfasst, Reported-by-Credit an Antonius
2026-04-06Mainline-Commit 0f42e3f4fe2a von Jakub Kicinski gemerged
2026-04-18Stable-Backports von Greg Kroah-Hartman gemerged (6.12.x, 6.18.x, 6.19.x)
2026-04-20CVE-2026-31429 veröffentlicht

Autor

Antonius (Spitzname: w1sdom)
Gründer & Senior-Forscher — Blue Dragon Security
Indonesien
[email protected]


Rechtliches

Dieser PoC wird für Bildungs- und Forschungszwecke veröffentlicht, nachdem der Upstream-Patch verfügbar war. Verwenden Sie ihn nicht auf Systemen, die Sie nicht besitzen oder für die Sie keine ausdrückliche Testberechtigung haben. Der Autor übernimmt keine Verantwortung für Missbrauch.

Tool herunterladen