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

[syzbot]

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

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/c5963fdd6790/disk-38872197.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/a8c2cab00c45/vmlinux-38872197.xz
kernel image: https://storage.googleapis.com/syzbot-assets/bde15d173380/Image-38872197.gz.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/c81cc2849c33/mount_3.gz
fsck result: failed (log: https://syzkaller.appspot.com/x/fsck.log?x=11cb4405580000)

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+c181d3...@syzkaller.appspotmail.com

------------[ cut here ]------------
WARNING: ./include/linux/pagemap.h:1130 at vma_flags_is_cow_mapping include/linux/mm.h:2315 [inline], CPU#1: syz.0.17/4884
WARNING: ./include/linux/pagemap.h:1130 at vma_is_cow_mapping include/linux/mm.h:2329 [inline], CPU#1: syz.0.17/4884
WARNING: ./include/linux/pagemap.h:1130 at linear_anon_page_index include/linux/pagemap.h:1130 [inline], CPU#1: syz.0.17/4884
WARNING: ./include/linux/pagemap.h:1130 at __folio_set_anon+0x240/0x298 mm/rmap.c:1491, CPU#1: syz.0.17/4884
Modules linked in:
CPU: 1 UID: 0 PID: 4884 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/14/2026
pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
pc : linear_anon_page_index include/linux/mm.h:2315 [inline]
pc : __folio_set_anon+0x240/0x298 mm/rmap.c:1491
lr : vma_flags_is_cow_mapping include/linux/mm.h:2315 [inline]
lr : vma_is_cow_mapping include/linux/mm.h:2329 [inline]
lr : linear_anon_page_index include/linux/pagemap.h:1130 [inline]
lr : __folio_set_anon+0x240/0x298 mm/rmap.c:1491
sp : ffff800095456de0
x29: ffff800095456df0 x28: 0000000000020000 x27: 1fffe00019e1007c
x26: ffff0000cf0803e0 x25: 0000000000020000 x24: dfff800000000000
x23: 0000000020000000 x22: 0000000000000000 x21: 00000000200020d1
x20: ffff0000cf0803c0 x19: fffffdffc3c10000 x18: 00000000ffffffff
x17: 0000000000000003 x16: ffff800088b97000 x15: ffff80008a849000
x14: 000000000062064d x13: 0000000000000001 x12: 0000000000000000
x11: 0000000000000000 x10: 000000000000003d x9 : 0000000000000000
x8 : 0000000000000000 x7 : ffff800080c16020 x6 : 0000000000000000
x5 : 0000000000000000 x4 : 0000000000000001 x3 : ffff800080ab2d0c
x2 : 0000000000000000 x1 : ffff0000d07a1d80 x0 : 0000000000000000
Call trace:
vma_flags_is_cow_mapping include/linux/mm.h:2315 [inline] (P)
vma_is_cow_mapping include/linux/mm.h:2329 [inline] (P)
linear_anon_page_index include/linux/pagemap.h:1130 [inline] (P)
__folio_set_anon+0x240/0x298 mm/rmap.c:1491 (P)
folio_add_new_anon_rmap+0x1a8/0x10ac mm/rmap.c:1663
map_anon_folio_pmd_nopf+0xfc/0x160 mm/huge_memory.c:1365
collapse_huge_page mm/khugepaged.c:1438 [inline]
mthp_collapse mm/khugepaged.c:1532 [inline]
collapse_scan_pmd mm/khugepaged.c:1781 [inline]
collapse_single_pmd+0x21e0/0x3748 mm/khugepaged.c:2797
madvise_collapse+0x2a4/0x6f4 mm/khugepaged.c:3231
madvise_vma_behavior+0x3e8/0x339c mm/madvise.c:1372
madvise_walk_vmas+0x4c8/0x9bc mm/madvise.c:1721
madvise_do_behavior+0x5f0/0x7c0 mm/madvise.c:1916
do_madvise+0x28c/0x2f0 mm/madvise.c:2014
__do_sys_madvise mm/madvise.c:2023 [inline]
__se_sys_madvise mm/madvise.c:2021 [inline]
__arm64_sys_madvise+0xac/0xc8 mm/madvise.c:2021
__invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]
invoke_syscall+0x98/0x244 arch/arm64/kernel/syscall.c:49
el0_svc_common+0xec/0x23c arch/arm64/kernel/syscall.c:121
do_el0_svc+0x4c/0x5c arch/arm64/kernel/syscall.c:140
el0_svc+0x64/0x260 arch/arm64/kernel/entry-common.c:758
el0t_64_sync_handler+0x44/0x104 arch/arm64/kernel/entry-common.c:777
el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:590
irq event stamp: 1412
hardirqs last enabled at (1411): [<ffff8000869b7264>] __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:210 [inline]
hardirqs last enabled at (1411): [<ffff8000869b7264>] _raw_spin_unlock_irqrestore+0x38/0x98 kernel/locking/spinlock.c:221
hardirqs last disabled at (1412): [<ffff800086991a8c>] el1_brk64+0x20/0x54 arch/arm64/kernel/entry-common.c:445
softirqs last enabled at (1120): [<ffff80008013c050>] local_bh_enable include/linux/bottom_half.h:33 [inline]
softirqs last enabled at (1120): [<ffff80008013c050>] put_cpu_fpsimd_context arch/arm64/kernel/fpsimd.c:251 [inline]
softirqs last enabled at (1120): [<ffff80008013c050>] fpsimd_restore_current_state+0x39c/0x9c8 arch/arm64/kernel/fpsimd.c:1797
softirqs last disabled at (1118): [<ffff80008013bcf8>] local_bh_disable include/linux/bottom_half.h:20 [inline]
softirqs last disabled at (1118): [<ffff80008013bcf8>] get_cpu_fpsimd_context arch/arm64/kernel/fpsimd.c:234 [inline]
softirqs last disabled at (1118): [<ffff80008013bcf8>] fpsimd_restore_current_state+0x44/0x9c8 arch/arm64/kernel/fpsimd.c:1790
---[ end trace 0000000000000000 ]---


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

[Lance Yang]

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
MAP_SHARED | PROT_READ. do_mmap() clears VM_SHARED and VM_MAYWRITE, so
mmap_zero_prepare() marks the VMA anonymous. MADV_COLLAPSE then allocates
a new folio and adds an anon rmap, hitting the warning in
linear_anon_page_index().

Can an anonymous VMA without VM_MAYWRITE legitimately have an anon rmap?

Cheers, Lance

[David Hildenbrand (Arm)]

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)

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?)

> mmap_zero_prepare() marks the VMA anonymous. MADV_COLLAPSE then allocates
> a new folio and adds an anon rmap, hitting the warning in
> linear_anon_page_index().
>
> Can an anonymous VMA without VM_MAYWRITE legitimately have an anon rmap?

It's not a COW mapping (by definition) so we don't expect anonymous folios in there.

--
Cheers,

David

[David Hildenbrand (Arm)]

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 :)

--
Cheers,

David

[Lorenzo Stoakes (ARM)]

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.)

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.

>
> --
> Cheers,
>
> David

--
Cheers, Lorenzo

[Lance Yang]

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!