From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 10B91128395 for ; Sun, 10 May 2026 14:45:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778424350; cv=none; b=LN+Kw8SzXBxtfsuZvWktZC3RyJKXkIY3LZislHtcUJjdEgzEQyVwdKqE4BoX8VtH35wtaoXreFM81ZCGcKPO+XfDLzRlZnmmMqyyUHTSdRUJgylQFU97aN4PhCMe6PWTesCYFqpGL0r8eYIM7pRX5+4087nJSXrkrZ7IOrzw1eE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778424350; c=relaxed/simple; bh=uvN/5ptO2FmDN/e/Ela/FkIB1rxI5dTFYaN6YMgFzck=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=h0NcC9Yygb6gExIZmYZzrCv5L/expy8iYcAoKPvBfedu/RXs8Frai7dAwK4i38aSpLi2LebKuTCAeBVuSGppcc1Hz5EmEbWjqi3a0rektEZpr/982ufBNAOfKJFpoYs02W7VYKWMRzz1PywxMH2Oy8OYtNGVNPrLnqvx9e001SU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RoMoVm6v; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="RoMoVm6v" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6D8BCC2BCB8; Sun, 10 May 2026 14:45:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778424349; bh=uvN/5ptO2FmDN/e/Ela/FkIB1rxI5dTFYaN6YMgFzck=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=RoMoVm6v32guMahx3/HOHwBioVrUkVaSR8wMtmjc/Dd4BL1RNfxhtUUr7n8ILx7AX u6Y6t9vxp7dtRkH09q5z/HcY/N8ba1iLwbWVQkGww3+Z2yuFb8UQts6vEy13CdomML pBaNBPSwvVLT1hGWQQyj9LZHekDS0r8iR411lGFvD1cj0H2ttkLtes8OfzlOc+NFi8 n1VMf1qlGe+FUMgBxCYl750tDLOaXNOjuMwQFQYR80OCViAiBW5GYxIgs/JAS6jt60 XxMUzClQn676s0I90/Qw4fOvEhekYO4p3WFh1rFAoo5o1gnlnXluuTZy39+QfgH4IV f1/6LxjswfJDg== Date: Sun, 10 May 2026 17:45:40 +0300 From: Mike Rapoport To: Breno Leitao Cc: Waiman Long , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , K Prateek Nayak , Frederic Weisbecker , linux-kernel@vger.kernel.org Subject: Re: [PATCH] sched/isolation: Don't free memblock allocated cpumasks Message-ID: References: <20260505051821.1107133-1-longman@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Hi Breno, On Fri, May 08, 2026 at 07:19:06AM -0700, Breno Leitao wrote: > 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(). Oops, somehow I overlooked that late freeing can't access memblock arrays :( Can you please test this fix: diff --git a/mm/memblock.c b/mm/memblock.c index a6a1c91e276d..ccd43f3abb82 100644 --- a/mm/memblock.c +++ b/mm/memblock.c @@ -989,13 +989,15 @@ void __init_memblock memblock_free(void *ptr, size_t size) int __init_memblock memblock_phys_free(phys_addr_t base, phys_addr_t size) { phys_addr_t end = base + size - 1; - int ret; + int ret = 0; memblock_dbg("%s: [%pa-%pa] %pS\n", __func__, &base, &end, (void *)_RET_IP_); kmemleak_free_part_phys(base, size); - ret = memblock_remove_range(&memblock.reserved, base, size); + + if (!slab_is_available() || IS_ENABLED(CONFIG_ARCH_KEEP_MEMBLOCK)) + ret = memblock_remove_range(&memblock.reserved, base, size); if (slab_is_available()) __free_reserved_area(base, base + size, -1); -- Sincerely yours, Mike.