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

[Alexander Potapenko]

On Mon, Mar 16, 2026 at 1:44 PM <vbabka@xxxxxxxxxx> wrote:
>
> 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?

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;