GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

CVE-2026-74576 (GCVE-0-2026-74576)

Vulnerability from cvelistv5 – Published: 2026-08-15 12:28 – Updated: 2026-08-17 05:48
VLAI
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 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---
Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Assigner
References
Impacted products
Vendor Product Version CPE status
Linux Linux Affected: 4b8736964640fe160724e7135dc62883bddcdace , < 3e71bfbdd3fd81ee9fefd867fdb2be62bade4140 (git)
Affected: 4b8736964640fe160724e7135dc62883bddcdace , < d01e88d421a6d07f35235600a43fbd0e551cf292 (git)
Affected: 4b8736964640fe160724e7135dc62883bddcdace , < ebefca49e4c69df24ba9307bfe0806230301d5c6 (git)
Affected: 4b8736964640fe160724e7135dc62883bddcdace , < d9e6a7623938968e3752b67e37eaff097e559a54 (git)
guessed Create a notification for this product.
Linux Linux Affected: 6.10
Unaffected: 0 , < 6.10 (semver)
Unaffected: 6.12.103 , ≤ 6.12.* (semver)
Unaffected: 6.18.44 , ≤ 6.18.* (semver)
Unaffected: 7.1.8 , ≤ 7.1.* (semver)
Unaffected: 7.2 , ≤ * (original_commit_for_fix)
guessed Create a notification for this product.
Show details on NVD website
To clipboard 

{
  "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",
              "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",
                  "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\u0027s 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\u0027s obj_exts array (used by\n  allocation profiling / memcg accounting) is itself kmalloc()\u0027d from a\n  KMALLOC_NORMAL cache, so the \"slab holds another slab\u0027s obj_exts array\"\n  relation can form cycles. With sizeof(struct slabobj_ext) == 16 and\n  the host\u0027s geometry:\n\n  - kmalloc-512 has 64 objects/slab -\u003e array is 64*16 == 1024 bytes,\n    served from kmalloc-1k;\n  - kmalloc-1k  has 32 objects/slab -\u003e 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\u0027s\n  obj_exts array.  Discarding one frees the other\u0027s array, which empties\n  and discards that slab, which frees the first\u0027s array, and so on:\n  __free_slab() -\u003e free_slab_obj_exts() -\u003e kfree() -\u003e discard_slab() -\u003e\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 \u003c-\u003e kfree ) ...\n   \u003ckernel driver freeing a resource\u003e\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---"
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 7.5,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
            "version": "3.1"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "AV:N - The bug is in the core SLUB kmalloc free path (__free_slab\u2192free_slab_obj_exts\u2192kfree\u2192discard_slab) shared by every kernel subsystem. On internet-facing servers with memory allocation profiling enabled (Meta production), remote workloads that drive routine frees of 512B/1kB kmalloc objects reach discard_slab and trigger the recursion.\nAC:L - With memory allocation profiling active, kmalloc-512 and kmalloc-1k slabs deterministically form a mutual obj_exts cycle from normal slab geometry. An attacker only needs to provoke standard kernel frees\u2014no races, special heap layout, or timing\u2014making exploitation reliable once profiling is enabled on the host.\nPR:N - Remote attackers need no account or kernel capabilities; unauthenticated network I/O that causes the kernel to free affected slabs suffices. Locally, any unprivileged process can reach kfree via ordinary syscalls, as in the documented Meta production crash through do_syscall_64.\nUI:N - Exploitation requires no victim interaction; the crash is triggered by attacker-driven or routine automated kernel memory free activity once the cyclic slabs exist.\nS:U - Impact is a kernel oops/stack guard fault within kernel context; it does not cross a VM, container, or IOMMU boundary into another security authority.\nC:N - The failure mode is unbounded recursion exhausting the kernel task stack (BUG: TASK stack guard page was hit). There is no memory corruption, use-after-free, or out-of-bounds read\u2014only repeated legitimate frees cycling until stack overflow.\nI:N - No integrity impact; objects are freed via the normal kfree path without arbitrary writes or control-flow hijacking. The recursion terminates at stack overflow without modifying attacker-controlled data.\nA:H - Exploitation reliably causes a kernel oops/panic via stack guard page violation (\"Oops: stack guard page\"), crashing the affected context and potentially the host, as demonstrated in Meta production with ~125 nested __free_slab/kfree frames."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-17T05:48:56.072Z",
        "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-17T05:48:56.072Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2026-74576",
      "date": "2026-09-04",
      "epss": "0.00376",
      "percentile": "0.30672"
    },
    "nvd": "{\"cve\":{\"id\":\"CVE-2026-74576\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2026-08-15T13:18:03.290\",\"lastModified\":\"2026-08-17T06:19:56.017\",\"vulnStatus\":\"Received\",\"cveTags\":[],\"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\u0027s 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\u0027s obj_exts array (used by\\n  allocation profiling / memcg accounting) is itself kmalloc()\u0027d from a\\n  KMALLOC_NORMAL cache, so the \\\"slab holds another slab\u0027s obj_exts array\\\"\\n  relation can form cycles. With sizeof(struct slabobj_ext) == 16 and\\n  the host\u0027s geometry:\\n\\n  - kmalloc-512 has 64 objects/slab -\u003e array is 64*16 == 1024 bytes,\\n    served from kmalloc-1k;\\n  - kmalloc-1k  has 32 objects/slab -\u003e 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\u0027s\\n  obj_exts array.  Discarding one frees the other\u0027s array, which empties\\n  and discards that slab, which frees the first\u0027s array, and so on:\\n  __free_slab() -\u003e free_slab_obj_exts() -\u003e kfree() -\u003e discard_slab() -\u003e\\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 \u003c-\u003e kfree ) ...\\n   \u003ckernel driver freeing a resource\u003e\\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---\"}],\"affected\":[{\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"affectedData\":[{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"unaffected\",\"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\",\"versions\":[{\"version\":\"4b8736964640fe160724e7135dc62883bddcdace\",\"lessThan\":\"3e71bfbdd3fd81ee9fefd867fdb2be62bade4140\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"4b8736964640fe160724e7135dc62883bddcdace\",\"lessThan\":\"d01e88d421a6d07f35235600a43fbd0e551cf292\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"4b8736964640fe160724e7135dc62883bddcdace\",\"lessThan\":\"ebefca49e4c69df24ba9307bfe0806230301d5c6\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"4b8736964640fe160724e7135dc62883bddcdace\",\"lessThan\":\"d9e6a7623938968e3752b67e37eaff097e559a54\",\"versionType\":\"git\",\"status\":\"affected\"}]},{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"affected\",\"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\",\"versions\":[{\"version\":\"6.10\",\"status\":\"affected\"},{\"version\":\"0\",\"lessThan\":\"6.10\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.12.103\",\"lessThanOrEqual\":\"6.12.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.18.44\",\"lessThanOrEqual\":\"6.18.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"7.1.8\",\"lessThanOrEqual\":\"7.1.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"7.2\",\"lessThanOrEqual\":\"*\",\"versionType\":\"original_commit_for_fix\",\"status\":\"unaffected\"}]}]}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"type\":\"Secondary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H\",\"baseScore\":7.5,\"baseSeverity\":\"HIGH\",\"attackVector\":\"NETWORK\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"NONE\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"NONE\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":3.9,\"impactScore\":3.6}]},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/3e71bfbdd3fd81ee9fefd867fdb2be62bade4140\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/d01e88d421a6d07f35235600a43fbd0e551cf292\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/d9e6a7623938968e3752b67e37eaff097e559a54\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/ebefca49e4c69df24ba9307bfe0806230301d5c6\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}]}}",
    "redhat_vex": {
      "aggregate_severity": "Moderate",
      "current_release_date": "2026-08-21T12:40:40+00:00",
      "cve": "CVE-2026-74576",
      "id": "CVE-2026-74576",
      "initial_release_date": "2026-08-15T00:00:00+00:00",
      "product_status:known_affected": "76",
      "product_status:known_not_affected": "198",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "kernel: mm/slab: prevent unbounded recursion in free path with new kmalloc type",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-74576.json",
      "version": "3"
    }
  }
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.