Re: [PATCH] drivers/char/mem: mmap readonly MAP_SHARED-/dev/zero correctly

[Lance Yang]

On Thu, Sep 24, 2026 at 03:48:24PM +0100, Lorenzo Stoakes (ARM) wrote:
>Rather surprisingly, opening /dev/zero read-only then mmap()'ing it
>MAP_SHARED gets you true anonymous memory (albeit in a VMA with
>non-NULL vma->vm_file).
>
>This is a by-product of MAP_PRIVATE-/dev/zero being how anonymous memory
>was mapped in Linux's distant past.
>
>It happens because mmap_zero_prepare() gates on VMA_SHARED_BIT and when
>mapping a read-only file MAP_SHARED, do_mmap() clears VMA_SHARED_BIT and
>VMA_MAYWRITE_BIT.
>
>The gating is incorrect - the (poorly named) VMA_MAYSHARE_BIT flag exists
>explicitly to tell you if something was originally mapped MAP_SHARED.
>
>So the fix is simple - gate on this instead.
>
>This isn't exactly a common use case, but it's unexpected behaviour which
>now causes an assert if CONFIG_DEBUG_VM is set.
>
>While this bug has existed since the dawn of time for linux (or at least
>since 2.6.12), it hasn't caused issues in the past, so while it's incorrect
>behaviour, it doesn't seem necessary to backport that far.
>
>The mapping is now accounted at mmap time and can fail with -ENOMEM under
>strict overcommit, and read faults allocate folios. However this is normal
>behaviour for a read-only shmem mapping.
>
>Commit 93c0c8dc87f6 ("mm/rmap: use anon pgoff to track MAP_PRIVATE
>file-backed anon folios") is the first patch at which the debug assert
>fires, so target that instead.
>
>Fixes: 93c0c8dc87f6 ("mm/rmap: use anon pgoff to track MAP_PRIVATE file-backed anon folios")
>Reported-by: syzbot+c181d3198e98f8aef8b9@xxxxxxxxxxxxxxxxxxxxxxxxx
>Closes: https://lore.kernel.org/linux-mm/6ab4ae75.80e1c6cc.1e8e5f.000d.GAE@xxxxxxxxxx/
>Signed-off-by: Lorenzo Stoakes (ARM) <ljs@xxxxxxxxxx>
>---

Reviewed-by: Lance Yang <lance.yang@xxxxxxxxx>