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

[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 <brauner@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+3de83a9efcca3f0412ee@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 syzkaller@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

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

[Christian Brauner]

On Mon, Jul 07, 2025 at 04:02:32AM -0700, syzbot wrote:
> 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 <brauner@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+3de83a9efcca3f0412ee@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

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

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

[syzbot]

Hello,

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

Reported-by: syzbot+3de83a9efcca3f0412ee@syzkaller.appspotmail.com
Tested-by: syzbot+3de83a9efcca3f0412ee@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.

[PATCH] secretmem: use SB_I_NOEXEC

[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
> 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

Link: https://lore.kernel.org/686ba948.a00a0220.c7b3.0080.GAE@google.com
Signed-off-by: Christian Brauner <brauner@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

Re: [PATCH] secretmem: use SB_I_NOEXEC

[Mike Rapoport]

On Mon, Jul 07, 2025 at 02:10:36PM +0200, Christian Brauner wrote:
> 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
> > 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
> 
> Link: https://lore.kernel.org/686ba948.a00a0220.c7b3.0080.GAE@google.com
> Signed-off-by: Christian Brauner <brauner@kernel.org>

Acked-by: Mike Rapoport (Microsoft) <rppt@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
> 

-- 
Sincerely yours,
Mike.

Re: [PATCH] secretmem: use SB_I_NOEXEC

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

Re: [PATCH] secretmem: use SB_I_NOEXEC

[Christian Brauner]

On Mon, Jul 07, 2025 at 06:17:35PM +0100, Al Viro wrote:
> 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?

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.