Re: [PATCH] ntfs3: fix info-leak in ntfs_rename()

[Al Viro <viro@zeniv.linux.org.uk>]

On Tue, Jun 09, 2026 at 09:19:48PM +0100, Al Viro wrote:
> On Tue, Jun 09, 2026 at 03:36:18PM +0300, Dmitry Antipov wrote:
> > In 'ntfs_rename()', buffer passed to 'fill_name_de()' should
> > be allocated with 'kzalloc()' to avoid exposing contents of
> > an uninitialized kernel memory via 'copy_to_user_iter()'.
> > 
> > Reported-by: syzbot+905d785c4923bea2c1db@syzkaller.appspotmail.com
> > Closes: https://syzkaller.appspot.com/bug?extid=905d785c4923bea2c1db
> > Fixes: ca2a04e84af7 ("ntfs: ->d_compare() must not block")
> > Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
> > ---
> >  fs/ntfs3/namei.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/fs/ntfs3/namei.c b/fs/ntfs3/namei.c
> > index b2af8f695e60..74fe002214f3 100644
> > --- a/fs/ntfs3/namei.c
> > +++ b/fs/ntfs3/namei.c
> > @@ -303,7 +303,7 @@ static int ntfs_rename(struct mnt_idmap *idmap, struct inode *dir,
> >  			return err;
> >  	}
> >  
> > -	de = kmalloc(PATH_MAX, GFP_KERNEL);
> > +	de = kzalloc(PATH_MAX, GFP_KERNEL);
> >  	if (!de)
> >  		return -ENOMEM;
> 
> Could you please elaborate the way by which the contents of that
> object would have managed to reach copy_to_user_iter()?
> While we are at it, which userland addresses would rename()
> want to write into?

From the syzkaller spew it would appear that data (filename converted
to unicode, AFAICS) somehow gets returned by read(2).  If that is
accurate, I would suggest that the things are already FUBAR and zeroing
is not going to fix whatever underlying bug you've got there (metadata
bh left around after the corresponding on-disk block got freed and
reused for regular file, perhaps?)