[PATCH v2] ntfs3: fix uninit memory after failed mi_read in mi_format_new

Raphael Pinsonneault-Thibeault posted 1 patch 2 months ago
fs/ntfs3/fsntfs.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
[PATCH v2] ntfs3: fix uninit memory after failed mi_read in mi_format_new
Posted by Raphael Pinsonneault-Thibeault 2 months ago
Fix a KMSAN un-init bug found by syzkaller.

ntfs_get_bh() expects a buffer from sb_getblk(), that buffer may not be
uptodate. We do not bring the buffer uptodate before setting it as
uptodate. If the buffer were to not be uptodate, it could mean adding a
buffer with un-init data to the mi record. Attempting to load that record
will trigger KMSAN.

Avoid this by setting the buffer as uptodate, if it’s not already, by
overwriting it.

Reported-by: syzbot+7a2ba6b7b66340cff225@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=7a2ba6b7b66340cff225
Tested-by: syzbot+7a2ba6b7b66340cff225@syzkaller.appspotmail.com
Fixes: 4342306f0f0d5 ("fs/ntfs3: Add file operations and implementation")
Signed-off-by: Raphael Pinsonneault-Thibeault <rpthibeault@gmail.com>
---

v1:
https://lore.kernel.org/all/20250925203701.223744-2-rpthibeault@gmail.com/
Differences from v1: 
In the previous version, I thought that mi_read() returning an error was
a genuine reason to stop trying to format the record. That was wrong. If
we find that mi_read() fails and that therefore we cannot reuse an old
record, we should try to make a new one. It then follows that
ntfs_get_bh() should provide an uptodate bh for the new record.

On testing:
I could not get xfstests-bld to work for ntfs3. Config nightmare. So I
first tested with the syzkaller repro, then tested for regressions manually 
with a program that called all the syscall code paths touched by my change: 
mkdir, fallocate (FALLOC_FL_COLLAPSE_RANGE), and 
fallocate (FALLOC_FL_INSERT_RANGE).

 fs/ntfs3/fsntfs.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/fs/ntfs3/fsntfs.c b/fs/ntfs3/fsntfs.c
index 938d351ebac7..0c07502fdb0f 100644
--- a/fs/ntfs3/fsntfs.c
+++ b/fs/ntfs3/fsntfs.c
@@ -1373,7 +1373,14 @@ int ntfs_get_bh(struct ntfs_sb_info *sbi, const struct runs_tree *run, u64 vbo,
 				}
 				if (buffer_locked(bh))
 					__wait_on_buffer(bh);
-				set_buffer_uptodate(bh);
+
+				lock_buffer(bh);
+				if (!buffer_uptodate(bh))
+				{
+					memset(bh->b_data, 0, blocksize);
+					set_buffer_uptodate(bh);
+				}
+				unlock_buffer(bh);
 			} else {
 				bh = ntfs_bread(sb, block);
 				if (!bh) {
-- 
2.43.0

Re: [PATCH v2] ntfs3: fix uninit memory after failed mi_read in mi_format_new
Posted by Konstantin Komarov 3 weeks, 6 days ago
On 10/12/25 22:16, Raphael Pinsonneault-Thibeault wrote:

> Fix a KMSAN un-init bug found by syzkaller.
>
> ntfs_get_bh() expects a buffer from sb_getblk(), that buffer may not be
> uptodate. We do not bring the buffer uptodate before setting it as
> uptodate. If the buffer were to not be uptodate, it could mean adding a
> buffer with un-init data to the mi record. Attempting to load that record
> will trigger KMSAN.
>
> Avoid this by setting the buffer as uptodate, if it’s not already, by
> overwriting it.
>
> Reported-by: syzbot+7a2ba6b7b66340cff225@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=7a2ba6b7b66340cff225
> Tested-by: syzbot+7a2ba6b7b66340cff225@syzkaller.appspotmail.com
> Fixes: 4342306f0f0d5 ("fs/ntfs3: Add file operations and implementation")
> Signed-off-by: Raphael Pinsonneault-Thibeault <rpthibeault@gmail.com>
> ---
>
> v1:
> https://lore.kernel.org/all/20250925203701.223744-2-rpthibeault@gmail.com/
> Differences from v1:
> In the previous version, I thought that mi_read() returning an error was
> a genuine reason to stop trying to format the record. That was wrong. If
> we find that mi_read() fails and that therefore we cannot reuse an old
> record, we should try to make a new one. It then follows that
> ntfs_get_bh() should provide an uptodate bh for the new record.
>
> On testing:
> I could not get xfstests-bld to work for ntfs3. Config nightmare. So I
> first tested with the syzkaller repro, then tested for regressions manually
> with a program that called all the syscall code paths touched by my change:
> mkdir, fallocate (FALLOC_FL_COLLAPSE_RANGE), and
> fallocate (FALLOC_FL_INSERT_RANGE).
>
>   fs/ntfs3/fsntfs.c | 9 ++++++++-
>   1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/fs/ntfs3/fsntfs.c b/fs/ntfs3/fsntfs.c
> index 938d351ebac7..0c07502fdb0f 100644
> --- a/fs/ntfs3/fsntfs.c
> +++ b/fs/ntfs3/fsntfs.c
> @@ -1373,7 +1373,14 @@ int ntfs_get_bh(struct ntfs_sb_info *sbi, const struct runs_tree *run, u64 vbo,
>   				}
>   				if (buffer_locked(bh))
>   					__wait_on_buffer(bh);
> -				set_buffer_uptodate(bh);
> +
> +				lock_buffer(bh);
> +				if (!buffer_uptodate(bh))
> +				{
> +					memset(bh->b_data, 0, blocksize);
> +					set_buffer_uptodate(bh);
> +				}
> +				unlock_buffer(bh);
>   			} else {
>   				bh = ntfs_bread(sb, block);
>   				if (!bh) {

Applied to my tree, thanks for the patch.

Regards,
Konstantin