Description

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 sizes larger than the object size. However, as pointed out by Vlastimil Babka [2], this can waste an excessive amount of memory as slabs from large kmalloc sizes (e.g. kmalloc-8k) generally need obj_exts arrays much smaller than the object size. Therefore, rather than bumping the size, let us take a different approach; disallow formation of cycles between kmalloc types when allocating obj_exts arrays. Currently, all obj_exts arrays are served from normal kmalloc caches. Cycles cannot be created if obj_exts arrays of normal kmalloc caches are served from a special kmalloc type that can never have obj_exts arrays. To achieve this, create a new kmalloc type called KMALLOC_NO_OBJ_EXT. KMALLOC_NO_OBJ_EXT caches are created with SLAB_NO_OBJ_EXT flag when either 1) memory allocation profiling is not permanently disabled, or 2) kmalloc types with a priority higher than KMALLOC_CGROUP are aliased with KMALLOC_NORMAL. Sheaf bootstrapping for KMALLOC_NO_OBJ_EXT caches now must be deferred because allocation of a barn can trigger obj_exts array allocation of normal kmalloc caches when the KMALLOC_NO_OBJ_EXT cache for that size is not ready yet. For simplicity, perform bootstrapping of sheaves for all kmalloc caches later. Introduce a new slab alloc flag, SLAB_ALLOC_NO_OBJ_EXT, to prevent allocation of obj_exts arrays, and let kmalloc_slab() override the type to KMALLOC_NO_OBJ_EXT when specified. Note that kmalloc_type() remains unchanged because kmalloc_flags() bypasses the kmalloc fastpath. Do not pass SLAB_ALLOC_NO_RECURSE to kmalloc_flags() in alloc_slab_obj_exts() and instead use SLAB_ALLOC_NO_OBJ_EXT only when the objects are allocated from normal kmalloc caches. While this prevents unbounded recursive allocation of obj_exts, it allows KMALLOC_NO_OBJ_EXT caches to have sheaves. Since sheaf allocations specify SLAB_ALLOC_NO_RECURSE that prevents allocation of both sheaves and obj_exts arrays, the recursion depth is bounded. obj_exts arrays for non- ---truncated---

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-08-15T13:18:03.290Z",
  "pubdate": "2026-08-15T13:18:03.290Z",
  "executiveSummary": "A vulnerability exists in the Linux kernel memory management subsystem, specifically within mm/slab, involving the handling of slab object extensions (obj_exts) used for allocation profiling and memory control group accounting. The vulnerability type is unbounded recursion leading to stack exhaustion and subsequent kernel panic.\nThe impact of this vulnerability is a denial of service (DoS) via kernel stack overflow, which can be triggered on production systems under normal operating conditions when specific memory allocation profiling features are active.\nThe affected system is the Linux kernel mm/slab subsystem using kmalloc caches and memory allocation profiling. The risk implications are high for production fleets as it results in unrecoverable system crashes (Task stack guard page hit).\nAttacker capabilities and exploitation requirements do not necessarily involve malicious intent or external network exposure; the cycle formation can occur organically through normal kernel heap allocations of differing kmalloc sizes (e.g., kmalloc-512 and kmalloc-1k) holding each other's obj_exts arrays, although local execution or workloads triggering slab creation and destruction paths are required to drive the recursion.",
  "technicalDetails": "The root cause of the vulnerability lies in circular dependencies formed during the allocation of slab object extension arrays (obj_exts) across different kmalloc cache sizes. Commit 280ea9c3154b previously attempted to prevent recursive allocation from caches of the same size by bumping the allocation size when equal. However, slabs from different kmalloc caches can still form cyclical relationships.\nSpecifically, a KMALLOC_NORMAL slab's obj_exts array can be allocated from a different KMALLOC_NORMAL cache. For instance, kmalloc-512 serves a 1024-byte array for kmalloc-1k (which has 64 objects/slab yielding a 64*16 array), while kmalloc-1k serves a 512-byte array for kmalloc-512 (32 objects/slab yielding a 32*16 array).\nThe attack flow and exploitation mechanism occur during the slab freeing path. When a resource is freed, __free_slab() invokes free_slab_obj_exts(), which calls kfree() on the dependent slab's obj_exts array. This triggers discard_slab(), leading to another invocation of __free_slab(). Because of the bidirectional or multi-node cycle between the kmalloc caches, this sequence recurses infinitely (__free_slab() <-> kfree()) until the kernel stack is completely exhausted.\nThe vulnerable component is the mm/slab subsystem and its interaction with allocation profiling and memory cgroup accounting via obj_exts arrays. The failure manifests as a kernel panic hitting the TASK stack guard page, resulting in an Oops with RIP pointing to kfree+0x8/0x5d0 and deep call traces of alternating __free_slab and kfree calls.\nPrivilege and authentication requirements are inherent to kernel execution paths, typically triggered by kernel drivers or system operations freeing resources. There is no direct network exposure required, as the vulnerability is triggered via local kernel memory management operations."
}