CVE-2026-45990: slub: fix data loss and overflow in krealloc()
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 'allocnew' 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 KREALLOCSHRINKOVERFLOW while (1) { void p = kmalloc(128, GFPKERNEL); p = kreallocnodealign(p, 64, 256, GFPKERNEL, NUMANONODE); kfree(p); }
demonstrates the issue:
================================================================== BUG: KFENCE: out-of-bounds write in memcpyorig+0x68/0x130
Out-of-bounds write at 0xffff8883ad757038 (120B right of kfence-#47): memcpyorig+0x68/0x130 kreallocnodealignnoprof+0x1c8/0x340 lkdtmKREALLOCSHRINKOVERFLOW+0x8c/0xc0 [lkdtm] lkdtmdoaction+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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Until the fix is applied, avoid forcing reallocation to change alignment or NUMA node on shrinking allocations (i.e., avoid calls that force a new alignment/NUMA such as krealloc_node_align/krealloc_node_align_noprof with a smaller new_size) to mitigate data-loss and overflow risks.
- Operational
Apply a source-level fix to the kernel slub allocator: move the old-size calculation to the top of __do_krealloc() and bound all copy lengths by the new allocation size to prevent data loss and out-of-bounds writes in krealloc() and kvrealloc().
- Operational
Use the provided reproducer (e.g., the lkdtm KREALLOC_SHRINK_OVERFLOW loop shown in the advisory) to verify the issue is resolved after applying the fix.