On Wed, Sep 16, 2020 at 10:56:56AM +0530, Anant Thazhemadam wrote: > The KMSAN bug report for the bug indicates that there exists; > Local variable ----nd@do_file_open_root created at: > do_file_open_root+0xa4/0xb40 fs/namei.c:3385 > do_file_open_root+0xa4/0xb40 fs/namei.c:3385 > > Initializing nd fixes this issue, and doesn't break anything else either > > Fixes: https://syzkaller.appspot.com/bug?extid=4191a44ad556eacc1a7a > Reported-by: syzbot+4191a44ad556eacc1a7a@xxxxxxxxxxxxxxxxxxxxxxxxx > Tested-by: syzbot+4191a44ad556eacc1a7a@xxxxxxxxxxxxxxxxxxxxxxxxx > Signed-off-by: Anant Thazhemadam <anant.thazhemadam@xxxxxxxxx> > --- > fs/namei.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/namei.c b/fs/namei.c > index e99e2a9da0f7..b27382586209 100644 > --- a/fs/namei.c > +++ b/fs/namei.c > @@ -3404,7 +3404,7 @@ struct file *do_filp_open(int dfd, struct filename *pathname, > struct file *do_file_open_root(struct dentry *dentry, struct vfsmount *mnt, > const char *name, const struct open_flags *op) > { > - struct nameidata nd; > + struct nameidata nd = {}; > struct file *file; > struct filename *filename; > int flags = op->lookup_flags | LOOKUP_ROOT; Looking at the actual KMSAN report, it looks like it's nameidata::dir_mode or nameidata::dir_uid that is uninitialized. You need to figure out the correct solution, not just blindly initialize with zeroes -- that could hide a bug. Is there a bug that is preventing these fields from being initialized to the correct values, are these fields being used when they shouldn't be, etc... - Eric
