CVE-2026-45990
Awaiting Analysis Awaiting Analysis - Queue
BaseFortify

Publication date: 2026-05-27

Last updated on: 2026-05-27

Assigner: kernel.org

Description
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 '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. 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): 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] ... ================================================================== Fix it by moving the old size calculation to the top of __do_krealloc() and bounding all copy lengths by the new allocation size.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-27
Last Modified
2026-05-27
Generated
2026-05-27
AI Q&A
2026-05-27
EPSS Evaluated
N/A
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux_kernel linux_kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability exists in the Linux kernel's memory allocator (slub) related to the krealloc() function, which reallocates memory. A recent change introduced the ability to force reallocation when the original memory object does not meet new alignment or NUMA node requirements, even if the object is being shrunk.

Two bugs were introduced in this reallocation fallback path: first, data loss during NUMA migration because the source size was not initialized before copying, resulting in zero bytes copied; second, a buffer overflow when shrinking an object with forced new alignment because the memcpy operation copied more bytes than the new smaller size, causing out-of-bounds writes.

These bugs can lead to memory corruption, demonstrated by an example reproducer that triggers an out-of-bounds write detected by kernel memory debugging tools.


How can this vulnerability impact me? :

This vulnerability can cause data loss and memory corruption within the Linux kernel's memory management subsystem.

Specifically, it can lead to out-of-bounds memory writes, which may cause system instability, crashes, or unpredictable behavior.

Such memory corruption issues can potentially be exploited by attackers to escalate privileges or execute arbitrary code, depending on the context and kernel usage.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by reproducing the conditions that trigger the bug, such as using the provided simple reproducer code snippet that repeatedly calls krealloc_node_align with shrinking size and alignment forcing.

The reproducer example is:

  • while (1) { void *p = kmalloc(128, GFP_KERNEL); p = krealloc_node_align(p, 64, 256, GFP_KERNEL, NUMA_NO_NODE); kfree(p); }

This will cause an out-of-bounds write detected by KFENCE, which can be observed in kernel logs.

To detect this on your system, you can monitor kernel logs for messages indicating out-of-bounds writes related to krealloc_node_align or use kernel debugging tools like KFENCE to catch such memory errors.


What immediate steps should I take to mitigate this vulnerability?

The immediate mitigation is to update the Linux kernel to a version that includes the fix for this vulnerability.

The fix involves moving the old size calculation to the top of __do_krealloc() and bounding all copy lengths by the new allocation size, preventing data loss and buffer overflow.

Until the kernel is updated, avoid workloads or code paths that trigger krealloc_node_align with shrinking and alignment forcing, as these can cause memory corruption.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart