CVSS 3.1
Вероятност да бъде експлоатирана в следващите 30 дни (EPSS)
Атакува се
Време до експлоатация
Атакува се по мрежата, без особени условия, без вход и без действие от потребителя.
- Експлоатация: няма данни за експлоатация
- Атаката може да се автоматизира
Описание
Оригинално описание
In the Linux kernel, the following vulnerability has been resolved: mm/slab: prevent unbounded recursion in free path with new kmalloc type Commit 280ea9c3154b ("mm/slab: avoid allocating slabobj_ext array from its own slab") avoided recursive allocation of obj_exts from kmalloc caches of the same size, by bumping the obj_exts array's allocation size whenever the array size equals the size of the object being allocated. However, as reported by Danielle Costantino and Shakeel Butt, even slabs from kmalloc caches of different sizes can form a cycle by allocating obj_exts arrays from each other [1]: What happened: a KMALLOC_NORMAL slab's obj_exts array (used by allocation profiling / memcg accounting) is itself kmalloc()'d from a KMALLOC_NORMAL cache, so the "slab holds another slab's obj_exts array" relation can form cycles. With sizeof(struct slabobj_ext) == 16 and the host's geometry: - kmalloc-512 has 64 objects/slab -> array is 64*16 == 1024 bytes, served from kmalloc-1k; - kmalloc-1k has 32 objects/slab -> array is 32*16 == 512 bytes, served from kmalloc-512. A kmalloc-512 slab and a kmalloc-1k slab therefore hold each other's obj_exts array. Discarding one frees the other's array, which empties and discards that slab, which frees the first's array, and so on: __free_slab() -> free_slab_obj_exts() -> kfree() -> discard_slab() -> __free_slab() recurses along the cycle until the stack is exhausted. With memory allocation profiling, this allows unbounded recursion in the free path and led to a stack overflow on a production host in the Meta fleet [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 ) ... <kernel driver freeing a resource> do_syscall_64 It is proposed [1] to resolve this issue by always serving the obj_exts array allocation from kmalloc caches (or large kmalloc) of
Засегнати продукти
- Linux Linux: 4b8736964640fe160724e7135dc62883bddcdace преди 3e71bfbdd3fd81ee9fefd867fdb2be62bade4140; 4b8736964640fe160724e7135dc62883bddcdace преди d01e88d421a6d07f35235600a43fbd0e551cf292; 4b8736964640fe160724e7135dc62883bddcdace преди ebefca49e4c69df24ba9307bfe0806230301d5c6; 4b8736964640fe160724e7135dc62883bddcdace преди d9e6a7623938968e3752b67e37eaff097e559a54
- Linux Linux: 6.10; преди 6.10; 6.12.103 до 6.12.*; 6.18.44 до 6.18.*; 7.1.8 до 7.1.*; от 7.2 нататък
История
- 15 август 2026 Публикувано
Други уязвимости в Linux Linux
Първоизточници
- https://www.cve.org/CVERecord?id=CVE-2026-74576
- https://nvd.nist.gov/vuln/detail/CVE-2026-74576
- https://git.kernel.org/stable/c/3e71bfbdd3fd81ee9fefd867fdb2be62bade4140
- https://git.kernel.org/stable/c/d01e88d421a6d07f35235600a43fbd0e551cf292
- https://git.kernel.org/stable/c/ebefca49e4c69df24ba9307bfe0806230301d5c6
- https://git.kernel.org/stable/c/d9e6a7623938968e3752b67e37eaff097e559a54