On Fri, Aug 18, 2023 at 11:26:51AM -0500, Eric W. Biederman wrote: > syzbot <syzbot+6ec38f7a8db3b3fb1002@xxxxxxxxxxxxxxxxxxxxxxxxx> writes: > > > Hello, > > > > syzbot found the following issue on: > > Not an issue. > Nothing to do with ntfs. > > The code is working as designed and intended. > > syzbot generated a malformed exec and the kernel made it > well formed and warned about it. > > Human beings who run syzbot please mark this as not an issue in your > system. The directions don't have a way to say that the code is working > as expected and designed. WARN and BUG should not be reachable from userspace, so if this can be tripped we should take a closer look and likely fix it... > > HEAD commit: 16931859a650 Merge tag 'nfsd-6.5-4' of git://git.kernel.or.. > > git tree: upstream > > console+strace: https://syzkaller.appspot.com/x/log.txt?x=13e2673da80000 > > kernel config: https://syzkaller.appspot.com/x/.config?x=aa796b6080b04102 > > dashboard link: https://syzkaller.appspot.com/bug?extid=6ec38f7a8db3b3fb1002 > > compiler: gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40 > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=17cdbc65a80000 > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1262d8cfa80000 > > > > Downloadable assets: > > disk image: https://storage.googleapis.com/syzbot-assets/eecc010800b4/disk-16931859.raw.xz > > vmlinux: https://storage.googleapis.com/syzbot-assets/f45ae06377a7/vmlinux-16931859.xz > > kernel image: https://storage.googleapis.com/syzbot-assets/68891896edba/bzImage-16931859.xz > > mounted in repro: https://storage.googleapis.com/syzbot-assets/4b6ab78b223a/mount_0.gz > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > > Reported-by: syzbot+6ec38f7a8db3b3fb1002@xxxxxxxxxxxxxxxxxxxxxxxxx > > > > ntfs: volume version 3.1. > > process 'syz-executor300' launched './file1' with NULL argv: empty string added > > ------------[ cut here ]------------ > > WARNING: CPU: 0 PID: 5020 at fs/exec.c:933 do_open_execat+0x18f/0x3f0 fs/exec.c:933 This is a double-check I left in place, since it shouldn't have been reachable: /* * may_open() has already checked for this, so it should be * impossible to trip now. But we need to be extra cautious * and check again at the very end too. */ err = -EACCES; if (WARN_ON_ONCE(!S_ISREG(file_inode(file)->i_mode) || path_noexec(&file->f_path))) goto exit; So yes, let's figure this out... -- Kees Cook
