CVE-2026-45990

Source
https://cve.org/CVERecord?id=CVE-2026-45990
Import Source
https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2026-45990.json
JSON Data
https://api.test.osv.dev/v1/vulns/CVE-2026-45990
Downstream
Related
Published
2026-05-27T12:55:42.572Z
Modified
2026-06-18T03:54:48.835064296Z
Summary
slub: fix data loss and overflow in krealloc()
Details

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:

  1. Data loss during NUMA migration: The jump to 'allocnew' happens before 'ks' and 'origsize' 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, 'newsize' is smaller than the old size. However, the memcpy() used the old size ('origsize ?: ks'), leading to an out-of-bounds write.

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:

// 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);
}

demonstrates the issue:

================================================================== BUG: KFENCE: out-of-bounds write in memcpy_orig+0x68/0x130

Out-of-bounds write at 0xffff8883ad757038 (120B right of kfence-#47): memcpyorig+0x68/0x130 kreallocnodealignnoprof+0x1c8/0x340 lkdtmKREALLOCSHRINKOVERFLOW+0x8c/0xc0 [lkdtm] lkdtmdo_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): kreallocnodealignnoprof+0x19c/0x340 lkdtmKREALLOCSHRINKOVERFLOW+0x8c/0xc0 [lkdtm] lkdtmdoaction+0x3a/0x60 [lkdtm] ... ==================================================================

Fix it by moving the old size calculation to the top of _dokrealloc() and bounding all copy lengths by the new allocation size.

Database specific
{
    "cna_assigner": "Linux",
    "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/45xxx/CVE-2026-45990.json"
}
References

Affected packages

Git / git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git

Affected ranges

Type
GIT
Repo
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Events
Introduced
2cd8231796b5e7133b1c3d66ad7d2a3c42c97258
Fixed
38387ccc0fbe38d14fb4c2ad7ee1d7404e5e59fd
Fixed
550fa6b5aabb096554536ac1e3ec96b76cbb35fd
Fixed
082a6d03a2d685a83a332666b500ad3966349588

Database specific

source
"https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2026-45990.json"

Linux / Kernel

Package

Name
Kernel

Affected ranges

Type
ECOSYSTEM
Events
Introduced
6.18.0
Fixed
6.18.27
Type
ECOSYSTEM
Events
Introduced
6.19.0
Fixed
7.0.4

Database specific

source
"https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2026-45990.json"