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

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

[Dmitry Antipov]

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;
 
-- 
2.54.0

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

[Al Viro]

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?

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

[Al Viro]

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?)