From nobody Fri Jun 12 20:22:24 2026 Received: from m16.mail.163.com (m16.mail.163.com [220.197.31.2]) (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 92386311C2A for ; Wed, 13 May 2026 01:03:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=220.197.31.2 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778634215; cv=none; b=L9fpJP9n7me1jeAEMVrU6bnJ/Gclfs5PUpxY2YJzD7CE9oqRN5/hIgo05q5IadLYCyQPbc7f9hkMobSDeEWq88/1/vHGdg0vjH7TebebXqXgwhJZwts4TbRZ3cWZrUQ9UK+cjf7tjvCcFiR+U9iqLh9lohoP9N88Qd2uobnRfd8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778634215; c=relaxed/simple; bh=hBRMcyWQ6N1Fhcz+UvmV7gx87uhujhTK65Jl+30UMwQ=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version:Content-Type; b=EJ4j1E5fSs8T57w539mklT46jO9dwFzJO9Xk25DOdT95l4Hk0zOE/uJpZE9LmccGWLFNLlZeMN/lmIqq4uGy1XzEl3L8bnrOuC4PBBlPsen4aE7LNKAMDDYpQ8s9H7X8/jJl8wdMkgmdbNyXNm8tDBWXpjbDNyWr0+bKUFSvDIE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com; spf=pass smtp.mailfrom=163.com; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b=iK722dMg; arc=none smtp.client-ip=220.197.31.2 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=163.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b="iK722dMg" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=From:To:Subject:Date:Message-Id:MIME-Version: Content-Type; bh=iWOMFoOs5ZLB23ex2t3PflHDKuzpdvnCncHsvkS8LTU=; b=iK722dMgsK6yDVjlZkJn+BP2CbLApDyDAsda7/SH2VgEorS27xqd2l+CfYC6ub 58NUpOqV7hFVcXipuEDIGVLTOoLDCXgu1pcq560MSqJh3yGW73i16Eeg7paWs7GJ HfwJT9oADQJvFVAafzmNo4R4wAU78Tfvcew+y1PB/j0ZE= Received: from server227.. (unknown []) by gzga-smtp-mtada-g1-1 (Coremail) with SMTP id _____wBn222_zQNq_ZQcBA--.5332S2; Wed, 13 May 2026 09:02:55 +0800 (CST) From: liulhong617@163.com To: catalin.marinas@arm.com, will@kernel.org Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, liulhong617 Subject: [PATCH] arm64: mm: fix accidental linear mapping of no-map reserved memory Date: Wed, 13 May 2026 09:02:55 +0800 Message-Id: <20260513010255.3764038-1-liulhong617@163.com> X-Mailer: git-send-email 2.34.1 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 X-CM-TRANSID: _____wBn222_zQNq_ZQcBA--.5332S2 X-Coremail-Antispam: 1Uf129KBjvJXoWxWr4ktrWxtr15Zw4UAw1xuFg_yoW5Cw13p3 y8GFn8Cr4jqryIq3ySy34DXrn5Zan3tF45JFsIkryjyFs8WFya9F4xC3W2gryjyayxZr1Y gr42ya4UWr15ZaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07jOZ2-UUUUU= X-CM-SenderInfo: holxzxxrqjliqx6rljoofrz/xtbC+h-9WGoDzb+uCQAA38 From: liulhong617 When reserved-memory regions with the "no-map" property are not page-aligned, the kernel may accidentally map them into the linear mapping, contradicting the no-map semantics. The root cause is a mismatch between /proc/iomem's address boundaries and the actual page table mapping boundaries: 1. /proc/iomem derives its ranges from memblock via memblock_region_reserved_base_pfn/memblock_region_reserved_end_pfn, which perform PFN rounding so the displayed boundaries are page-aligned. This gives the impression that the no-map region occupies whole pages. 2. However, memblock_mark_nomap() splits memblock.memory regions at exact byte boundaries (memblock_isolate_range preserves raw DT base/size with no alignment). When for_each_mem_range iterates the non-NOMAP regions adjacent to a no-map region, it returns start/end values that are NOT page-aligned =E2=80=94 they are the precise byte boundaries from the memblock split. 3. These sub-page-aligned values are passed to __create_pgd_mapping_locked(), which does: phys &=3D PAGE_MASK; addr =3D virt & PAGE_MASK; end =3D PAGE_ALIGN(virt + size); The downward rounding of phys via PAGE_MASK extends the mapped range backward into the adjacent no-map region, effectively including no-map memory in the linear mapping. For example, with 64K pages, reserved_region@A2000000 (base=3D0xA2000000, size=3D0x8000, no-map) causes for_each_mem_range to return start=3D0xA2008000 for the next mappable region. After phys &=3D PAGE_MASK, the actual mapping starts at 0xA2000000 =E2=80=94 the entire no-map region = is incorrectly mapped. Fix this by rounding the mappable range inward to PAGE_SIZE boundaries before passing it to __map_memblock: start is rounded UP and end is rounded DOWN. This ensures the mapped area never overlaps with adjacent no-map regions. The cost is at most one page of unmapped gap at each boundary, which is preferable to violating no-map semantics. Signed-off-by: liulhong617 --- arch/arm64/mm/mmu.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c index dd85e093f..bc8ac7622 100644 --- a/arch/arm64/mm/mmu.c +++ b/arch/arm64/mm/mmu.c @@ -1175,6 +1175,20 @@ static void __init map_mem(pgd_t *pgdp) for_each_mem_range(i, &start, &end) { if (start >=3D end) break; + /* + * for_each_mem_range may return sub-page-aligned boundaries + * after memblock_mark_nomap() splits regions at byte precision. + * __create_pgd_mapping_locked aligns phys down to PAGE_MASK, + * which could accidentally map no-map memory on the boundary. + * Round the mappable range inward: start UP, end DOWN, so + * that the mapped area never overlaps with adjacent no-map + * regions. The cost is at most one page of unmapped gap at + * each boundary. + */ + start =3D PAGE_ALIGN(start); + end =3D end & PAGE_MASK; + if (start >=3D end) + continue; /* * The linear map must allow allocation tags reading/writing * if MTE is present. Otherwise, it has the same attributes as --=20 2.34.1