* [syzbot] [mm?] [ext4?] WARNING in __folio_set_anon
@ 2026-09-24 5:00 syzbot
2026-09-24 6:54 ` Lance Yang
0 siblings, 1 reply; 6+ messages in thread
From: syzbot @ 2026-09-24 5:00 UTC (permalink / raw)
To: akpm, david, harry, jannh, lance.yang, liam, linux-ext4,
linux-kernel, linux-mm, ljs, riel, syzkaller-bugs, vbabka
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+c181d3198e98f8aef8b9@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 syzkaller@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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [syzbot] [mm?] [ext4?] WARNING in __folio_set_anon
2026-09-24 5:00 [syzbot] [mm?] [ext4?] WARNING in __folio_set_anon syzbot
@ 2026-09-24 6:54 ` Lance Yang
2026-09-24 7:43 ` David Hildenbrand (Arm)
0 siblings, 1 reply; 6+ messages in thread
From: Lance Yang @ 2026-09-24 6:54 UTC (permalink / raw)
To: david, ljs, akpm
Cc: harry, jannh, lance.yang, liam, linux-ext4, linux-kernel,
linux-mm, riel, syzkaller-bugs, vbabka,
syzbot+c181d3198e98f8aef8b9
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
>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+c181d3198e98f8aef8b9@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 syzkaller@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
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [syzbot] [mm?] [ext4?] WARNING in __folio_set_anon
2026-09-24 6:54 ` Lance Yang
@ 2026-09-24 7:43 ` David Hildenbrand (Arm)
2026-09-24 7:50 ` David Hildenbrand (Arm)
0 siblings, 1 reply; 6+ messages in thread
From: David Hildenbrand (Arm) @ 2026-09-24 7:43 UTC (permalink / raw)
To: Lance Yang, ljs, akpm
Cc: harry, jannh, liam, linux-ext4, linux-kernel, linux-mm, riel,
syzkaller-bugs, vbabka, syzbot+c181d3198e98f8aef8b9
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [syzbot] [mm?] [ext4?] WARNING in __folio_set_anon
2026-09-24 7:43 ` David Hildenbrand (Arm)
@ 2026-09-24 7:50 ` David Hildenbrand (Arm)
2026-09-24 8:52 ` Lorenzo Stoakes (ARM)
0 siblings, 1 reply; 6+ messages in thread
From: David Hildenbrand (Arm) @ 2026-09-24 7:50 UTC (permalink / raw)
To: Lance Yang, ljs, akpm
Cc: harry, jannh, liam, linux-ext4, linux-kernel, linux-mm, riel,
syzkaller-bugs, vbabka, syzbot+c181d3198e98f8aef8b9
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)
>
> 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 :)
--
Cheers,
David
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [syzbot] [mm?] [ext4?] WARNING in __folio_set_anon
2026-09-24 7:50 ` David Hildenbrand (Arm)
@ 2026-09-24 8:52 ` Lorenzo Stoakes (ARM)
2026-09-24 9:27 ` Lance Yang
0 siblings, 1 reply; 6+ messages in thread
From: Lorenzo Stoakes (ARM) @ 2026-09-24 8:52 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: Lance Yang, akpm, harry, jannh, liam, linux-ext4, linux-kernel,
linux-mm, riel, syzkaller-bugs, vbabka,
syzbot+c181d3198e98f8aef8b9
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [syzbot] [mm?] [ext4?] WARNING in __folio_set_anon
2026-09-24 8:52 ` Lorenzo Stoakes (ARM)
@ 2026-09-24 9:27 ` Lance Yang
0 siblings, 0 replies; 6+ messages in thread
From: Lance Yang @ 2026-09-24 9:27 UTC (permalink / raw)
To: Lorenzo Stoakes (ARM), David Hildenbrand (Arm)
Cc: akpm, harry, jannh, liam, linux-ext4, linux-kernel, linux-mm,
riel, syzkaller-bugs, vbabka, syzbot+c181d3198e98f8aef8b9
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2026-09-24 9:27 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-09-24 5:00 [syzbot] [mm?] [ext4?] WARNING in __folio_set_anon syzbot
2026-09-24 6:54 ` Lance Yang
2026-09-24 7:43 ` David Hildenbrand (Arm)
2026-09-24 7:50 ` David Hildenbrand (Arm)
2026-09-24 8:52 ` Lorenzo Stoakes (ARM)
2026-09-24 9:27 ` Lance Yang
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®