CVE-2026-45990
In the Linux kernel, the following vulnerability has been resolved:
slub: fix data loss and overflow in krealloc()
Commit 2cd8231796b5 ("mm/slub: allow to set node and align in k[v]realloc") introduced the ability to force a reallocation if the original object does not satisfy new alignment or NUMA node, even when the object is being shrunk.
This introduced two bugs in the reallocation fallback path:
The same overflow bug exists in the kvrealloc() fallback path, where the old bucket size ksize(p) is copied into the new buffer without being bounded by the new size.
A simple reproducer:
demonstrates the issue:
Leer descripción completaMostrar menos
Fix it by moving the old size calculation to the top of __do_krealloc() and bounding all copy lengths by the new allocation size.
Detalles técnicos trazas, registros y código del informe original
1. Data loss during NUMA migration: The jump to 'alloc_new' happens
before 'ks' and 'orig_size' are initialized. As a result, the
memcpy() in the 'alloc_new' block would copy 0 bytes into the new
allocation.
2. Buffer overflow during shrinking: When shrinking an object while
forcing a new alignment, 'new_size' is smaller than the old size.
However, the memcpy() used the old size ('orig_size ?: ks'), leading
to an out-of-bounds write.
// e.g. add to lkdtm as KREALLOC_SHRINK_OVERFLOW
while (1) {
void *p = kmalloc(128, GFP_KERNEL);
p = krealloc_node_align(p, 64, 256, GFP_KERNEL, NUMA_NO_NODE);
kfree(p);
}
==================================================================
BUG: KFENCE: out-of-bounds write in memcpy_orig+0x68/0x130
Out-of-bounds write at 0xffff8883ad757038 (120B right of kfence-#47):
memcpy_orig+0x68/0x130
krealloc_node_align_noprof+0x1c8/0x340
lkdtm_KREALLOC_SHRINK_OVERFLOW+0x8c/0xc0 [lkdtm]
lkdtm_do_action+0x3a/0x60 [lkdtm]
...
kfence-#47: 0xffff8883ad756fc0-0xffff8883ad756fff, size=64, cache=kmalloc-64
allocated by task 316 on cpu 7 at 97.680481s (0.021813s ago):
krealloc_node_align_noprof+0x19c/0x340
lkdtm_KREALLOC_SHRINK_OVERFLOW+0x8c/0xc0 [lkdtm]
lkdtm_do_action+0x3a/0x60 [lkdtm]
...
==================================================================CVSS
- Versión: 3.1
- Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
- Puntuación base: 5.5
Probabilidad de explotación (EPSS)
- Probabilidad de explotación en los próximos 30 días: 0.17%
- Percentil entre todas las CVEs puntuadas: 6
- Fecha de la puntuación: 5/10/2026
EPSS (Exploit Prediction Scoring System, de FIRST) estima la probabilidad de que una vulnerabilidad sea explotada en 30 días. Complementa a CVSS (impacto) y a CISA KEV (explotación confirmada).
Tecnologías afectadas (1)
CWE
- CWE-190
Referencias
JSON original (NVD)
Mostrar
{
"id": "CVE-2026-45990",
"cveTags": [],
"metrics": {
"cvssMetricV31": [
{
"type": "Primary",
"source": "nvd@nist.gov",
"cvssData": {
"scope": "UNCHANGED",
"version": "3.1",
"baseScore": 5.5,
"attackVector": "LOCAL",
"baseSeverity": "MEDIUM",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"integrityImpact": "NONE",
"userInteraction": "NONE",
"attackComplexity": "LOW",
"availabilityImpact": "HIGH",
"privilegesRequired": "LOW",
"confidentialityImpact": "NONE"
},
"impactScore": 3.6,
"exploitabilityScore": 1.8
}
]
},
"affected": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"affectedData": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"product": "Linux",
"versions": [
{
"status": "affected",
"version": "2cd8231796b5e7133b1c3d66ad7d2a3c42c97258",
"lessThan": "38387ccc0fbe38d14fb4c2ad7ee1d7404e5e59fd",
"versionType": "git"
},
{
"status": "affected",
"version": "2cd8231796b5e7133b1c3d66ad7d2a3c42c97258",
"lessThan": "550fa6b5aabb096554536ac1e3ec96b76cbb35fd",
"versionType": "git"
},
{
"status": "affected",
"version": "2cd8231796b5e7133b1c3d66ad7d2a3c42c97258",
"lessThan": "082a6d03a2d685a83a332666b500ad3966349588",
"versionType": "git"
}
],
"programFiles": [
"mm/slub.c"
],
"defaultStatus": "unaffected"
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"product": "Linux",
"versions": [
{
"status": "affected",
"version": "6.18"
},
{
"status": "unaffected",
"version": "0",
"lessThan": "6.18",
"versionType": "semver"
},
{
"status": "unaffected",
"version": "6.18.27",
"versionType": "semver",
"lessThanOrEqual": "6.18.*"
},
{
"status": "unaffected",
"version": "7.0.4",
"versionType": "semver",
"lessThanOrEqual": "7.0.*"
},
{
"status": "unaffected",
"version": "7.1",
"versionType": "original_commit_for_fix",
"lessThanOrEqual": "*"
}
],
"programFiles": [
"mm/slub.c"
],
"defaultStatus": "affected"
}
]
}
],
"published": "2026-05-27T14:17:16.527",
"references": [
{
"url": "https://git.kernel.org/stable/c/082a6d03a2d685a83a332666b500ad3966349588",
"tags": [
"Patch"
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/38387ccc0fbe38d14fb4c2ad7ee1d7404e5e59fd",
"tags": [
"Patch"
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/550fa6b5aabb096554536ac1e3ec96b76cbb35fd",
"tags": [
"Patch"
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"vulnStatus": "Analyzed",
"weaknesses": [
{
"type": "Primary",
"source": "nvd@nist.gov",
"description": [
{
"lang": "en",
"value": "CWE-190"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nslub: fix data loss and overflow in krealloc()\n\nCommit 2cd8231796b5 (\"mm/slub: allow to set node and align in\nk[v]realloc\") introduced the ability to force a reallocation if the\noriginal object does not satisfy new alignment or NUMA node, even when\nthe object is being shrunk.\n\nThis introduced two bugs in the reallocation fallback path:\n\n1. Data loss during NUMA migration: The jump to 'alloc_new' happens\n before 'ks' and 'orig_size' are initialized. As a result, the\n memcpy() in the 'alloc_new' block would copy 0 bytes into the new\n allocation.\n\n2. Buffer overflow during shrinking: When shrinking an object while\n forcing a new alignment, 'new_size' is smaller than the old size.\n However, the memcpy() used the old size ('orig_size ?: ks'), leading\n to an out-of-bounds write.\n\nThe same overflow bug exists in the kvrealloc() fallback path, where the\nold bucket size ksize(p) is copied into the new buffer without being\nbounded by the new size.\n\nA simple reproducer:\n\n\t// e.g. add to lkdtm as KREALLOC_SHRINK_OVERFLOW\n\twhile (1) {\n\t\tvoid *p = kmalloc(128, GFP_KERNEL);\n\t\tp = krealloc_node_align(p, 64, 256, GFP_KERNEL, NUMA_NO_NODE);\n\t\tkfree(p);\n\t}\n\ndemonstrates the issue:\n\n ==================================================================\n BUG: KFENCE: out-of-bounds write in memcpy_orig+0x68/0x130\n\n Out-of-bounds write at 0xffff8883ad757038 (120B right of kfence-#47):\n memcpy_orig+0x68/0x130\n krealloc_node_align_noprof+0x1c8/0x340\n lkdtm_KREALLOC_SHRINK_OVERFLOW+0x8c/0xc0 [lkdtm]\n lkdtm_do_action+0x3a/0x60 [lkdtm]\n ...\n\n kfence-#47: 0xffff8883ad756fc0-0xffff8883ad756fff, size=64, cache=kmalloc-64\n\n allocated by task 316 on cpu 7 at 97.680481s (0.021813s ago):\n krealloc_node_align_noprof+0x19c/0x340\n lkdtm_KREALLOC_SHRINK_OVERFLOW+0x8c/0xc0 [lkdtm]\n lkdtm_do_action+0x3a/0x60 [lkdtm]\n ...\n ==================================================================\n\nFix it by moving the old size calculation to the top of __do_krealloc()\nand bounding all copy lengths by the new allocation size."
}
],
"lastModified": "2026-06-17T10:52:51.603",
"configurations": [
{
"nodes": [
{
"negate": false,
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"vulnerable": true,
"matchCriteriaId": "1A10DA86-4154-4102-9D63-807CF10A4352",
"versionEndExcluding": "6.18.27",
"versionStartIncluding": "6.18"
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"vulnerable": true,
"matchCriteriaId": "CDB78D6D-22C3-4154-B0D0-94AF1CE5C2E3",
"versionEndExcluding": "7.0.4",
"versionStartIncluding": "6.19"
}
],
"operator": "OR"
}
]
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}