{"api_version":"1","generated_at":"2026-08-15T15:12:43+00:00","cve":"CVE-2026-74576","urls":{"html":"https://cve.report/CVE-2026-74576","api":"https://cve.report/api/cve/CVE-2026-74576.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-74576","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-74576"},"summary":{"title":"mm/slab: prevent unbounded recursion in free path with new kmalloc type","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nmm/slab: prevent unbounded recursion in free path with new kmalloc type\n\nCommit 280ea9c3154b (\"mm/slab: avoid allocating slabobj_ext array from\nits own slab\") avoided recursive allocation of obj_exts from kmalloc\ncaches of the same size, by bumping the obj_exts array's allocation\nsize whenever the array size equals the size of the object being\nallocated.\n\nHowever, as reported by Danielle Costantino and Shakeel Butt,\neven slabs from kmalloc caches of different sizes can form a cycle\nby allocating obj_exts arrays from each other [1]:\n\n  What happened: a KMALLOC_NORMAL slab's obj_exts array (used by\n  allocation profiling / memcg accounting) is itself kmalloc()'d from a\n  KMALLOC_NORMAL cache, so the \"slab holds another slab's obj_exts array\"\n  relation can form cycles. With sizeof(struct slabobj_ext) == 16 and\n  the host's geometry:\n\n  - kmalloc-512 has 64 objects/slab -> array is 64*16 == 1024 bytes,\n    served from kmalloc-1k;\n  - kmalloc-1k  has 32 objects/slab -> array is 32*16 ==  512 bytes,\n    served from kmalloc-512.\n\n  A kmalloc-512 slab and a kmalloc-1k slab therefore hold each other's\n  obj_exts array.  Discarding one frees the other's array, which empties\n  and discards that slab, which frees the first's array, and so on:\n  __free_slab() -> free_slab_obj_exts() -> kfree() -> discard_slab() ->\n  __free_slab() recurses along the cycle until the stack is exhausted.\n\nWith memory allocation profiling, this allows unbounded recursion\nin the free path and led to a stack overflow on a production host in\nthe Meta fleet [1]:\n\n  BUG: TASK stack guard page was hit\n  Oops: stack guard page\n  RIP: 0010:kfree+0x8/0x5d0\n  Call Trace:\n   __free_slab+0x66/0xc0\n   kfree+0x3f0/0x5d0\n   ... ( ~125x __free_slab <-> kfree ) ...\n   <kernel driver freeing a resource>\n   do_syscall_64\n\nIt is proposed [1] to resolve this issue by always serving the obj_exts\narray allocation from kmalloc caches (or large kmalloc) of sizes larger\nthan the object size. However, as pointed out by Vlastimil Babka [2],\nthis can waste an excessive amount of memory as slabs from large\nkmalloc sizes (e.g. kmalloc-8k) generally need obj_exts arrays much\nsmaller than the object size.\n\nTherefore, rather than bumping the size, let us take a different\napproach; disallow formation of cycles between kmalloc types when\nallocating obj_exts arrays. Currently, all obj_exts arrays are served\nfrom normal kmalloc caches. Cycles cannot be created if obj_exts arrays\nof normal kmalloc caches are served from a special kmalloc type that can\nnever have obj_exts arrays.\n\nTo achieve this, create a new kmalloc type called KMALLOC_NO_OBJ_EXT.\nKMALLOC_NO_OBJ_EXT caches are created with SLAB_NO_OBJ_EXT flag when\neither 1) memory allocation profiling is not permanently disabled,\nor 2) kmalloc types with a priority higher than KMALLOC_CGROUP are\naliased with KMALLOC_NORMAL.\n\nSheaf bootstrapping for KMALLOC_NO_OBJ_EXT caches now must be deferred\nbecause allocation of a barn can trigger obj_exts array allocation of\nnormal kmalloc caches when the KMALLOC_NO_OBJ_EXT cache for that size\nis not ready yet. For simplicity, perform bootstrapping of sheaves for\nall kmalloc caches later.\n\nIntroduce a new slab alloc flag, SLAB_ALLOC_NO_OBJ_EXT, to prevent\nallocation of obj_exts arrays, and let kmalloc_slab() override the type\nto KMALLOC_NO_OBJ_EXT when specified. Note that kmalloc_type() remains\nunchanged because kmalloc_flags() bypasses the kmalloc fastpath.\n\nDo not pass SLAB_ALLOC_NO_RECURSE to kmalloc_flags() in\nalloc_slab_obj_exts() and instead use SLAB_ALLOC_NO_OBJ_EXT only when\nthe objects are allocated from normal kmalloc caches. While this\nprevents unbounded recursive allocation of obj_exts, it allows\nKMALLOC_NO_OBJ_EXT caches to have sheaves.\n\nSince sheaf allocations specify SLAB_ALLOC_NO_RECURSE that prevents\nallocation of both sheaves and obj_exts arrays, the recursion depth\nis bounded.\n\nobj_exts arrays for non-\n---truncated---","state":"PUBLISHED","assigner":"Linux","published_at":"2026-08-15 13:18:03","updated_at":"2026-08-15 13:18:03"},"problem_types":[],"metrics":[],"references":[{"url":"https://git.kernel.org/stable/c/d9e6a7623938968e3752b67e37eaff097e559a54","name":"https://git.kernel.org/stable/c/d9e6a7623938968e3752b67e37eaff097e559a54","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/d01e88d421a6d07f35235600a43fbd0e551cf292","name":"https://git.kernel.org/stable/c/d01e88d421a6d07f35235600a43fbd0e551cf292","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/3e71bfbdd3fd81ee9fefd867fdb2be62bade4140","name":"https://git.kernel.org/stable/c/3e71bfbdd3fd81ee9fefd867fdb2be62bade4140","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/ebefca49e4c69df24ba9307bfe0806230301d5c6","name":"https://git.kernel.org/stable/c/ebefca49e4c69df24ba9307bfe0806230301d5c6","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-74576","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-74576","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 4b8736964640fe160724e7135dc62883bddcdace 3e71bfbdd3fd81ee9fefd867fdb2be62bade4140 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 4b8736964640fe160724e7135dc62883bddcdace d01e88d421a6d07f35235600a43fbd0e551cf292 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 4b8736964640fe160724e7135dc62883bddcdace ebefca49e4c69df24ba9307bfe0806230301d5c6 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 4b8736964640fe160724e7135dc62883bddcdace d9e6a7623938968e3752b67e37eaff097e559a54 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 6.10","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.10 semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.12.103 6.12.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.18.44 6.18.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.1.8 7.1.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.2-rc5 * original_commit_for_fix","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":null,"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"cna":{"affected":[{"defaultStatus":"unaffected","product":"Linux","programFiles":["include/linux/slab.h","mm/slab.h","mm/slab_common.c","mm/slub.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"lessThan":"3e71bfbdd3fd81ee9fefd867fdb2be62bade4140","status":"affected","version":"4b8736964640fe160724e7135dc62883bddcdace","versionType":"git"},{"lessThan":"d01e88d421a6d07f35235600a43fbd0e551cf292","status":"affected","version":"4b8736964640fe160724e7135dc62883bddcdace","versionType":"git"},{"lessThan":"ebefca49e4c69df24ba9307bfe0806230301d5c6","status":"affected","version":"4b8736964640fe160724e7135dc62883bddcdace","versionType":"git"},{"lessThan":"d9e6a7623938968e3752b67e37eaff097e559a54","status":"affected","version":"4b8736964640fe160724e7135dc62883bddcdace","versionType":"git"}]},{"defaultStatus":"affected","product":"Linux","programFiles":["include/linux/slab.h","mm/slab.h","mm/slab_common.c","mm/slub.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"status":"affected","version":"6.10"},{"lessThan":"6.10","status":"unaffected","version":"0","versionType":"semver"},{"lessThanOrEqual":"6.12.*","status":"unaffected","version":"6.12.103","versionType":"semver"},{"lessThanOrEqual":"6.18.*","status":"unaffected","version":"6.18.44","versionType":"semver"},{"lessThanOrEqual":"7.1.*","status":"unaffected","version":"7.1.8","versionType":"semver"},{"lessThanOrEqual":"*","status":"unaffected","version":"7.2-rc5","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"cpeMatch":[{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.12.103","versionStartIncluding":"6.10","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.18.44","versionStartIncluding":"6.10","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.1.8","versionStartIncluding":"6.10","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.2-rc5","versionStartIncluding":"6.10","vulnerable":true}],"negate":false,"operator":"OR"}]}],"descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\nmm/slab: prevent unbounded recursion in free path with new kmalloc type\n\nCommit 280ea9c3154b (\"mm/slab: avoid allocating slabobj_ext array from\nits own slab\") avoided recursive allocation of obj_exts from kmalloc\ncaches of the same size, by bumping the obj_exts array's allocation\nsize whenever the array size equals the size of the object being\nallocated.\n\nHowever, as reported by Danielle Costantino and Shakeel Butt,\neven slabs from kmalloc caches of different sizes can form a cycle\nby allocating obj_exts arrays from each other [1]:\n\n  What happened: a KMALLOC_NORMAL slab's obj_exts array (used by\n  allocation profiling / memcg accounting) is itself kmalloc()'d from a\n  KMALLOC_NORMAL cache, so the \"slab holds another slab's obj_exts array\"\n  relation can form cycles. With sizeof(struct slabobj_ext) == 16 and\n  the host's geometry:\n\n  - kmalloc-512 has 64 objects/slab -> array is 64*16 == 1024 bytes,\n    served from kmalloc-1k;\n  - kmalloc-1k  has 32 objects/slab -> array is 32*16 ==  512 bytes,\n    served from kmalloc-512.\n\n  A kmalloc-512 slab and a kmalloc-1k slab therefore hold each other's\n  obj_exts array.  Discarding one frees the other's array, which empties\n  and discards that slab, which frees the first's array, and so on:\n  __free_slab() -> free_slab_obj_exts() -> kfree() -> discard_slab() ->\n  __free_slab() recurses along the cycle until the stack is exhausted.\n\nWith memory allocation profiling, this allows unbounded recursion\nin the free path and led to a stack overflow on a production host in\nthe Meta fleet [1]:\n\n  BUG: TASK stack guard page was hit\n  Oops: stack guard page\n  RIP: 0010:kfree+0x8/0x5d0\n  Call Trace:\n   __free_slab+0x66/0xc0\n   kfree+0x3f0/0x5d0\n   ... ( ~125x __free_slab <-> kfree ) ...\n   <kernel driver freeing a resource>\n   do_syscall_64\n\nIt is proposed [1] to resolve this issue by always serving the obj_exts\narray allocation from kmalloc caches (or large kmalloc) of sizes larger\nthan the object size. However, as pointed out by Vlastimil Babka [2],\nthis can waste an excessive amount of memory as slabs from large\nkmalloc sizes (e.g. kmalloc-8k) generally need obj_exts arrays much\nsmaller than the object size.\n\nTherefore, rather than bumping the size, let us take a different\napproach; disallow formation of cycles between kmalloc types when\nallocating obj_exts arrays. Currently, all obj_exts arrays are served\nfrom normal kmalloc caches. Cycles cannot be created if obj_exts arrays\nof normal kmalloc caches are served from a special kmalloc type that can\nnever have obj_exts arrays.\n\nTo achieve this, create a new kmalloc type called KMALLOC_NO_OBJ_EXT.\nKMALLOC_NO_OBJ_EXT caches are created with SLAB_NO_OBJ_EXT flag when\neither 1) memory allocation profiling is not permanently disabled,\nor 2) kmalloc types with a priority higher than KMALLOC_CGROUP are\naliased with KMALLOC_NORMAL.\n\nSheaf bootstrapping for KMALLOC_NO_OBJ_EXT caches now must be deferred\nbecause allocation of a barn can trigger obj_exts array allocation of\nnormal kmalloc caches when the KMALLOC_NO_OBJ_EXT cache for that size\nis not ready yet. For simplicity, perform bootstrapping of sheaves for\nall kmalloc caches later.\n\nIntroduce a new slab alloc flag, SLAB_ALLOC_NO_OBJ_EXT, to prevent\nallocation of obj_exts arrays, and let kmalloc_slab() override the type\nto KMALLOC_NO_OBJ_EXT when specified. Note that kmalloc_type() remains\nunchanged because kmalloc_flags() bypasses the kmalloc fastpath.\n\nDo not pass SLAB_ALLOC_NO_RECURSE to kmalloc_flags() in\nalloc_slab_obj_exts() and instead use SLAB_ALLOC_NO_OBJ_EXT only when\nthe objects are allocated from normal kmalloc caches. While this\nprevents unbounded recursive allocation of obj_exts, it allows\nKMALLOC_NO_OBJ_EXT caches to have sheaves.\n\nSince sheaf allocations specify SLAB_ALLOC_NO_RECURSE that prevents\nallocation of both sheaves and obj_exts arrays, the recursion depth\nis bounded.\n\nobj_exts arrays for non-\n---truncated---"}],"providerMetadata":{"dateUpdated":"2026-08-15T12:28:13.798Z","orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux"},"references":[{"url":"https://git.kernel.org/stable/c/3e71bfbdd3fd81ee9fefd867fdb2be62bade4140"},{"url":"https://git.kernel.org/stable/c/d01e88d421a6d07f35235600a43fbd0e551cf292"},{"url":"https://git.kernel.org/stable/c/ebefca49e4c69df24ba9307bfe0806230301d5c6"},{"url":"https://git.kernel.org/stable/c/d9e6a7623938968e3752b67e37eaff097e559a54"}],"title":"mm/slab: prevent unbounded recursion in free path with new kmalloc type","x_generator":{"engine":"bippy-1.2.0"}}},"cveMetadata":{"assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","assignerShortName":"Linux","cveId":"CVE-2026-74576","datePublished":"2026-08-15T12:28:13.798Z","dateReserved":"2026-08-15T05:44:03.917Z","dateUpdated":"2026-08-15T12:28:13.798Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-08-15 13:18:03","lastModifiedDate":"2026-08-15 13:18:03","problem_types":[],"metrics":[],"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"74576","Ordinal":"1","Title":"mm/slab: prevent unbounded recursion in free path with new kmall","CVE":"CVE-2026-74576","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"74576","Ordinal":"1","NoteData":"In the Linux kernel, the following vulnerability has been resolved:\n\nmm/slab: prevent unbounded recursion in free path with new kmalloc type\n\nCommit 280ea9c3154b (\"mm/slab: avoid allocating slabobj_ext array from\nits own slab\") avoided recursive allocation of obj_exts from kmalloc\ncaches of the same size, by bumping the obj_exts array's allocation\nsize whenever the array size equals the size of the object being\nallocated.\n\nHowever, as reported by Danielle Costantino and Shakeel Butt,\neven slabs from kmalloc caches of different sizes can form a cycle\nby allocating obj_exts arrays from each other [1]:\n\n  What happened: a KMALLOC_NORMAL slab's obj_exts array (used by\n  allocation profiling / memcg accounting) is itself kmalloc()'d from a\n  KMALLOC_NORMAL cache, so the \"slab holds another slab's obj_exts array\"\n  relation can form cycles. With sizeof(struct slabobj_ext) == 16 and\n  the host's geometry:\n\n  - kmalloc-512 has 64 objects/slab -> array is 64*16 == 1024 bytes,\n    served from kmalloc-1k;\n  - kmalloc-1k  has 32 objects/slab -> array is 32*16 ==  512 bytes,\n    served from kmalloc-512.\n\n  A kmalloc-512 slab and a kmalloc-1k slab therefore hold each other's\n  obj_exts array.  Discarding one frees the other's array, which empties\n  and discards that slab, which frees the first's array, and so on:\n  __free_slab() -> free_slab_obj_exts() -> kfree() -> discard_slab() ->\n  __free_slab() recurses along the cycle until the stack is exhausted.\n\nWith memory allocation profiling, this allows unbounded recursion\nin the free path and led to a stack overflow on a production host in\nthe Meta fleet [1]:\n\n  BUG: TASK stack guard page was hit\n  Oops: stack guard page\n  RIP: 0010:kfree+0x8/0x5d0\n  Call Trace:\n   __free_slab+0x66/0xc0\n   kfree+0x3f0/0x5d0\n   ... ( ~125x __free_slab <-> kfree ) ...\n   <kernel driver freeing a resource>\n   do_syscall_64\n\nIt is proposed [1] to resolve this issue by always serving the obj_exts\narray allocation from kmalloc caches (or large kmalloc) of sizes larger\nthan the object size. However, as pointed out by Vlastimil Babka [2],\nthis can waste an excessive amount of memory as slabs from large\nkmalloc sizes (e.g. kmalloc-8k) generally need obj_exts arrays much\nsmaller than the object size.\n\nTherefore, rather than bumping the size, let us take a different\napproach; disallow formation of cycles between kmalloc types when\nallocating obj_exts arrays. Currently, all obj_exts arrays are served\nfrom normal kmalloc caches. Cycles cannot be created if obj_exts arrays\nof normal kmalloc caches are served from a special kmalloc type that can\nnever have obj_exts arrays.\n\nTo achieve this, create a new kmalloc type called KMALLOC_NO_OBJ_EXT.\nKMALLOC_NO_OBJ_EXT caches are created with SLAB_NO_OBJ_EXT flag when\neither 1) memory allocation profiling is not permanently disabled,\nor 2) kmalloc types with a priority higher than KMALLOC_CGROUP are\naliased with KMALLOC_NORMAL.\n\nSheaf bootstrapping for KMALLOC_NO_OBJ_EXT caches now must be deferred\nbecause allocation of a barn can trigger obj_exts array allocation of\nnormal kmalloc caches when the KMALLOC_NO_OBJ_EXT cache for that size\nis not ready yet. For simplicity, perform bootstrapping of sheaves for\nall kmalloc caches later.\n\nIntroduce a new slab alloc flag, SLAB_ALLOC_NO_OBJ_EXT, to prevent\nallocation of obj_exts arrays, and let kmalloc_slab() override the type\nto KMALLOC_NO_OBJ_EXT when specified. Note that kmalloc_type() remains\nunchanged because kmalloc_flags() bypasses the kmalloc fastpath.\n\nDo not pass SLAB_ALLOC_NO_RECURSE to kmalloc_flags() in\nalloc_slab_obj_exts() and instead use SLAB_ALLOC_NO_OBJ_EXT only when\nthe objects are allocated from normal kmalloc caches. While this\nprevents unbounded recursive allocation of obj_exts, it allows\nKMALLOC_NO_OBJ_EXT caches to have sheaves.\n\nSince sheaf allocations specify SLAB_ALLOC_NO_RECURSE that prevents\nallocation of both sheaves and obj_exts arrays, the recursion depth\nis bounded.\n\nobj_exts arrays for non-\n---truncated---","Type":"Description","Title":"mm/slab: prevent unbounded recursion in free path with new kmall"}]}}}