Re: [syzbot] [mm?] WARNING in v9fs_fid_get_acl (2)

Re: [syzbot] [mm?] WARNING in v9fs_fid_get_acl (2)

[Andrew Morton]

On Fri, 18 Sep 2026 22:07:23 -0700 syzbot <syzbot+de6fd6789748a8aa64a0@syzkaller.appspotmail.com> wrote:

> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    587858367581 Merge tag 'nfsd-7.3-1' of git://git.kernel.or..
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1361a115580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=8c5c3949d762a91f
> dashboard link: https://syzkaller.appspot.com/bug?extid=de6fd6789748a8aa64a0
> compiler:       gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=11f64df9580000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=10e1a115580000
> 
> Downloadable assets:
> disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-58785836.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/f8460d7438eb/vmlinux-58785836.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/551bf08b9af2/bzImage-58785836.xz
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+de6fd6789748a8aa64a0@syzkaller.appspotmail.com
> 
> ------------[ cut here ]------------
> 1
> WARNING: mm/page_alloc.c:5340 at alloc_order_allowed mm/page_alloc.c:5340 [inline], CPU#0: syz.1.357/7872
> WARNING: mm/page_alloc.c:5340 at __alloc_frozen_pages_noprof+0x2137/0x3300 mm/page_alloc.c:5397, CPU#0: syz.1.357/7872

Thanks.  Caused by an old v9fs bug.  A fix was proposed but never merged:
https://lists.openwall.net/linux-kernel/2024/02/02/806?utm_source=chatgpt.com

> Modules linked in:
> CPU: 0 UID: 0 PID: 7872 Comm: syz.1.357 Not tainted syzkaller #0 PREEMPT(full) 
> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
> RIP: 0010:alloc_order_allowed mm/page_alloc.c:5340 [inline]
> RIP: 0010:__alloc_frozen_pages_noprof+0x2137/0x3300 mm/page_alloc.c:5397
> Code: 13 00 00 39 84 24 98 00 00 00 0f 85 4a fa ff ff e9 91 f6 ff ff 80 3d e2 93 bb 0e 00 0f 85 9d e2 ff ff c6 05 d5 93 bb 0e 01 90 <0f> 0b 90 e9 8d e2 ff ff 31 c0 e9 5f ec ff ff 48 8b 7c 24 08 48 c7
> RSP: 0018:ffffc90004df7758 EFLAGS: 00010246
> RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
> RDX: 0000000000000000 RSI: 0000000000000029 RDI: 0000000000040d40
> RBP: 0000000000000029 R08: 0000000000000000 R09: 0000000000000009
> R10: 0000000000000029 R11: 0000000000000000 R12: 0000000000040d40
> R13: 1ffff920009bef47 R14: 0000000000000000 R15: 1ffff920009bef05
> FS:  00007fc8804026c0(0000) GS:ffff8880d5b59000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007fc88037dff8 CR3: 0000000037685000 CR4: 0000000000352ef0
> Call Trace:
>  <TASK>
>  alloc_pages_mpol+0x201/0x550 mm/mempolicy.c:2486
>  ___kmalloc_large_node+0xe8/0x130 mm/slub.c:5353
>  __kmalloc_large_node_noprof+0x1c/0x70 mm/slub.c:5385
>  __do_kmalloc_node mm/slub.c:5402 [inline]
>  __kmalloc_noprof+0x5a8/0x840 mm/slub.c:5439
>  _kmalloc_noprof include/linux/slab.h:995 [inline]
>  _kzalloc_noprof include/linux/slab.h:1312 [inline]
>  v9fs_fid_get_acl+0x7a/0x120 fs/9p/acl.c:33
>  __v9fs_get_acl fs/9p/acl.c:67 [inline]
>  v9fs_get_acl+0xe8/0x480 fs/9p/acl.c:93
>  v9fs_qid_iget_dotl fs/9p/vfs_inode_dotl.c:131 [inline]
>  v9fs_inode_from_fid_dotl+0x26d/0x300 fs/9p/vfs_inode_dotl.c:154
>  v9fs_get_new_inode_from_fid fs/9p/v9fs.h:264 [inline]
>  v9fs_get_tree+0x55c/0xb50 fs/9p/vfs_super.c:120
>  vfs_get_tree+0x92/0x320 fs/super.c:1933
>  fc_mount fs/namespace.c:1198 [inline]
>  do_new_mount_fc fs/namespace.c:3772 [inline]
>  do_new_mount fs/namespace.c:3848 [inline]
>  path_mount+0x7d0/0x24c0 fs/namespace.c:4168
>  do_mount fs/namespace.c:4181 [inline]
>  __do_sys_mount fs/namespace.c:4397 [inline]
>  __se_sys_mount fs/namespace.c:4374 [inline]
>  __x64_sys_mount+0x293/0x310 fs/namespace.c:4374
>  do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
>  do_syscall_64+0x123/0x790 arch/x86/entry/syscall_64.c:84
>  entry_SYSCALL_64_after_hwframe+0x77/0x7f
> RIP: 0033:0x7fc87f59e159
> Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
> RSP: 002b:00007fc880402028 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
> RAX: ffffffffffffffda RBX: 00007fc87f825fa0 RCX: 00007fc87f59e159
> RDX: 0000200000000240 RSI: 0000200000000200 RDI: 0000000000000000
> RBP: 00007fc87f63503b R08: 0000200000000180 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
> R13: 00007fc87f826038 R14: 00007fc87f825fa0 R15: 00007ffeeb3b2c38
>  </TASK>
> 
> 
> ---
> 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

Re: [syzbot] [mm?] WARNING in v9fs_fid_get_acl (2)

[Dominique Martinet]

(+Nguyen in Cc as he tried resending sloppy patches after this)

Andrew Morton wrote on Sat, Sep 19, 2026 at 03:14:51AM -0700:
> > WARNING: mm/page_alloc.c:5340 at alloc_order_allowed mm/page_alloc.c:5340 [inline], CPU#0: syz.1.357/7872
> > WARNING: mm/page_alloc.c:5340 at __alloc_frozen_pages_noprof+0x2137/0x3300 mm/page_alloc.c:5397, CPU#0: syz.1.357/7872
> 
> Thanks.  Caused by an old v9fs bug.  A fix was proposed but never merged:
> https://lists.openwall.net/linux-kernel/2024/02/02/806?utm_source=chatgpt.com

Right, we've been going in circle with this since forever, and nobody
answered Christian Schoenebeck's question[1] about what the limit should
be, and while I don't care much ultimately I sort of agree with him
(e.g. limit should be XATTR_SIZE_MAX for anything that the VFS layer
touches, but acl are converted within the 9p subsystem and could be
arbitrarily large so status quo of a KMALLOC_MAX_SIZE limit because they
could come from something else)

Andrew, if you have an opinion on whether we should cap the acl sizes
anyway, please say...

[1] https://lore.kernel.org/all/Z1n-Ue19Pa_AWVu0@codewreck.org/T/#md7c1e009696501b3b87940cb613150bdebd1db28


-- 
Dominique Martinet | Asmadeus

Re: [syzbot] [mm?] WARNING in v9fs_fid_get_acl (2)

[Andrew Morton]

On Tue, 22 Sep 2026 17:45:14 +0900 Dominique Martinet <asmadeus@codewreck.org> wrote:

> (+Nguyen in Cc as he tried resending sloppy patches after this)
> 
> Andrew Morton wrote on Sat, Sep 19, 2026 at 03:14:51AM -0700:
> > > WARNING: mm/page_alloc.c:5340 at alloc_order_allowed mm/page_alloc.c:5340 [inline], CPU#0: syz.1.357/7872
> > > WARNING: mm/page_alloc.c:5340 at __alloc_frozen_pages_noprof+0x2137/0x3300 mm/page_alloc.c:5397, CPU#0: syz.1.357/7872
> > 
> > Thanks.  Caused by an old v9fs bug.  A fix was proposed but never merged:
> > https://lists.openwall.net/linux-kernel/2024/02/02/806?utm_source=chatgpt.com
> 
> Right, we've been going in circle with this since forever, and nobody
> answered Christian Schoenebeck's question[1] about what the limit should
> be, and while I don't care much ultimately I sort of agree with him
> (e.g. limit should be XATTR_SIZE_MAX for anything that the VFS layer
> touches, but acl are converted within the 9p subsystem and could be
> arbitrarily large so status quo of a KMALLOC_MAX_SIZE limit because they
> could come from something else)
> 
> Andrew, if you have an opinion on whether we should cap the acl sizes
> anyway, please say...

whome.  Well, if the converted ACLs can be large and it's hard to
figure out how large then yes, some pre-canned limit is difficult.  So
it's OK to leave the decision up to kmalloc() and just put a (nicely
commented!) __GFP_NOWARN in there.

otoh, if we're permitting workloads to trigger a large number of large
allocations then that might be a problem from a utilization or even DoS
point of view.