Re: [syzbot] [mm?] [ext4?] WARNING in __folio_set_anon

[Lance Yang <lance.yang@linux.dev>]

On 2026/9/24 16:52, Lorenzo Stoakes (ARM) wrote:
> On Thu, Sep 24, 2026 at 09:50:02AM +0200, David Hildenbrand (Arm) wrote:
>> On 9/24/26 09:43, David Hildenbrand (Arm) wrote:
>>> On 9/24/26 08:54, Lance Yang wrote:
>>>>
>>>> On Wed, Sep 23, 2026 at 10:00:37PM -0700, syzbot wrote:
>>>>> Hello,
>>>>>
>>>>> syzbot found the following issue on:
>>>>>
>>>>> HEAD commit:    38872197cae2 Merge branch 'for-next/fixes' into for-kernelci
>>>>> git tree:       git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci
>>>>> console output: https://syzkaller.appspot.com/x/log.txt?x=17a44d25580000
>>>>> kernel config:  https://syzkaller.appspot.com/x/.config?x=56ed23170c168d4c
>>>>> dashboard link: https://syzkaller.appspot.com/bug?extid=c181d3198e98f8aef8b9
>>>>> compiler:       Debian clang version 22.1.8 (++20260613092233+e80beda6e255-1~exp1~20260613092250.77), Debian LLD 22.1.8
>>>>> userspace arch: arm64
>>>>> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=16a36515580000
>>>>> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=16dcf4c9580000
>>>>
>>>> Looking at the repro, emm ... the repro maps an O_RDONLY /dev/zero fd with
>>>
>>> Does this trigger upstream or only after Lorenzo's rework (not upstream yet IIRC)
> 
> It'd trigger with my make MAP_PRIVATE-/dev/zero true anon stuff too yes.
> 
>>>
>>> 46827ac1ab221 mm/vma: make MAP_PRIVATE-mapped /dev/zero mappings truly anonymous
>>> db7438ea23180 mm/vma: only permit MAP_PRIVATE /dev/zero to be mapped anonymous
>>> 54e8e096ea86b mm: implement file_is_dev_zero() to uniquely identify /dev/zero
>>> fb24843cfd9eb mm: move drivers/char/mem.c to mm/char-mem.c
>>>
>>> I assume it triggers upstream. Does it also trigger with lorenzo's changes?
>>>
>>>> MAP_SHARED | PROT_READ. do_mmap() clears VM_SHARED and VM_MAYWRITE, so
>>>
>>> Clearing VM_MAYWRITE for a private mapping is odd. Can you point me at the code
>>> that clears both things?
>>>
>>> I assume we still have the file pointer, and as the file is read-only we remove
>>> VM_MAYWRITE. But why are we removing MAP_SHARED? (where?)
>>
>> Looking at the code, it's the
>>
>> 	if (!(file->f_mode & FMODE_WRITE))
>> 		vma_flags_clear(&vma_flags, VMA_MAYWRITE_BIT, VMA_SHARED_BIT);
>>
>> So we end up with VMA_MAYSHARE_BIT but without VMA_MAYWRITE_BIT and without
>> VMA_SHARED_BIT.
>>
>> So it's by definition not a COW mapping. But it's marked anonymous and confuses
>> the system :)
> 
> This is definitely a bug. And I added these asserts specifically to find
> bugs like this with anon mappings:
> 
> 	VM_WARN_ON_ONCE(!vma_is_cow_mapping(vma)); <-- fires
> 	if (vma_is_anonymous(vma))
> 		VM_WARN_ON_ONCE(pgoff != linear_page_index(vma, address)); <-- would have fired
> 
> It's because mmap_zero_prepare() keys off VMA_SHARED_BIT when it should be
> keying off the terribly-named VMA_MAYSHARE_BIT.
> 
> (VMA_MAYSHARE_BIT actually tells you if the mapping was mapped shared _in
> the first place_ specifically because of this clearing of VMA_SHARED_BIT,
> VMA_MAYWRITE_BIT.)

Cool! Using VMA_MAYSHARE_BIT instead of VMA_SHARED_BIT in 
mmap_zero_prepare()
should do the trick.

> 
> So it turns out forever a readonly /dev/zero shared mapping has quietly been
> converted to yet another variant of a 'special' anonymous mapping that we
> weren't even aware of.
> 
> And it's got an incorrect pgoff (but not anon pgoff now) as a result,
> similar to the usual MAP_PRIVATE-/dev/zero case.
> 
> So the solution is simple, check for VMA_MAYSHARE_BIT in
> mmap_zero_prepare(). The Fixes: will be in the sands of time.
> 
> I'll send a fix out.

Thanks, Lorenzo!

>>
>> --
>> Cheers,
>>
>> David
> 
> --
> Cheers, Lorenzo