CVE-2026-45990: Linux Kernel Buffer Overflow Vulnerability

CVE-2026-45990 Overview

CVE-2026-45990 is a Linux kernel vulnerability in the SLUB memory allocator's krealloc() reallocation fallback path. The flaw was introduced by commit 2cd8231796b5 ("mm/slub: allow to set node and align in k[v]realloc"), which added the ability to force reallocation when alignment or NUMA node constraints are not satisfied. The defect produces two distinct failure modes: data loss during NUMA migration and an out-of-bounds heap write when shrinking an object with a forced alignment. The same overflow pattern exists in the kvrealloc() fallback path, where ksize(p) is copied into a smaller destination buffer without size bounding.

Critical Impact
Local code paths invoking krealloc_node_align() with a smaller new_size can trigger out-of-bounds kernel heap writes, leading to memory corruption and potential privilege escalation.

Affected Products

Linux kernel versions containing commit 2cd8231796b5 ("mm/slub: allow to set node and align in k[v]realloc")
Linux kernel slub allocator __do_krealloc() and kvrealloc() fallback paths
Distributions shipping affected stable kernel branches prior to the fix commits

Discovery Timeline

2026-05-27 - CVE-2026-45990 published to NVD
2026-05-27 - Last updated in NVD database

Technical Details for CVE-2026-45990

Vulnerability Analysis

The vulnerability resides in the reallocation fallback path of __do_krealloc() in the Linux kernel's SLUB allocator. When a caller requests a new alignment or NUMA node that the existing object cannot satisfy, the code jumps to the alloc_new label to allocate a fresh buffer and copy the existing contents. Two ordering and bounds-checking defects exist in this path.

The first defect is a data-loss condition. The jump to alloc_new occurs before the local variables ks (the original bucket size) and orig_size are initialized. The subsequent memcpy() therefore copies zero bytes into the new allocation, silently discarding caller data during NUMA migration.

The second defect is an out-of-bounds write [CWE-787]. When new_size is smaller than the original allocation, the memcpy() length is computed as orig_size ?: ks, which reflects the old size rather than the new bound. The copy writes past the end of the smaller destination buffer. The same pattern exists in kvrealloc(), where ksize(p) is used unbounded.

Root Cause

The root cause is incorrect ordering of size initialization relative to the alloc_new jump target and the absence of a min() bound between source and destination sizes in the memcpy() call. The fix moves the old-size calculation to the top of __do_krealloc() and bounds all copy lengths by the new allocation size.

Attack Vector

Exploitation requires local kernel-context code that invokes krealloc_node_align() or kvrealloc() with a new_size smaller than the original object while requesting a different alignment or NUMA node. The reproducer published with the patch uses the lkdtm test module to trigger a KFENCE-detected out-of-bounds write at memcpy_orig+0x68/0x130 originating from krealloc_node_align_noprof(). Reachability from unprivileged userspace depends on which in-kernel callers pass attacker-influenced size and alignment parameters to the affected APIs.

// Reproducer pattern from the upstream commit message (prose summary)
// Allocate 128 bytes, then krealloc with new_size=64 but align=256.
// The shrink-with-realignment path copies the old size into the smaller
// destination buffer, producing an out-of-bounds write detected by KFENCE.

Detection Methods for CVE-2026-45990

Indicators of Compromise

KFENCE or KASAN reports citing memcpy_orig called from krealloc_node_align_noprof+0x1c8/0x340 with an "out-of-bounds write" classification.
Kernel oops or panic stacks containing __do_krealloc or kvrealloc frames adjacent to slab corruption diagnostics.
Unexplained zeroed buffers immediately after krealloc() calls that requested a different NUMA node, indicating the data-loss variant.

Detection Strategies

Enable CONFIG_KFENCE and CONFIG_KASAN on test and canary kernels to surface the out-of-bounds write at runtime.
Audit kernel modules and drivers for callers of krealloc_node_align() and kvrealloc() that pass a shrinking new_size together with a non-default alignment or node.
Build with lkdtm and exercise a KREALLOC_SHRINK_OVERFLOW-style test case to confirm whether a given kernel build carries the fix.

Monitoring Recommendations

Forward kernel ring buffer and kern.log entries containing KFENCE, KASAN, or BUG: markers to a central log store for review.
Track package versions of running kernels against the fixed commits 082a6d03a2d6, 38387ccc0fbe, and 550fa6b5aabb to identify hosts still exposed.
Alert on unexpected module loads of lkdtm in production, as it is a kernel self-test module rather than a production component.

How to Mitigate CVE-2026-45990

Immediate Actions Required

Apply the upstream stable kernel updates that include commits 082a6d03a2d6, 38387ccc0fbe, and 550fa6b5aabb and reboot affected hosts.
Rebuild and redeploy any out-of-tree kernel modules that call krealloc_node_align() or kvrealloc() against a patched kernel tree.
Disable or restrict loading of the lkdtm test module in production environments.

Patch Information

The fix moves the old-size calculation to the top of __do_krealloc() and bounds every memcpy() length by the new allocation size, eliminating both the zero-copy data-loss path and the shrink-time out-of-bounds write. Reference patches: kernel.org commit 082a6d03a2d6, kernel.org commit 38387ccc0fbe, and kernel.org commit 550fa6b5aabb.

Workarounds

Avoid calling krealloc_node_align() or kvrealloc() with a new_size smaller than the existing object when also changing alignment or NUMA node until the patched kernel is deployed.
Restrict loading of unsigned or third-party kernel modules through kernel.modules_disabled=1 or module signing enforcement to reduce the set of callers reaching the affected path.
Run security-sensitive workloads on kernel builds with CONFIG_KFENCE=y so that triggered out-of-bounds writes are detected and contained rather than silently corrupting adjacent slabs.

bash

# Verify the running kernel includes one of the fix commits
uname -r
zgrep -E '082a6d03a2d6|38387ccc0fbe|550fa6b5aabb' /usr/share/doc/linux-image-*/changelog.Debian.gz 2>/dev/null

# Prevent lkdtm from being loaded in production
echo 'blacklist lkdtm' | sudo tee /etc/modprobe.d/blacklist-lkdtm.conf