From: syzbot <syzbot+2472d48b2d3b2a23a570@syzkaller.appspotmail.com>
To: tristmd@gmail.com
Cc: tristmd@gmail.com, linux-kernel@vger.kernel.org,
syzkaller-bugs@googlegroups.com
Subject: Re: [PATCH] ntfs3: zero-initialize trailing VBN slot in index entry
Date: Fri, 17 Apr 2026 03:12:42 -0700 [thread overview]
Message-ID: <69e2079a.a00a0220.1cdc.000e.GAE@google.com> (raw)
In-Reply-To: <20260417101240.2491632-1-tristmd@gmail.com>
> From: Tristan Madani <tristan@talencesecurity.com>
>
> #syz test: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
This crash does not have a reproducer. I cannot test it.
>
> allocations
>
> indx_insert_into_buffer() and indx_delete_entry() each allocate an
> index entry buffer with room for a trailing VBN (virtual block number)
> sub-node pointer:
>
> up_e = kmalloc(sp_size + sizeof(u64), GFP_NOFS);
> memcpy(up_e, sp, sp_size);
>
> re = kmalloc(le16_to_cpu(te->size) + sizeof(u64), GFP_NOFS);
> memcpy(re, te, le16_to_cpu(te->size));
>
> The extra sizeof(u64) bytes reserved for the VBN are left
> uninitialized. When the entry is a leaf node (no sub-nodes), the VBN
> slot is never written, and the uninitialized bytes are eventually
> written to the index buffer on disk. When the index is later read
> back, ntfs_read_hdr() processes these uninitialized bytes, which KMSAN
> flags as a use of uninitialized memory.
>
> Fix this by using kzalloc() instead of kmalloc(), ensuring the VBN
> slot defaults to zero when not explicitly set.
>
> Reported-by: syzbot+2472d48b2d3b2a23a570@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=2472d48b2d3b2a23a570
> Fixes: 522e010b5837 ("fs/ntfs3: Add file operations and implementation")
> Cc: stable@vger.kernel.org
> Signed-off-by: Tristan Madani <tristan@talencesecurity.com>
> ---
> fs/ntfs3/index.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/ntfs3/index.c b/fs/ntfs3/index.c
> index XXXXXXX..XXXXXXX 100644
> --- a/fs/ntfs3/index.c
> +++ b/fs/ntfs3/index.c
> @@ -1838,7 +1838,7 @@ static int indx_insert_into_buffer(struct ntfs_index *indx,
>
> sp_size = le16_to_cpu(sp->size);
> - up_e = kmalloc(sp_size + sizeof(u64), GFP_NOFS);
> + up_e = kzalloc(sp_size + sizeof(u64), GFP_NOFS);
> if (!up_e)
> return -ENOMEM;
> memcpy(up_e, sp, sp_size);
> @@ -2228,7 +2228,7 @@ int indx_delete_entry(struct ntfs_index *indx, struct ntfs_inode *ni,
> }
>
> /* Copy the candidate entry into the replacement entry buffer. */
> - re = kmalloc(le16_to_cpu(te->size) + sizeof(u64), GFP_NOFS);
> + re = kzalloc(le16_to_cpu(te->size) + sizeof(u64), GFP_NOFS);
> if (!re) {
> err = -ENOMEM;
> goto out;
> --
> 2.43.0
parent reply other threads:[~2026-04-17 10:12 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <20260417101240.2491632-1-tristmd@gmail.com>]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=69e2079a.a00a0220.1cdc.000e.GAE@google.com \
--to=syzbot+2472d48b2d3b2a23a570@syzkaller.appspotmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=syzkaller-bugs@googlegroups.com \
--cc=tristmd@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.