Re: [syzbot] [mm?] KMSAN: uninit-value in copy_from_kernel_nofault

[vbabka]

On 3/16/26 12:58, Christian Brauner wrote:
> On Mon, Mar 16, 2026 at 03:22:46AM -0700, syzbot wrote:
>> Hello,
>> 
>> syzbot found the following issue on:
>> 
>> HEAD commit:    80234b5ab240 Merge tag 'rproc-v7.0-fixes' of git://git.ker..
>> git tree:       upstream
>> console output: https://syzkaller.appspot.com/x/log.txt?x=1474cd52580000
>> kernel config:  https://syzkaller.appspot.com/x/.config?x=242f02fcd3fbc8f3
>> dashboard link: https://syzkaller.appspot.com/bug?extid=c18de0ad13d62f18469d
>> compiler:       Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
>> userspace arch: i386
>> 
>> Unfortunately, I don't have any reproducer for this issue yet.
>> 
>> Downloadable assets:
>> disk image: https://storage.googleapis.com/syzbot-assets/a0d037332dff/disk-80234b5a.raw.xz
>> vmlinux: https://storage.googleapis.com/syzbot-assets/0a1f7f8b54f8/vmlinux-80234b5a.xz
>> kernel image: https://storage.googleapis.com/syzbot-assets/83eb68ee6421/bzImage-80234b5a.xz
>> 
>> IMPORTANT: if you fix the issue, please add the following tag to the commit:
>> Reported-by: syzbot+c18de0ad13d62f18469d@xxxxxxxxxxxxxxxxxxxxxxxxx
>> 
>> =====================================================
>> BUG: KMSAN: uninit-value in copy_from_kernel_nofault+0x15f/0x570 mm/maccess.c:41
>>  copy_from_kernel_nofault+0x15f/0x570 mm/maccess.c:41
>>  prepend_copy fs/d_path.c:50 [inline]
>>  prepend fs/d_path.c:76 [inline]
>>  prepend_name fs/d_path.c:101 [inline]
>>  __prepend_path fs/d_path.c:133 [inline]
>>  prepend_path+0x64e/0x1090 fs/d_path.c:172
> 
> I think this might just be KMSAN not being able to deal with seqlocks
> appropriately? 

Let's cc KMSAN folks then. Maybe there's a way to teach it that/add
exceptions/ignores.

> dentry->d_shortname.string[DNAME_INLINE_LEN-1] = 0;
> 
> is initialized with a zero byte at the end instead of:
> 
> memset(&dentry->d_shortname, 0, sizeof(dentry->d_shortname));
> 
> which would prevent that warning. But that's zeroing 40 bytes vs one and
> the dache is fast-fast-fast.
> 
> prepend_path() detects the initialization race via rename_lock seqlock
> and retries d_absolute_path(). So this is entirely harmless and works
> correct.