From: Catalin Marinas <catalin.marinas@arm.com>
To: Zhao Gongyi <zhaogongyi@bytedance.com>
Cc: Will Deacon <will@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] arm64: mm: validate /dev/mem mmap ranges without overflow
Date: Tue, 3 Nov 2026 15:08:40 +0000 [thread overview]
Message-ID: <aun4-MXVMZNrmvGr@arm.com> (raw)
In-Reply-To: <20261101171030.87343-1-zhaogongyi@bytedance.com>
On Mon, Nov 02, 2026 at 01:10:30AM +0800, Zhao Gongyi wrote:
> An arm64 syzkaller reproducer creates a FUSE character device with
> major:minor 1:1, so opening it uses the /dev/mem file operations. It
> maps one page from offset 0xfffffffffffff000 at user address zero.
> The next openat() with a NULL pathname triggers a synchronous external
> abort (SEA, ESR 0x96000010) in strncpy_from_user() via do_getname(),
> panicking the kernel.
>
> valid_mmap_phys_addr_range() checks the exclusive end by adding the
> mapping size to the starting address. For this offset, the sum wraps
> to zero and passes the PHYS_MASK test, allowing an out-of-range PFN to
> reach remap_pfn_range(). The inclusive-end overflow check in
> mmap_mem_prepare() does not catch it because the end is ULONG_MAX.
>
> Reject starting PFNs outside PHYS_MASK and compare the inclusive length
> against the remaining physical range without overflowing. This also
> allows mappings that end exactly at PHYS_MASK, which the old check
> incorrectly rejects.
>
> Fixes: 1d18c47c735e ("arm64: MMU fault handling and page table management")
> Cc: stable@vger.kernel.org
> Signed-off-by: Zhao Gongyi <zhaogongyi@bytedance.com>
> ---
> Tested on the base commit with QEMU TCG and 52-bit LPA2:
> the overflowing one-page mapping changes from success to -EINVAL,
> while the last valid one- and two-page mappings change from -EINVAL to
> success. A direct /dev/mem mmap followed by openat(NULL) panics before
> this change; with the change, mmap fails with -EINVAL and openat()
> returns -EFAULT.
>
> arch/arm64/mm/mmap.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/mm/mmap.c b/arch/arm64/mm/mmap.c
> index 32e0771..d6286bc 100644
> --- a/arch/arm64/mm/mmap.c
> +++ b/arch/arm64/mm/mmap.c
> @@ -61,7 +61,12 @@ int valid_phys_addr_range(phys_addr_t addr, size_t size)
> */
> int valid_mmap_phys_addr_range(unsigned long pfn, size_t size)
> {
> - return !(((pfn << PAGE_SHIFT) + size) & ~PHYS_MASK);
> + const phys_addr_t max_addr = PHYS_MASK;
> +
> + if (!size || pfn > (max_addr >> PAGE_SHIFT))
> + return 0;
> +
> + return size - 1 <= max_addr - (pfn << PAGE_SHIFT);
> }
Can we write this as:
int valid_mmap_phys_addr_range(unsigned long pfn, size_t size)
{
phys_addr_t limit = PHYS_MASK + 1;
return size <= limit && pfn <= (limit - size) >> PAGE_SHIFT;
}
It would resemble the generic __access_ok() better where we need to
check for similar overflow. I find it easier to read.
(happy to make the change when applying)
--
Catalin
next prev parent reply other threads:[~2026-11-03 15:08 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-01 17:10 [PATCH] arm64: mm: validate /dev/mem mmap ranges without overflow Zhao Gongyi
2026-11-03 15:08 ` Catalin Marinas [this message]
2026-11-04 2:21 ` Zhao Gongyi
2026-11-04 19:04 ` Catalin Marinas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aun4-MXVMZNrmvGr@arm.com \
--to=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=will@kernel.org \
--cc=zhaogongyi@bytedance.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.