CVE-2026-45990

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> slub: fix data loss and overflow in krealloc()<br /> <br /> Commit 2cd8231796b5 ("mm/slub: allow to set node and align in<br /> k[v]realloc") introduced the ability to force a reallocation if the<br /> original object does not satisfy new alignment or NUMA node, even when<br /> the object is being shrunk.<br /> <br /> This introduced two bugs in the reallocation fallback path:<br /> <br /> 1. Data loss during NUMA migration: The jump to &amp;#39;alloc_new&amp;#39; happens<br /> before &amp;#39;ks&amp;#39; and &amp;#39;orig_size&amp;#39; are initialized. As a result, the<br /> memcpy() in the &amp;#39;alloc_new&amp;#39; block would copy 0 bytes into the new<br /> allocation.<br /> <br /> 2. Buffer overflow during shrinking: When shrinking an object while<br /> forcing a new alignment, &amp;#39;new_size&amp;#39; is smaller than the old size.<br /> However, the memcpy() used the old size (&amp;#39;orig_size ?: ks&amp;#39;), leading<br /> to an out-of-bounds write.<br /> <br /> The same overflow bug exists in the kvrealloc() fallback path, where the<br /> old bucket size ksize(p) is copied into the new buffer without being<br /> bounded by the new size.<br /> <br /> A simple reproducer:<br /> <br /> // e.g. add to lkdtm as KREALLOC_SHRINK_OVERFLOW<br /> while (1) {<br /> void *p = kmalloc(128, GFP_KERNEL);<br /> p = krealloc_node_align(p, 64, 256, GFP_KERNEL, NUMA_NO_NODE);<br /> kfree(p);<br /> }<br /> <br /> demonstrates the issue:<br /> <br /> ==================================================================<br /> BUG: KFENCE: out-of-bounds write in memcpy_orig+0x68/0x130<br /> <br /> Out-of-bounds write at 0xffff8883ad757038 (120B right of kfence-#47):<br /> memcpy_orig+0x68/0x130<br /> krealloc_node_align_noprof+0x1c8/0x340<br /> lkdtm_KREALLOC_SHRINK_OVERFLOW+0x8c/0xc0 [lkdtm]<br /> lkdtm_do_action+0x3a/0x60 [lkdtm]<br /> ...<br /> <br /> kfence-#47: 0xffff8883ad756fc0-0xffff8883ad756fff, size=64, cache=kmalloc-64<br /> <br /> allocated by task 316 on cpu 7 at 97.680481s (0.021813s ago):<br /> krealloc_node_align_noprof+0x19c/0x340<br /> lkdtm_KREALLOC_SHRINK_OVERFLOW+0x8c/0xc0 [lkdtm]<br /> lkdtm_do_action+0x3a/0x60 [lkdtm]<br /> ...<br /> ==================================================================<br /> <br /> Fix it by moving the old size calculation to the top of __do_krealloc()<br /> and bounding all copy lengths by the new allocation size.