CVE-2026-74576: mm/slab: prevent unbounded recursion in free path with new kmalloc type

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 slabobjext array from its own slab") avoided recursive allocation of objexts from kmalloc caches of the same size, by bumping the objexts 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 objexts arrays from each other [1]:

What happened: a KMALLOCNORMAL slab's objexts array (used by allocation profiling / memcg accounting) is itself kmalloc()'d from a KMALLOCNORMAL cache, so the "slab holds another slab's objexts array" relation can form cycles. With sizeof(struct slabobjext) == 16 and the host's geometry:

- kmalloc-512 has 64 objects/slab -> array is 6416 == 1024 bytes, served from kmalloc-1k; - kmalloc-1k has 32 objects/slab -> array is 3216 == 512 bytes, served from kmalloc-512.

A kmalloc-512 slab and a kmalloc-1k slab therefore hold each other's objexts array. Discarding one frees the other's array, which empties and discards that slab, which frees the first's array, and so on: freeslab() -> freeslabobjexts() -> kfree() -> discardslab() -> freeslab() 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: freeslab+0x66/0xc0 kfree+0x3f0/0x5d0 ... ( ~125x freeslab <-> kfree ) ... <kernel driver freeing a resource> dosyscall64

It is proposed [1] to resolve this issue by always serving the objexts 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 objexts 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 objexts arrays. Currently, all objexts arrays are served from normal kmalloc caches. Cycles cannot be created if objexts arrays of normal kmalloc caches are served from a special kmalloc type that can never have objexts arrays.

To achieve this, create a new kmalloc type called KMALLOCNOOBJEXT. KMALLOCNOOBJEXT caches are created with SLABNOOBJEXT flag when either 1) memory allocation profiling is not permanently disabled, or 2) kmalloc types with a priority higher than KMALLOCCGROUP are aliased with KMALLOCNORMAL.

Sheaf bootstrapping for KMALLOCNOOBJEXT caches now must be deferred because allocation of a barn can trigger objexts array allocation of normal kmalloc caches when the KMALLOCNOOBJEXT 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, SLABALLOCNOOBJEXT, to prevent allocation of objexts arrays, and let kmallocslab() override the type to KMALLOCNOOBJEXT when specified. Note that kmalloctype() remains unchanged because kmallocflags() bypasses the kmalloc fastpath.

Do not pass SLABALLOCNORECURSE to kmallocflags() in allocslabobjexts() and instead use SLABALLOCNOOBJEXT only when the objects are allocated from normal kmalloc caches. While this prevents unbounded recursive allocation of objexts, it allows KMALLOCNOOBJEXT caches to have sheaves.

Since sheaf allocations specify SLABALLOCNORECURSE that prevents allocation of both sheaves and objexts arrays, the recursion depth is bounded.

objexts arrays for non- ---truncated---