CVE-2026-74576 in Linux
Zusammenfassung
von VulDB • 15.08.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
mm/slab: Verhinderung ungebundener Rekursion im Freigabepfad bei neuem kmalloc-Typ
Der Commit 280ea9c3154b („mm/slab: vermeiden der rekursiven Allokation von slabobj_ext-Arrays aus Slabs derselben Größe“) verhinderte die rekursive Allokation von obj_exts aus kmalloc-Caches gleicher Größe, indem er die Allokationsgröße des obj_exts-Arrays erhöhte, sobald die Array-Größe gleich der Größe des zu allokierenden Objekts war.
Wie jedoch Danielle Costantino und Shakeel Butt berichteten, können selbst Slabs aus kmalloc-Caches unterschiedlicher Größen einen Zyklus bilden, indem sie obj_exts-Arrays voneinander allokieren [1]:
Was geschah: Das obj_exts-Array eines KMALLOC_NORMAL-Slabs (verwendet für Allokationsprofilierung / memcg-Buchhaltung) wird selbst über kmalloc() aus einem KMALLOC_NORMAL-Cache allokiert, sodass die Beziehung „Slab hält das obj_exts-Array eines anderen Slabs“ Zyklen bilden kann. Bei sizeof(struct slabobj_ext) == 16 und der Geometrie des Hosts:
- kmalloc-512 hat 64 Objekte/Slab -> Array ist 64*16 == 1024 Bytes, bereitgestellt von kmalloc-1k; - kmalloc-1k hat 32 Objekte/Slab -> Array ist 32*16 == 512 Bytes, bereitgestellt von kmalloc-512.
Ein kmalloc-512-Slab und ein kmalloc-1k-Slab halten daher jeweils das obj_exts-Array des anderen. Das Verwerfen eines Slabs gibt das Array des anderen frei, was diesen leert und verwirft, welches wiederum das Array des ersten freigibt, und so weiter: __free_slab() -> free_slab_obj_exts() -> kfree() -> discard_slab() -> __free_slab() rekuriert entlang des Zyklus, bis der Stack erschöpft ist.
Mit Allokationsprofilierung ermöglicht dies ungebundene Rekursion im Freigabepfad und führte auf einem Produktionshost in der Meta-Flotte zu einem Stack Overflow [1]:
BUG: TASK stack guard page was hit Oops: stack guard page RIP: 0010:kfree+0x8/0x5d0 Call Trace: __free_slab+0x66/0xc0 kfree+0x3f0/0x5d0 ... (~125x __free_slab kfree ) ...
do_syscall_64
Es wird vorgeschlagen [1], dieses Problem dadurch zu lösen, dass die Allok
If you want to get best quality of vulnerability data, you may have to visit VulDB.