From nobody Sat Feb 7 15:12:37 2026 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 499A125BEF8 for ; Fri, 23 Jan 2026 20:55:46 +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=1769201747; cv=none; b=KdxB9kguA9uBe2DXgWKJPDk7/TNm0m8G8qxUaHF1j31uo/5s94FFivOb7aU/7wiPy8KeY8YZq01kr3odVYqC+ztckRiQazpyNF2BfdcOD95ta11+3C0OXU8WrsTfGHBWpdjp1PR46wsY6G0skwD24jNdxChiU9+ziu76rUW2quw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769201747; c=relaxed/simple; bh=MRLIJHMes6O1llUqkugm5ytuer8+s6cgNaGPzgrEq9U=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type; b=kMuFFMSjT4tIDgC0TWvDCVIONM20C/PTsHVEvzB9uxtvA4g+2Mt7On49ZsoE/Wjzgw2xm5tf4S0cEPliLjzfmGxFsYH6YEwpbdL/NHwIaLTwWrVVkOlMem/lABuNq14WGrIZiDiyXCPS7JqaIyKR4mbWDaD54J5zJFcnsctMJxQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=sS06KUKX; 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="sS06KUKX" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9ADDEC4CEF1; Fri, 23 Jan 2026 20:55:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769201746; bh=MRLIJHMes6O1llUqkugm5ytuer8+s6cgNaGPzgrEq9U=; h=From:To:Cc:Subject:Date:From; b=sS06KUKX/sttv1aAZEgo7bIfPUpctd1CZk53JrmyNARckS9LWxwiw6f5LWLdiKDT2 jGnctg2GFb/TSC6jQrGRXzCV3NTUzn6TwpeXv7Gy7unA5nMGP+JytGH7yeAg88tNxA myzW+r2amqWLf5l0udCOSqcWxEaQI9E+CmL/l5bxwGyY1qM9PBU8IWya0zRZz8vSxG AgNToFSwtjFcBuGGsfUqBH/CP8xEfS12OTieC9bsRGleFitlVQgjkxM7maBHgXs5Fs cvVLN8VBXWY2Eo8pXwkCfvFIHLMLqyG5yFLQVF0+/hcWFvCBO00Vya/6yXb6j1Jap3 io3sPYa9DAcjQ== From: Dennis Zhou To: Tejun Heo , Christoph Lameter , Andrew Morton Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Dennis Zhou , Sebastian Andrzej Siewior Subject: [PATCH v3] percpu: add double free check to pcpu_free_area() Date: Fri, 23 Jan 2026 12:55:35 -0800 Message-ID: <20260123205535.35267-1-dennis@kernel.org> X-Mailer: git-send-email 2.43.0 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="utf-8" Content-Transfer-Encoding: quoted-printable Percpu memory provides access via offsets into the percpu address space. Offsets are essentially fixed for the lifetime of a chunk and therefore require all users be good samaritans. If a user improperly handles the lifetime of the percpu object, it can result in corruption in a couple of ways: - immediate double free - breaks percpu metadata accounting - free after subsequent allocation - corruption due to multiple owner problem (either prior owner still writes or future allocation happens) - potential for oops if the percpu pages are reclaimed as the subsequent allocation isn't pinning the pages down - can lead to page->private pointers pointing to freed chunks Sebastian noticed that if this happens, none of the memory debugging facilities add additional information [2]. This patch aims to catch invalid free scenarios within valid chunks. To better guard free_percpu(), we can either add a magic number or some tracking facility to the percpu subsystem in a separate patch. The invalid free check in pcpu_free_area() validates that the allocation=E2=80=99s starting bit is set in both alloc_map and bound_map. T= he alloc_map bit test ensures the area is allocated while the bound_map bit test checks we are freeing from the beginning of an allocation. We choose not to check the validity of the offset as that is encoded in page->private being a valid chunk. pcpu_stats_area_dealloc() is moved later to only be on the happy path so stats are only updated on valid frees. This is a respin of [1] adding the requested changes from me and Christoph. [1] https://lore.kernel.org/linux-mm/20250904143514.Yk6Ap-jy@linutronix.de/ [2] https://lore.kernel.org/lkml/20260119074813.ecAFsGaT@linutronix.de/ Signed-off-by: Dennis Zhou Cc: Sebastian Andrzej Siewior --- v3: - Removed bit_off in bounds check because it's derived from the address passed in. If bit_off is bad, it's because we are getting a bad chunk from page->private. Let's do a better check on chunk validity in a=20 future patch probably behind a Kconfig. - Removed ratelimit in favor of WARN_ON_ONCE(1). mm/percpu.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/mm/percpu.c b/mm/percpu.c index 81462ce5866e..a2107bdebf0b 100644 --- a/mm/percpu.c +++ b/mm/percpu.c @@ -1279,12 +1279,16 @@ static int pcpu_free_area(struct pcpu_chunk *chunk,= int off) int bit_off, bits, end, oslot, freed; =20 lockdep_assert_held(&pcpu_lock); - pcpu_stats_area_dealloc(chunk); =20 oslot =3D pcpu_chunk_slot(chunk); =20 bit_off =3D off / PCPU_MIN_ALLOC_SIZE; =20 + /* check invalid free */ + if (!test_bit(bit_off, chunk->alloc_map) || + !test_bit(bit_off, chunk->bound_map)) + return 0; + /* find end index */ end =3D find_next_bit(chunk->bound_map, pcpu_chunk_map_bits(chunk), bit_off + 1); @@ -1303,6 +1307,8 @@ static int pcpu_free_area(struct pcpu_chunk *chunk, i= nt off) =20 pcpu_chunk_relocate(chunk, oslot); =20 + pcpu_stats_area_dealloc(chunk); + return freed; } =20 @@ -2242,6 +2248,13 @@ void free_percpu(void __percpu *ptr) =20 spin_lock_irqsave(&pcpu_lock, flags); size =3D pcpu_free_area(chunk, off); + if (size =3D=3D 0) { + spin_unlock_irqrestore(&pcpu_lock, flags); + + /* invalid percpu free */ + WARN_ON_ONCE(1); + return; + } =20 pcpu_alloc_tag_free_hook(chunk, off, size); =20 --=20 2.43.0