Re: [PATCH] sched/isolation: Don't free memblock allocated cpumasks

[Breno Leitao]

On Tue, May 05, 2026 at 01:18:21AM -0400, Waiman Long wrote:
> One workaround for now to avoid these warning/bug
> messages is to keep the memblock allocated cpumasks even if they are
> no longer needed until the memblock subsystem is properly updated to
> handle memblock_free().

We just hit the same KASAN UAF from a different caller on a v7.1-rc3 boot,
which I think reinforces that the fix really needs to be in memblock rather
than in each subsystem.

In our case the offender is the IMA kexec buffer release path:

    [  113.498542] BUG: KASAN: use-after-free in memblock_isolate_range+0x208/0x8f0
    [  113.514206] Read of size 8 at addr ff11001824ba4000 by task swapper/0/1
    ...
    [  113.532258]  memblock_isolate_range+0x208/0x8f0
    [  113.532267]  memblock_phys_free+0x5f/0x300
    [  113.532274]  ima_free_kexec_buffer+0x1d/0x40
    [  113.532280]  ima_load_kexec_buffer+0xbf/0xf0
    [  113.532285]  ima_init+0x42/0xa0
    [  113.532287]  init_ima+0x5e/0x190
    [  113.532290]  security_initcall_late+0xad/0x210
    [  113.532301]  do_one_initcall+0x138/0x540

Same shape as your second trace: memblock_phys_free() reads
memblock.reserved.regions, which memblock_discard() has already returned
to the buddy allocator (the KASAN shadow shows the page as fully poisoned,
and pfn 0x1824ba4 has been reallocated). It then page-faults a moment later
on the same address.

ima_init runs as a security_initcall_late, so by the time
ima_free_kexec_buffer() calls memblock_phys_free() on the previous
kernel's measurement buffer, memblock has long been torn down on
configurations without CONFIG_ARCH_KEEP_MEMBLOCK 

This regression seems to come from commit 87ce9e83ab8b ("memblock, treewide: make
memblock_free() handle late freeing"), which dropped memblock_free_late()
and made memblock_phys_free() unconditionally call
memblock_remove_range(&memblock.reserved, ...) followed by an optional
__free_reserved_area().