CVE-2026-64368 (GCVE-0-2026-64368)
Vulnerability from cvelistv5
Published
2026-07-25 08:50
Modified
2026-08-17 04:54
Severity ?
VLAI Severity ?
EPSS score ?
Summary
In the Linux kernel, the following vulnerability has been resolved:
mm/slab: do not limit zeroing to orig_size when only red zoning is enabled
When init (zeroing) on allocation is requested, for kmalloc() we
generally have to zero the full object size even if a smaller size is
requested, in order to provide krealloc()'s __GFP_ZERO guarantees.
But if we track the requested size, krealloc() uses that information to
do the right thing, so we can zero only the requested size. With red
zoning also enabled, any extra size became part of the red zone, so it
must not be zeroed and thus we must zero only the requested size.
However the current check is imprecise, and will trigger also when only
SLAB_RED_ZONE is enabled without SLAB_STORE_USER (which enables tracking
the requested size). This means enabling red zoning alone can compromise
krealloc()'s __GFP_ZERO contract.
Fix this by using slub_debug_orig_size() instead, which is the exact
check for whether the requested size is tracked. We don't need to care
if red zoning is also enabled or not. Also update and expand the
comment accordingly.
References
Impacted products
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"mm/slub.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "6256899c3a34674bba6076884aedbba49fc695e4",
"status": "affected",
"version": "9ce67395f5a0cdec6ce152d26bfda13b98b25c01",
"versionType": "git"
},
{
"lessThan": "7e706d50fa119eead6376bf0ef973e8d73a96030",
"status": "affected",
"version": "9ce67395f5a0cdec6ce152d26bfda13b98b25c01",
"versionType": "git"
},
{
"lessThan": "2382971aaaef5bf85a651234c64906f59580b8be",
"status": "affected",
"version": "9ce67395f5a0cdec6ce152d26bfda13b98b25c01",
"versionType": "git"
},
{
"lessThan": "0d18ccef142f04433dfb2a0c120cf223d2b8a42c",
"status": "affected",
"version": "9ce67395f5a0cdec6ce152d26bfda13b98b25c01",
"versionType": "git"
},
{
"lessThan": "648927ceb84021a25a0fbd5673740956f318d534",
"status": "affected",
"version": "9ce67395f5a0cdec6ce152d26bfda13b98b25c01",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"mm/slub.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "6.2"
},
{
"lessThan": "6.2",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.145",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.96",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.39",
"versionType": "semver"
},
{
"lessThanOrEqual": "7.1.*",
"status": "unaffected",
"version": "7.1.4",
"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.6.145",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.96",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.18.39",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "7.1.4",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "7.2",
"versionStartIncluding": "6.2",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/slab: do not limit zeroing to orig_size when only red zoning is enabled\n\nWhen init (zeroing) on allocation is requested, for kmalloc() we\ngenerally have to zero the full object size even if a smaller size is\nrequested, in order to provide krealloc()\u0027s __GFP_ZERO guarantees.\n\nBut if we track the requested size, krealloc() uses that information to\ndo the right thing, so we can zero only the requested size. With red\nzoning also enabled, any extra size became part of the red zone, so it\nmust not be zeroed and thus we must zero only the requested size.\n\nHowever the current check is imprecise, and will trigger also when only\nSLAB_RED_ZONE is enabled without SLAB_STORE_USER (which enables tracking\nthe requested size). This means enabling red zoning alone can compromise\nkrealloc()\u0027s __GFP_ZERO contract.\n\nFix this by using slub_debug_orig_size() instead, which is the exact\ncheck for whether the requested size is tracked. We don\u0027t need to care\nif red zoning is also enabled or not. Also update and expand the\ncomment accordingly."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 8.1,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"scenarios": [
{
"lang": "en",
"value": "AV:N - On an already-mounted CephFS client, a malicious or compromised monitor can deliver crafted MDS-map data over TCP that reaches ceph_mdsmap_decode(), krealloc(), and the vulnerable allocator behavior.\nAC:H - Exploitation requires the uncommon, attacker-uncontrolled configuration of SLUB red zoning without SLAB_STORE_USER. Once configured, the attacker controls allocation sizes and heap-grooming messages without needing an uncontrolled race.\nPR:N - The attacking network peer requires no local account or capability on the target, and legacy or unauthenticated Ceph monitor connections can deliver the map without verified credentials.\nUI:N - An already-mounted, long-lived CephFS client processes MDS-map updates asynchronously, requiring no victim action during exploitation.\nS:U - Successful exploitation compromises the kernel and host resources within the same security authority; it does not inherently cross a VM or equivalent boundary.\nC:H - The skipped allocation tail exposes stale kernel-heap contents as valid data, including a pointer that check_new_map() can dereference, creating arbitrary kernel-memory read and disclosure potential.\nI:H - Stale attacker-groomed counts and pointers can reach unchecked set_bit() operations and kfree(), enabling out-of-bounds writes, arbitrary frees, and potential control-flow hijacking.\nA:H - Invalid pointer dereferences, out-of-bounds stack writes, or freeing a stale pointer can cause a kernel oops or panic and can be triggered repeatedly by crafted map updates."
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-17T04:54:17.771Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/6256899c3a34674bba6076884aedbba49fc695e4"
},
{
"url": "https://git.kernel.org/stable/c/7e706d50fa119eead6376bf0ef973e8d73a96030"
},
{
"url": "https://git.kernel.org/stable/c/2382971aaaef5bf85a651234c64906f59580b8be"
},
{
"url": "https://git.kernel.org/stable/c/0d18ccef142f04433dfb2a0c120cf223d2b8a42c"
},
{
"url": "https://git.kernel.org/stable/c/648927ceb84021a25a0fbd5673740956f318d534"
}
],
"title": "mm/slab: do not limit zeroing to orig_size when only red zoning is enabled",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2026-64368",
"datePublished": "2026-07-25T08:50:21.831Z",
"dateReserved": "2026-07-19T15:36:31.783Z",
"dateUpdated": "2026-08-17T04:54:17.771Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
Loading…
Loading…
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.
Loading…
Loading…