]> git.ipfire.org Git - thirdparty/kernel/linux.git/commit
arm64: mm: Check for pud_/pmd_set_huge() failures on kernel mappings
authorArd Biesheuvel <ardb@kernel.org>
Fri, 29 May 2026 15:01:54 +0000 (17:01 +0200)
committerWill Deacon <will@kernel.org>
Tue, 2 Jun 2026 15:29:15 +0000 (16:29 +0100)
commit8dd640d9233dd1fdd649920fe1f7fce78a8b40fa
tree3ea340b7f3963cc7f68a6cc0cf0133cc99c365cb
parent2e527667a3b9b17833ea82c81bb9da649eb3e50e
arm64: mm: Check for pud_/pmd_set_huge() failures on kernel mappings

Sashiko reports:

| If pmd_set_huge() rejects an unsafe page table transition (such as
| mapping a different physical address over an existing block mapping),
| it returns 0 and leaves the page table entry unmodified.
|
| Because *pmdp remains unmodified, READ_ONCE(pmd_val(*pmdp)) will equal
| pmd_val(old_pmd). The transition from old_pmd to old_pmd is evaluated
| as safe by pgattr_change_is_safe(), so the BUG_ON never triggers.
|
| This allows invalid and unsafe mapping updates to be silently dropped
| instead of panicking, leaving stale memory mappings active while the
| caller assumes the update was successful.

The same applies to pud_set_huge() in alloc_init_pud().

Given how it is generally preferred to limp on rather than blow up the
system if an unexpected condition such as this one occurs, and the fact
that there are no known cases where this disparity results in real
problems, let's WARN on these failures rather than BUG, allowing the
system to survive to the point where it can actually report them.

Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
arch/arm64/mm/mmu.c