Received-SPF: pass (google.com: domain of linux-nfs+bounces-1134-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Precedence: bulk
MIME-Version: 1.0
References: <000000000000e3d83a060ee5285a@google.com> <B4A8D625-6997-49C8-B105-B2DCFE8C6DDA@oracle.com>
In-Reply-To: <B4A8D625-6997-49C8-B105-B2DCFE8C6DDA@oracle.com>
From: Amir Goldstein <amir73il@gmail.com>
Date: Tue, 16 Jan 2024 19:21:00 +0200
Message-ID: <CAOQ4uxg8LLj4EN-MiMCR3vcarN3X6EMkgnqZ1uX1=G2DnxNbLQ@mail.gmail.com>
Subject: Re: [syzbot] [nfs?] KMSAN: kernel-infoleak in sys_name_to_handle_at (4)
To: Chuck Lever III <chuck.lever@oracle.com>
Cc: syzbot <syzbot+09b349b3066c2e0b1e96@syzkaller.appspotmail.com>, 
	Christian Brauner <brauner@kernel.org>, Jeff Layton <jlayton@kernel.org>, 
	linux-fsdevel <linux-fsdevel@vger.kernel.org>, 
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, 
	Linux NFS Mailing List <linux-nfs@vger.kernel.org>, 
	"syzkaller-bugs@googlegroups.com" <syzkaller-bugs@googlegroups.com>, Al Viro <viro@zeniv.linux.org.uk>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jan 16, 2024 at 5:08=E2=80=AFPM Chuck Lever III <chuck.lever@oracle=
.com> wrote:
>
>
>
> > On Jan 14, 2024, at 5:14=E2=80=AFAM, syzbot <syzbot+09b349b3066c2e0b1e9=
6@syzkaller.appspotmail.com> wrote:
> >
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit:    861deac3b092 Linux 6.7-rc7
> > git tree:       upstream
> > console+strace: https://syzkaller.appspot.com/x/log.txt?x=3D155d9131e80=
000
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=3De0c7078a6b9=
01aa3
> > dashboard link: https://syzkaller.appspot.com/bug?extid=3D09b349b3066c2=
e0b1e96
> > compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for D=
ebian) 2.40
> > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=3D16cefdc9e=
80000
> > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=3D164fe7e9e80=
000
> >
> > Downloadable assets:
> > disk image: https://storage.googleapis.com/syzbot-assets/0ea60ee8ed32/d=
isk-861deac3.raw.xz
> > vmlinux: https://storage.googleapis.com/syzbot-assets/6d69fdc33021/vmli=
nux-861deac3.xz
> > kernel image: https://storage.googleapis.com/syzbot-assets/f0158750d452=
/bzImage-861deac3.xz
> > mounted in repro: https://storage.googleapis.com/syzbot-assets/bb450f07=
6a10/mount_0.gz
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the co=
mmit:
> > Reported-by: syzbot+09b349b3066c2e0b1e96@syzkaller.appspotmail.com
> >
> >         option from the mount to silence this warning.
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
> > BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/in=
strumented.h:114 [inline]
> > BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x100 lib/usercopy.c:=
40
> > instrument_copy_to_user include/linux/instrumented.h:114 [inline]
> > _copy_to_user+0xbc/0x100 lib/usercopy.c:40
> > copy_to_user include/linux/uaccess.h:191 [inline]
> > do_sys_name_to_handle fs/fhandle.c:73 [inline]
> > __do_sys_name_to_handle_at fs/fhandle.c:112 [inline]
> > __se_sys_name_to_handle_at+0x949/0xb10 fs/fhandle.c:94
> > __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94
> > do_syscall_x64 arch/x86/entry/common.c:52 [inline]
> > do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83
> > entry_SYSCALL_64_after_hwframe+0x63/0x6b
> >
> > Uninit was created at:
> > slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768
> > slab_alloc_node mm/slub.c:3478 [inline]
> > __kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517
> > __do_kmalloc_node mm/slab_common.c:1006 [inline]
> > __kmalloc+0x121/0x3c0 mm/slab_common.c:1020
> > kmalloc include/linux/slab.h:604 [inline]
> > do_sys_name_to_handle fs/fhandle.c:39 [inline]
> > __do_sys_name_to_handle_at fs/fhandle.c:112 [inline]
> > __se_sys_name_to_handle_at+0x441/0xb10 fs/fhandle.c:94
> > __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94
> > do_syscall_x64 arch/x86/entry/common.c:52 [inline]
> > do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83
> > entry_SYSCALL_64_after_hwframe+0x63/0x6b
> >
> > Bytes 18-19 of 20 are uninitialized
> > Memory access of size 20 starts at ffff888128a46380
> > Data copied to user address 0000000020000240
> >
> > CPU: 0 PID: 5006 Comm: syz-executor975 Not tainted 6.7.0-rc7-syzkaller =
#0
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS=
 Google 11/17/2023
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
>
> Hi Amir-
>
> The kmalloc() at fs/fhandle.c:39 could be made a kzalloc().
>
> But I wonder if those uninitialized bytes in the file_handle
> buffer are actually a logic bug in do_sys_name_to_handle().
>

I am not sure I understand from the report which bytes are not initialized.
If it's the bytes of the opaque f_handle, then it sounds like a
filesystem (nilfs) bug.

Thanks,
Amir.