[syzbot] [mm?] [fs?] WARNING in path_noexec

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: 8d6c58332c7a Add linux-next specific files for 20250703
git tree: linux-next
console+strace: https://syzkaller.appspot.com/x/log.txt?x=15788582580000
kernel config: https://syzkaller.appspot.com/x/.config?x=d7dc16394230c170
dashboard link: https://syzkaller.appspot.com/bug?extid=3de83a9efcca3f0412ee
compiler: Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16ecb3d4580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=153af770580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/ff731adf5dfa/disk-8d6c5833.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/5c7a3c57e0a1/vmlinux-8d6c5833.xz
kernel image: https://storage.googleapis.com/syzbot-assets/2f90e7c18574/bzImage-8d6c5833.xz

The issue was bisected to:

commit df43ee1b368c791b7042504d2aa90893569b9034
Author: Christian Brauner <bra...@kernel.org>
Date: Wed Jul 2 09:23:55 2025 +0000

anon_inode: rework assertions

bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=14b373d4580000
final oops: https://syzkaller.appspot.com/x/report.txt?x=16b373d4580000
console output: https://syzkaller.appspot.com/x/log.txt?x=12b373d4580000

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+3de83a...@syzkaller.appspotmail.com
Fixes: df43ee1b368c ("anon_inode: rework assertions")

------------[ cut here ]------------
WARNING: fs/exec.c:119 at path_noexec+0x1af/0x200 fs/exec.c:118, CPU#1: syz-executor260/5835
Modules linked in:
CPU: 1 UID: 0 PID: 5835 Comm: syz-executor260 Not tainted 6.16.0-rc4-next-20250703-syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
RIP: 0010:path_noexec+0x1af/0x200 fs/exec.c:118
Code: 02 31 ff 48 89 de e8 f0 b1 89 ff d1 eb eb 07 e8 07 ad 89 ff b3 01 89 d8 5b 41 5e 41 5f 5d c3 cc cc cc cc cc e8 f2 ac 89 ff 90 <0f> 0b 90 e9 48 ff ff ff 44 89 f1 80 e1 07 80 c1 03 38 c1 0f 8c a6
RSP: 0018:ffffc90003eefbd8 EFLAGS: 00010293
RAX: ffffffff8235f22e RBX: ffff888072be0940 RCX: ffff88807763bc00
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000080000 R08: ffff88807763bc00 R09: 0000000000000003
R10: 0000000000000003 R11: 0000000000000000 R12: 0000000000000011
R13: 1ffff920007ddf90 R14: 0000000000000000 R15: dffffc0000000000
FS: 000055556832d380(0000) GS:ffff888125d1e000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f21e34810d0 CR3: 00000000718a8000 CR4: 00000000003526f0
Call Trace:
<TASK>
do_mmap+0xa43/0x10d0 mm/mmap.c:472
vm_mmap_pgoff+0x31b/0x4c0 mm/util.c:579
ksys_mmap_pgoff+0x51f/0x760 mm/mmap.c:607
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f21e340a9f9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 c1 17 00 00 90 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 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffd23ca3468 EFLAGS: 00000246 ORIG_RAX: 0000000000000009
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f21e340a9f9
RDX: 0000000000000000 RSI: 0000000000004000 RDI: 0000200000ff9000
RBP: 00007f21e347d5f0 R08: 0000000000000003 R09: 0000000000000000
R10: 0000000000000011 R11: 0000000000000246 R12: 0000000000000001
R13: 431bde82d7b634db R14: 0000000000000001 R15: 0000000000000001
</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 syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection

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

[Christian Brauner]

And already we have found one offender whose not raising SB_I_NOEXEC but
using anonymous inodes...

#syz test: https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git vfs.fixes

[Hillf Danton]

> Date: Mon, 07 Jul 2025 04:02:32 -0700

> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: 8d6c58332c7a Add linux-next specific files for 20250703
> git tree: linux-next
> console+strace: https://syzkaller.appspot.com/x/log.txt?x=15788582580000
> kernel config: https://syzkaller.appspot.com/x/.config?x=d7dc16394230c170
> dashboard link: https://syzkaller.appspot.com/bug?extid=3de83a9efcca3f0412ee
> compiler: Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16ecb3d4580000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=153af770580000
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/ff731adf5dfa/disk-8d6c5833.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/5c7a3c57e0a1/vmlinux-8d6c5833.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/2f90e7c18574/bzImage-8d6c5833.xz
>
> The issue was bisected to:
>
> commit df43ee1b368c791b7042504d2aa90893569b9034
> Author: Christian Brauner <bra...@kernel.org>
> Date: Wed Jul 2 09:23:55 2025 +0000
>
> anon_inode: rework assertions
>

Given EPERM [1], this rework looks like a case of overdose.

[1] https://web.git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/mm/mmap.c?id=df43ee1b368c#n474

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+3de83a...@syzkaller.appspotmail.com
Tested-by: syzbot+3de83a...@syzkaller.appspotmail.com

Tested on:

commit: 98f99394 secretmem: use SB_I_NOEXEC
git tree: https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git vfs.fixes
console output: https://syzkaller.appspot.com/x/log.txt?x=13829f70580000
kernel config: https://syzkaller.appspot.com/x/.config?x=8211a357c817ddc6

dashboard link: https://syzkaller.appspot.com/bug?extid=3de83a9efcca3f0412ee
compiler: Debian clang version 20.1.7 (++20250616065708+6146a88f6049-1~exp1~20250616065826.132), Debian LLD 20.1.7

Note: no patches were applied.
Note: testing is done by a robot and is best-effort only.

[Christian Brauner]

Anonymous inodes may never ever be exectuable and the only way to
enforce this is to raise SB_I_NOEXEC on the superblock which can never
be unset. I've made the exec code yell at anyone who does not abide by
this rule.

For good measure also kill any pretense that device nodes are supported
on the secretmem filesystem.

> WARNING: fs/exec.c:119 at path_noexec+0x1af/0x200 fs/exec.c:118, CPU#1: syz-executor260/5835
> Modules linked in:
> CPU: 1 UID: 0 PID: 5835 Comm: syz-executor260 Not tainted 6.16.0-rc4-next-20250703-syzkaller #0 PREEMPT(full)
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
> RIP: 0010:path_noexec+0x1af/0x200 fs/exec.c:118

Link: https://lore.kernel.org/686ba948.a00a02...@google.com
Signed-off-by: Christian Brauner <bra...@kernel.org>
---
mm/secretmem.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/mm/secretmem.c b/mm/secretmem.c
index 9a11a38a6770..e042a4a0bc0c 100644
--- a/mm/secretmem.c
+++ b/mm/secretmem.c
@@ -261,7 +261,15 @@ SYSCALL_DEFINE1(memfd_secret, unsigned int, flags)

static int secretmem_init_fs_context(struct fs_context *fc)
{
- return init_pseudo(fc, SECRETMEM_MAGIC) ? 0 : -ENOMEM;
+ struct pseudo_fs_context *ctx;
+
+ ctx = init_pseudo(fc, SECRETMEM_MAGIC);
+ if (!ctx)
+ return -ENOMEM;
+
+ fc->s_iflags |= SB_I_NOEXEC;
+ fc->s_iflags |= SB_I_NODEV;
+ return 0;
}

static struct file_system_type secretmem_fs = {
@@ -279,9 +287,6 @@ static int __init secretmem_init(void)
if (IS_ERR(secretmem_mnt))
return PTR_ERR(secretmem_mnt);

- /* prevent secretmem mappings from ever getting PROT_EXEC */
- secretmem_mnt->mnt_flags |= MNT_NOEXEC;
-
return 0;
}
fs_initcall(secretmem_init);
--
2.47.2

[Mike Rapoport]

Acked-by: Mike Rapoport (Microsoft) <rp...@kernel.org>

--
Sincerely yours,
Mike.

[Al Viro]

On Mon, Jul 07, 2025 at 02:10:36PM +0200, Christian Brauner wrote:

> static int secretmem_init_fs_context(struct fs_context *fc)
> {
> - return init_pseudo(fc, SECRETMEM_MAGIC) ? 0 : -ENOMEM;
> + struct pseudo_fs_context *ctx;
> +
> + ctx = init_pseudo(fc, SECRETMEM_MAGIC);
> + if (!ctx)
> + return -ENOMEM;
> +
> + fc->s_iflags |= SB_I_NOEXEC;
> + fc->s_iflags |= SB_I_NODEV;
> + return 0;
> }

What's the point of doing that *after* init_pseudo()? IOW, why not simply

static int secretmem_init_fs_context(struct fs_context *fc)
{

fc->s_iflags |= SB_I_NOEXEC;
fc->s_iflags |= SB_I_NODEV;

return init_pseudo(fc, SECRETMEM_MAGIC) ? 0 : -ENOMEM;
}

seeing that init_pseudo() won't undo those?

[Christian Brauner]

Seemed cleaner to do it the other way around and get rid of the ? while
at it. I don't think it matters either way.

[syzbot]

For archival purposes, forwarding an incoming command email to
syzkall...@googlegroups.com.

***

Subject: Re: [PATCH] secretmem: use SB_I_NOEXEC
Author: penguin...@i-love.sakura.ne.jp

F.Y.I. This bug is still happening; more patches needed.

#syz fix: secretmem: use SB_I_NOEXEC