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.
Published: 2026-05-27
Score: n/a
EPSS: n/a
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The vulnerability arises from incorrect size calculation in the slub allocator's krealloc path. During a shrink operation or NUMA migration, the code copies data using an original size that exceeds the new allocation, leading to a buffer overflow. The overflow can overwrite adjacent memory or trigger a data loss in NUMA migration, potentially compromising kernel memory integrity and enabling privilege escalation.

Affected Systems

Linux kernel, any version without commit 2cd8231796b5 that introduces the temporary reallocation logic. All architectures that use the slub allocator are impacted.

Risk and Exploitability

The CVSS score is not listed; EPSS is not available and the vulnerability is not in the KEV catalog. Nevertheless, the buffer overflow can allow arbitrary code execution in kernel mode under suitable conditions. Attackers could trigger the flaw via crafted kernel allocations, such as by invoking krealloc_node_align with incompatible size or alignment, leading to memory corruption. Given the kernel context and lack of mitigation by default, the risk is considered high for systems exposing vulnerable allocations.

Generated by OpenCVE AI on May 27, 2026 at 17:07 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade the Linux kernel to a version that includes the patch from commit 2cd8231796b5, which corrects the size calculation and bounds copy lengths.
  • If an immediate kernel upgrade is not possible, audit and restrict any code paths that call krealloc or krealloc_node_align, ensuring they do not use forced alignment or node parameters unless necessary, or replace them with safe allocation abstractions.
  • Monitor kernel logs for kfence or memory corruption events and apply memory-protection hardening such as SMEP, SMAP, and page table isolation to reduce the impact of any residual vulnerability.

Generated by OpenCVE AI on May 27, 2026 at 17:07 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Wed, 27 May 2026 17:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-119

Wed, 27 May 2026 14:15:00 +0000

Type Values Removed Values Added
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.
Title slub: fix data loss and overflow in krealloc()
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-05-27T12:55:42.572Z

Reserved: 2026-05-13T15:03:33.091Z

Link: CVE-2026-45990

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Awaiting Analysis

Published: 2026-05-27T14:17:16.527

Modified: 2026-05-27T14:48:03.013

Link: CVE-2026-45990

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-05-27T17:15:38Z

Weaknesses