Skip to content
Heist/ feed
Back to feed
HighFix available

mm/slab: prevent unbounded recursion in free path with new kmalloc type

Type: advisorySources: OSV

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

Products
Kernel
Affected versions
Not specified
Fixed versions
6.12.103, 6.18.44, 7.1.8
CVEs
CVE-2026-74576
Confirmed fixed CVEs
Not specified
Updated in this feed
4 Nov 2026, 18:56 UTC · Revision 1

Source evidence

mm/slab: prevent unbounded recursion in free path with new kmalloc type

core-osv · Original source

Published 15 Aug 2026, 12:28 UTC

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

osv:CVE-2026-74576

Kernel

Fixed versions: 6.12.103, 6.18.44, 7.1.8

Complete source record
{
  "id": "055517d4329997dca29626deecba7f161372ed78bd2b4035b8c498760c0ffc0f",
  "url": "https://osv.dev/vulnerability/CVE-2026-74576",
  "method": "structured",
  "payload": {
    "kind": "advisory",
    "title": "mm/slab: prevent unbounded recursion in free path with new kmalloc type",
    "summary": "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",
    "evidence": "osv:CVE-2026-74576",
    "products": [
      {
        "name": {
          "value": "Kernel",
          "evidence": "/affected/1/package/name"
        },
        "prerequisites": [],
        "fixed_versions": [
          {
            "value": "6.12.103",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "6.18.44",
            "evidence": "/affected/1/ranges"
          },
          {
            "value": "7.1.8",
            "evidence": "/affected/1/ranges"
          }
        ],
        "affected_versions": []
      }
    ],
    "severity": "high",
    "structured": {
      "id": "CVE-2026-74576",
      "aliases": [
        "CVE-2026-74576"
      ],
      "metrics": [
        {
          "type": "CVSS_V3",
          "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H"
        }
      ],
      "affected": [
        {
          "ranges": [
            {
              "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
              "type": "GIT",
              "events": [
                {
                  "introduced": "4b8736964640fe160724e7135dc62883bddcdace"
                },
                {
                  "fixed": "3e71bfbdd3fd81ee9fefd867fdb2be62bade4140"
                },
                {
                  "fixed": "d01e88d421a6d07f35235600a43fbd0e551cf292"
                },
                {
                  "fixed": "ebefca49e4c69df24ba9307bfe0806230301d5c6"
                },
                {
                  "fixed": "d9e6a7623938968e3752b67e37eaff097e559a54"
                }
              ]
            }
          ],
          "database_specific": {
            "source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-74576.json"
          }
        },
        {
          "ranges": [
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "6.10.0"
                },
                {
                  "fixed": "6.12.103"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "6.13.0"
                },
                {
                  "fixed": "6.18.44"
                }
              ]
            },
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "6.19.0"
                },
                {
                  "fixed": "7.1.8"
                }
              ]
            }
          ],
          "package": {
            "name": "Kernel",
            "ecosystem": "Linux"
          },
          "database_specific": {
            "source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-74576.json"
          }
        }
      ],
      "modified": "2026-10-28T02:30:38.502107820Z",
      "provider": "osv",
      "references": [
        "https://git.kernel.org/stable/c/3e71bfbdd3fd81ee9fefd867fdb2be62bade4140",
        "https://git.kernel.org/stable/c/d01e88d421a6d07f35235600a43fbd0e551cf292",
        "https://git.kernel.org/stable/c/d9e6a7623938968e3752b67e37eaff097e559a54",
        "https://git.kernel.org/stable/c/ebefca49e4c69df24ba9307bfe0806230301d5c6",
        "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/74xxx/CVE-2026-74576.json",
        "https://nvd.nist.gov/vuln/detail/CVE-2026-74576",
        "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
      ],
      "provider_metadata": {
        "cna_assigner": "Linux",
        "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/74xxx/CVE-2026-74576.json"
      }
    },
    "related_cves": [
      {
        "value": "CVE-2026-74576",
        "evidence": "/id"
      }
    ],
    "security_relevant": true,
    "severity_evidence": "/severity/0/score"
  },
  "source_id": "core-osv",
  "document_id": 505916,
  "published_at": "2026-08-15T12:28:13.798+00:00"
}