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

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

[Lorenzo Stoakes (ARM)]

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@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/linux-mm/6ab4ae75.80e1c6cc.1e8e5f.000d.GAE@google.com/
Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
---
 drivers/char/mem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index 63253d1de5d7..5b93c92c2cf1 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -503,7 +503,7 @@ static int mmap_zero_prepare(struct vm_area_desc *desc)
 #ifndef CONFIG_MMU
 	return -ENOSYS;
 #endif
-	if (vma_desc_test(desc, VMA_SHARED_BIT))
+	if (vma_desc_test(desc, VMA_MAYSHARE_BIT))
 		return shmem_zero_setup_desc(desc);
 
 	/*

---
base-commit: 62f4c998b297cf233997a2b4cd6fc2d2df0319c9
change-id: 20260924-fix-dev-zero-readonly-shared-f2d46c156ce2

Best regards,
-- 
Lorenzo Stoakes (ARM) <ljs@kernel.org>

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

[Greg Kroah-Hartman]

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@syzkaller.appspotmail.com
> Closes: https://lore.kernel.org/linux-mm/6ab4ae75.80e1c6cc.1e8e5f.000d.GAE@google.com/
> Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
> ---
>  drivers/char/mem.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/char/mem.c b/drivers/char/mem.c
> index 63253d1de5d7..5b93c92c2cf1 100644
> --- a/drivers/char/mem.c
> +++ b/drivers/char/mem.c
> @@ -503,7 +503,7 @@ static int mmap_zero_prepare(struct vm_area_desc *desc)
>  #ifndef CONFIG_MMU
>  	return -ENOSYS;
>  #endif
> -	if (vma_desc_test(desc, VMA_SHARED_BIT))
> +	if (vma_desc_test(desc, VMA_MAYSHARE_BIT))
>  		return shmem_zero_setup_desc(desc);

What's the odds that something "big" actually relies on this?

I'm all for the change, but be prepared in about 5 years for people to
start complaining :)

Want me to take it through my tree?

thanks,

greg k-h

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

[Lorenzo Stoakes (ARM)]

On Thu, Sep 24, 2026 at 05:08:49PM +0200, Greg Kroah-Hartman wrote:
> 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@syzkaller.appspotmail.com
> > Closes: https://lore.kernel.org/linux-mm/6ab4ae75.80e1c6cc.1e8e5f.000d.GAE@google.com/
> > Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
> > ---
> >  drivers/char/mem.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/char/mem.c b/drivers/char/mem.c
> > index 63253d1de5d7..5b93c92c2cf1 100644
> > --- a/drivers/char/mem.c
> > +++ b/drivers/char/mem.c
> > @@ -503,7 +503,7 @@ static int mmap_zero_prepare(struct vm_area_desc *desc)
> >  #ifndef CONFIG_MMU
> >  	return -ENOSYS;
> >  #endif
> > -	if (vma_desc_test(desc, VMA_SHARED_BIT))
> > +	if (vma_desc_test(desc, VMA_MAYSHARE_BIT))
> >  		return shmem_zero_setup_desc(desc);
>
> What's the odds that something "big" actually relies on this?

I think it'd be fairly crazy to, unless people really care about read-faulting a
lot of zero pages which they want to somehow not account properly.

Anything's possible but I think on this, right to take a (v. small) risk!

>
> I'm all for the change, but be prepared in about 5 years for people to
> start complaining :)
>
> Want me to take it through my tree?

Sure, thanks, though there will be a conflict against a patch in mm.

Though it's really that the file is moved (to mm/), so actually should be an
easy resolution?

>
> thanks,
>
> greg k-h

--
Cheers, Lorenzo

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

[David Hildenbrand (Arm)]

On 9/24/26 16:48, 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@syzkaller.appspotmail.com
> Closes: https://lore.kernel.org/linux-mm/6ab4ae75.80e1c6cc.1e8e5f.000d.GAE@google.com/
> Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
> ---
>  drivers/char/mem.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/char/mem.c b/drivers/char/mem.c
> index 63253d1de5d7..5b93c92c2cf1 100644
> --- a/drivers/char/mem.c
> +++ b/drivers/char/mem.c
> @@ -503,7 +503,7 @@ static int mmap_zero_prepare(struct vm_area_desc *desc)
>  #ifndef CONFIG_MMU
>  	return -ENOSYS;
>  #endif
> -	if (vma_desc_test(desc, VMA_SHARED_BIT))
> +	if (vma_desc_test(desc, VMA_MAYSHARE_BIT))
>  		return shmem_zero_setup_desc(desc);
>  

So instead of shared zeropages we'd now get zero-filled shmem pages.

The alternative would be to just convert it to a proper read-only COW mapping in
mmap code:
* Not clearing VM_MAYWRITE, but keeping VM_WRITE clear
* Clearing VMA_SHARED and VMA_MAYSHARE

Sure, someone could then mprotect(PROT_WRITE that thing) or
FOLL_FORCE|FOLL_WRITE to get anonymous memory. Just raising that as an alternative.

-- 
Cheers,

David

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

[Greg Kroah-Hartman]

On Thu, Sep 24, 2026 at 04:29:23PM +0100, Lorenzo Stoakes (ARM) wrote:
> On Thu, Sep 24, 2026 at 05:08:49PM +0200, Greg Kroah-Hartman wrote:
> > 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@syzkaller.appspotmail.com
> > > Closes: https://lore.kernel.org/linux-mm/6ab4ae75.80e1c6cc.1e8e5f.000d.GAE@google.com/
> > > Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
> > > ---
> > >  drivers/char/mem.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/char/mem.c b/drivers/char/mem.c
> > > index 63253d1de5d7..5b93c92c2cf1 100644
> > > --- a/drivers/char/mem.c
> > > +++ b/drivers/char/mem.c
> > > @@ -503,7 +503,7 @@ static int mmap_zero_prepare(struct vm_area_desc *desc)
> > >  #ifndef CONFIG_MMU
> > >  	return -ENOSYS;
> > >  #endif
> > > -	if (vma_desc_test(desc, VMA_SHARED_BIT))
> > > +	if (vma_desc_test(desc, VMA_MAYSHARE_BIT))
> > >  		return shmem_zero_setup_desc(desc);
> >
> > What's the odds that something "big" actually relies on this?
> 
> I think it'd be fairly crazy to, unless people really care about read-faulting a
> lot of zero pages which they want to somehow not account properly.
> 
> Anything's possible but I think on this, right to take a (v. small) risk!
> 
> >
> > I'm all for the change, but be prepared in about 5 years for people to
> > start complaining :)
> >
> > Want me to take it through my tree?
> 
> Sure, thanks, though there will be a conflict against a patch in mm.
> 
> Though it's really that the file is moved (to mm/), so actually should be an
> easy resolution?

No problem, you can take it if that makes it easier:

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>