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

[vba...@kernel.org]

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+c18de0...@syzkaller.appspotmail.com
>>
>> =====================================================
>> 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.

[Alexander Potapenko]

I think KMSAN correctly points out that the data is uninitialized at
the point when copy_from_kernel_nofault executes.
KMSAN actually knows nothing about seqlocks or any other
synchronization primitives, it just tracks the state of every
uninitialized bit in the kernel, and reports an error if the data is
uninitialized when a check is requested.
It's a good question whether we need the aggressive KMSAN check in
copy_from_kernel() (are there cases in which this function copies data
out of the kernel?)
If we do, the following patch should fix the report in question:

diff --git a/fs/dcache.c b/fs/dcache.c
index 9ceab142896f..923e32e6a2d4 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -32,6 +32,7 @@
#include <linux/bit_spinlock.h>
#include <linux/rculist_bl.h>
#include <linux/list_lru.h>
+#include <linux/kmsan-checks.h>
#include "internal.h"
#include "mount.h"

@@ -1749,6 +1750,7 @@ static struct dentry *__d_alloc(struct
super_block *sb, const struct qstr *name)
* be overwriting an internal NUL character
*/

dentry->d_shortname.string[DNAME_INLINE_LEN-1] = 0;

+ kmsan_unpoison_memory(&dentry->d_shortname,
sizeof(dentry->d_shortname));
if (unlikely(!name)) {
name = &slash_name;
dname = dentry->d_shortname.string;