* [syzbot] [mm?] [fuse?] WARNING in shmem_initxattrs
@ 2026-11-05 11:10 syzbot
2026-11-05 16:27 ` Andrew Morton
0 siblings, 1 reply; 3+ messages in thread
From: syzbot @ 2026-11-05 11:10 UTC (permalink / raw)
To: akpm, baolin.wang, fuse-devel, hughd, linux-kernel, linux-mm,
syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: 05441d697f7f Merge tag 'cocci-7.4-rc1' of git://git.kernel..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=17bcaca1580000
kernel config: https://syzkaller.appspot.com/x/.config?x=1cf189394a856f11
dashboard link: https://syzkaller.appspot.com/bug?extid=4324f771847cecb27c54
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=14423cbe580000
Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-05441d69.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/0edd3964be19/vmlinux-05441d69.xz
kernel image: https://storage.googleapis.com/syzbot-assets/84d6d8dd5648/bzImage-05441d69.xz
AI-generated root cause summary:
In mm/shmem.c:shmem_initxattrs(), the initial reservation of inode xattr space
(ispace) from sbinfo->free_ispace is gated by 'if (sbinfo->max_inodes)', and
subsequent per-xattr subtraction from ispace is also gated by 'if
(sbinfo->max_inodes)'. Because sbinfo->max_inodes is accessed locklessly and can
be concurrently modified to 0 during a remount (shmem_reconfigure() with
nr_inodes=0), ispace can be reserved when max_inodes is non-zero, but fail to be
decremented when max_inodes becomes 0. Consequently, after all security xattrs
are successfully allocated and added, ispace remains non-zero, tripping the
WARN_ON(ispace) assertion.
full analysis: https://syzkaller.appspot.com/x/ai_root_cause?x=4324f771847cecb27c54
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+4324f771847cecb27c54@syzkaller.appspotmail.com
------------[ cut here ]------------
ispace
WARNING: mm/shmem.c:4451 at shmem_initxattrs+0x3f5/0x650 mm/shmem.c:4451, CPU#3: syz.1.18954/2882
Modules linked in:
CPU: 3 UID: 0 PID: 2882 Comm: syz.1.18954 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:shmem_initxattrs+0x3f5/0x650 mm/shmem.c:4451
Code: 03 80 3c 02 00 0f 85 5d 02 00 00 48 83 3b 00 0f 85 fd fc ff ff e8 6b 3b ae ff 4c 89 ee 31 ff e8 01 36 ae ff e8 5c 3b ae ff 90 <0f> 0b 90 e9 dd fe ff ff e8 4e 3b ae ff 4d 8d 7e 78 4c 89 ff e8 52
RSP: 0018:ffffc90007eefbb0 EFLAGS: 00010293
RAX: 0000000000000000 RBX: ffff888032b8d818 RCX: 0000000000000000
RDX: ffff888030c3cb00 RSI: ffffffff82602984 RDI: 0000000000000007
RBP: ffff888023be9000 R08: 0000000000000000 R09: 0000000000000053
R10: ffff888037378973 R11: 0000000000000000 R12: dffffc0000000000
R13: 0000000000000053 R14: ffff888054123400 R15: ffff888023be9030
FS: 00007f7a3de3d6c0(0000) GS:ffff8880d477c000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f7a3ddfaff8 CR3: 000000004e80f000 CR4: 0000000000352ef0
Call Trace:
<TASK>
security_inode_init_security+0x242/0x370 security/security.c:1384
shmem_mknod+0x2ce/0x480 mm/shmem.c:4039
shmem_mkdir+0x31/0x80 mm/shmem.c:4094
vfs_mkdir+0x36d/0x8a0 fs/namei.c:5428
filename_mkdirat+0x4c4/0x630 fs/namei.c:5461
__do_sys_mkdirat fs/namei.c:5482 [inline]
__se_sys_mkdirat fs/namei.c:5479 [inline]
__x64_sys_mkdirat+0x89/0xc0 fs/namei.c:5479
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:0x7f7a3cf9fb19
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:00007f7a3de3d028 EFLAGS: 00000246 ORIG_RAX: 0000000000000102
RAX: ffffffffffffffda RBX: 00007f7a3d226270 RCX: 00007f7a3cf9fb19
RDX: 00000000000001ff RSI: 0000200000000800 RDI: ffffffffffffff9c
RBP: 00007f7a3d037b70 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f7a3d226308 R14: 00007f7a3d226270 R15: 00007ffe3809a618
</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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [syzbot] [mm?] [fuse?] WARNING in shmem_initxattrs
2026-11-05 11:10 [syzbot] [mm?] [fuse?] WARNING in shmem_initxattrs syzbot
@ 2026-11-05 16:27 ` Andrew Morton
2026-11-05 16:47 ` syzbot
0 siblings, 1 reply; 3+ messages in thread
From: Andrew Morton @ 2026-11-05 16:27 UTC (permalink / raw)
To: syzbot
Cc: baolin.wang, fuse-devel, hughd, linux-kernel, linux-mm,
syzkaller-bugs, syzkaller, Miklos Szeredi, Christian Brauner
On Thu, 05 Nov 2026 03:10:43 -0800 syzbot <syzbot+4324f771847cecb27c54@syzkaller.appspotmail.com> wrote:
> syzbot found the following issue on:
>
> HEAD commit: 05441d697f7f Merge tag 'cocci-7.4-rc1' of git://git.kernel..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=17bcaca1580000
> kernel config: https://syzkaller.appspot.com/x/.config?x=1cf189394a856f11
> dashboard link: https://syzkaller.appspot.com/bug?extid=4324f771847cecb27c54
> 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=14423cbe580000
>
> Downloadable assets:
> disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-05441d69.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/0edd3964be19/vmlinux-05441d69.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/84d6d8dd5648/bzImage-05441d69.xz
>
> AI-generated root cause summary:
> In mm/shmem.c:shmem_initxattrs(), the initial reservation of inode xattr space
> (ispace) from sbinfo->free_ispace is gated by 'if (sbinfo->max_inodes)', and
> subsequent per-xattr subtraction from ispace is also gated by 'if
> (sbinfo->max_inodes)'. Because sbinfo->max_inodes is accessed locklessly and can
> be concurrently modified to 0 during a remount (shmem_reconfigure() with
> nr_inodes=0), ispace can be reserved when max_inodes is non-zero, but fail to be
> decremented when max_inodes becomes 0. Consequently, after all security xattrs
> are successfully allocated and added, ispace remains non-zero, tripping the
> WARN_ON(ispace) assertion.
>
> full analysis: https://syzkaller.appspot.com/x/ai_root_cause?x=4324f771847cecb27c54
Well that's convenient, thanks! Two additional suggestions:
- The Subject "[mm?] [fuse?]" can be tightened. I told my thing
figure out a Subject for this bug report - identify
the kernel subsystem which is primarily affected
and it responded
Subject: [BUG] shmem: xattr accounting warning when remount disables inode limits
- Use your LLM to figure out who to cc on the report:
figure out who should be cc'ed on this. Use the
MAINTAINERS entries for the affected files. Also use git to
figure out who has recently worked on the affected code. Prefer
to choose developers who have recently shown significant
involvement in kernel work.
and it replied
Cc: Hugh Dickins <hughd@google.com>
Cc: Baolin Wang <baolin.wang@linux.alibaba.com>
Cc: Miklos Szeredi <mszeredi@redhat.com>
Cc: Christian Brauner <brauner@kernel.org>
Cc: linux-mm@kvack.org
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: syzbot+4324f771847cecb27c54@syzkaller.appspotmail.com
Hugh and Baolin: the maintainer and reviewer listed under
TMPFS (SHMEM FILESYSTEM), which explicitly covers mm/shmem.c.
Baolin also has recent shmem fixes and substantial review
activity.
Miklos: the most directly relevant developer. Git
identifies him as author of 076e5cef28e27, "simple_xattr: change
interface to pass struct simple_xattrs", from June 2026.
Christian: committed that change and authored the preceding
rhashtable-based shmem xattr conversion. His involvement is
directly in this code, rather than merely elsewhere in
mm/shmem.c.
and, of course "fix the dang bug", I'll test this later.
#syz test
From: Andrew Morton <akpm@linux-foundation.org>
Subject: shmem: consume the reserved xattr space despite remount
Date: Thu, 05 Nov 2026 08:08:06 -0800
Creating a tmpfs inode can trigger WARN_ON(ispace) in shmem_initxattrs()
when a concurrent remount sets nr_inodes=0. With panic_on_warn enabled,
this warning can panic the machine.
shmem_initxattrs() reserves space for the security xattrs while inode
limits are enabled. It later tests max_inodes again before consuming that
reservation for each installed xattr. If remount disables the limit
between those steps, successfully installed xattrs leave a nonzero
reservation behind.
Use the remaining reservation, rather than the current mount policy, to
decide whether to subtract the installed xattr's space. This also leaves
the failure path with only the unconsumed reservation to refund.
An initially unlimited filesystem cannot acquire an inode limit through
remount: shmem_reconfigure() rejects that transition.
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reported-by: <syzbot+4324f771847cecb27c54@syzkaller.appspotmail.com>
Closes: https://syzkaller.appspot.com/bug?extid=4324f771847cecb27c54
---
Test candidate against 05441d697f7f9a927264f4058cbbc6a03dfcac9d.
Application checked; no kernel build or runtime reproduction performed.
Fixes attribution and stable-backport scope have not yet been verified.
mm/shmem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/mm/shmem.c~shmem-consume-the-reserved-xattr-space-despite-remount
+++ a/mm/shmem.c
@@ -4451,7 +4451,7 @@ static int shmem_initxattrs(struct inode
if (simple_xattr_add(&sbinfo->xa_cache, &info->xattrs, new_xattr))
break;
- if (sbinfo->max_inodes)
+ if (ispace)
ispace -= simple_xattr_space(new_xattr->name, new_xattr->size);
retain_and_null_ptr(new_xattr);
}
_
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [syzbot] [mm?] [fuse?] WARNING in shmem_initxattrs
2026-11-05 16:27 ` Andrew Morton
@ 2026-11-05 16:47 ` syzbot
0 siblings, 0 replies; 3+ messages in thread
From: syzbot @ 2026-11-05 16:47 UTC (permalink / raw)
To: akpm, baolin.wang, brauner, fuse-devel, hughd, linux-kernel,
linux-mm, mszeredi, syzkaller-bugs, syzkaller
Hello,
syzbot has tested the proposed patch and the reproducer did not trigger any issue:
Reported-by: syzbot+4324f771847cecb27c54@syzkaller.appspotmail.com
Tested-by: syzbot+4324f771847cecb27c54@syzkaller.appspotmail.com
Tested on:
commit: 05441d69 Merge tag 'cocci-7.4-rc1' of git://git.kernel..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=11953cbe580000
kernel config: https://syzkaller.appspot.com/x/.config?x=1cf189394a856f11
dashboard link: https://syzkaller.appspot.com/bug?extid=4324f771847cecb27c54
compiler: gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
patch: https://syzkaller.appspot.com/x/patch.diff?x=1624c98d580000
Note: testing is done by a robot and is best-effort only.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-11-05 16:47 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-11-05 11:10 [syzbot] [mm?] [fuse?] WARNING in shmem_initxattrs syzbot
2026-11-05 16:27 ` Andrew Morton
2026-11-05 16:47 ` syzbot
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®