[syzbot] KMSAN: uninit-value in fat_subdirs

5 views
Skip to first unread message

syzbot

unread,
Jan 7, 2022, 6:40:19 AM1/7/22
to gli...@google.com, hiro...@mail.parknet.co.jp, linux-...@vger.kernel.org, syzkall...@googlegroups.com
Hello,

syzbot found the following issue on:

HEAD commit: 81c325bbf94e kmsan: hooks: do not check memory in kmsan_in..
git tree: https://github.com/google/kmsan.git master
console output: https://syzkaller.appspot.com/x/log.txt?x=11506cb3b00000
kernel config: https://syzkaller.appspot.com/x/.config?x=2d8b9a11641dc9aa
dashboard link: https://syzkaller.appspot.com/bug?extid=ac94ae5f68b84197f41c
compiler: clang version 14.0.0 (/usr/local/google/src/llvm-git-monorepo 2b554920f11c8b763cd9ed9003f4e19b919b8e1f), GNU ld (GNU Binutils for Debian) 2.35.2
userspace arch: i386

Unfortunately, I don't have any reproducer for this issue yet.

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+ac94ae...@syzkaller.appspotmail.com

loop3: detected capacity change from 0 to 7
=====================================================
BUG: KMSAN: uninit-value in fat_get_short_entry fs/fat/dir.c:875 [inline]
BUG: KMSAN: uninit-value in fat_subdirs+0x24b/0x460 fs/fat/dir.c:939
fat_get_short_entry fs/fat/dir.c:875 [inline]
fat_subdirs+0x24b/0x460 fs/fat/dir.c:939
fat_read_root+0x92f/0xac0 fs/fat/inode.c:1413
fat_fill_super+0x6e5b/0x7ff0 fs/fat/inode.c:1860
vfat_fill_super+0xa6/0xc0 fs/fat/namei_vfat.c:1051
mount_bdev+0x626/0x920 fs/super.c:1370
vfat_mount+0xc9/0xe0 fs/fat/namei_vfat.c:1058
legacy_get_tree+0x163/0x2e0 fs/fs_context.c:610
vfs_get_tree+0xd8/0x5d0 fs/super.c:1500
do_new_mount+0x7b5/0x16f0 fs/namespace.c:2988
path_mount+0x1021/0x28b0 fs/namespace.c:3318
do_mount fs/namespace.c:3331 [inline]
__do_sys_mount fs/namespace.c:3539 [inline]
__se_sys_mount+0x8a8/0x9d0 fs/namespace.c:3516
__ia32_sys_mount+0x157/0x1b0 fs/namespace.c:3516
do_syscall_32_irqs_on arch/x86/entry/common.c:114 [inline]
__do_fast_syscall_32+0x96/0xf0 arch/x86/entry/common.c:180
do_fast_syscall_32+0x34/0x70 arch/x86/entry/common.c:205
do_SYSENTER_32+0x1b/0x20 arch/x86/entry/common.c:248
entry_SYSENTER_compat_after_hwframe+0x4d/0x5c

Uninit was created at:
__alloc_pages+0xbbf/0x1090 mm/page_alloc.c:5409
alloc_pages+0x8a5/0xb80
folio_alloc+0x7b/0x180 mm/mempolicy.c:2201
filemap_alloc_folio mm/filemap.c:1036 [inline]
__filemap_get_folio+0xee2/0x1b20 mm/filemap.c:1951
pagecache_get_page+0xc6/0x3a0 mm/folio-compat.c:125
find_or_create_page include/linux/pagemap.h:489 [inline]
grow_dev_page+0x1b6/0xe00 fs/buffer.c:949
grow_buffers fs/buffer.c:1014 [inline]
__getblk_slow fs/buffer.c:1041 [inline]
__getblk_gfp+0x410/0x620 fs/buffer.c:1334
__bread_gfp+0xb3/0x810 fs/buffer.c:1379
sb_bread include/linux/buffer_head.h:303 [inline]
fat_fill_super+0x38d2/0x7ff0 fs/fat/inode.c:1685
vfat_fill_super+0xa6/0xc0 fs/fat/namei_vfat.c:1051
mount_bdev+0x626/0x920 fs/super.c:1370
vfat_mount+0xc9/0xe0 fs/fat/namei_vfat.c:1058
legacy_get_tree+0x163/0x2e0 fs/fs_context.c:610
vfs_get_tree+0xd8/0x5d0 fs/super.c:1500
do_new_mount+0x7b5/0x16f0 fs/namespace.c:2988
path_mount+0x1021/0x28b0 fs/namespace.c:3318
do_mount fs/namespace.c:3331 [inline]
__do_sys_mount fs/namespace.c:3539 [inline]
__se_sys_mount+0x8a8/0x9d0 fs/namespace.c:3516
__ia32_sys_mount+0x157/0x1b0 fs/namespace.c:3516
do_syscall_32_irqs_on arch/x86/entry/common.c:114 [inline]
__do_fast_syscall_32+0x96/0xf0 arch/x86/entry/common.c:180
do_fast_syscall_32+0x34/0x70 arch/x86/entry/common.c:205
do_SYSENTER_32+0x1b/0x20 arch/x86/entry/common.c:248
entry_SYSENTER_compat_after_hwframe+0x4d/0x5c

CPU: 1 PID: 5570 Comm: syz-executor.3 Tainted: G W 5.16.0-rc5-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
=====================================================


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

OGAWA Hirofumi

unread,
Jan 9, 2022, 4:36:48 AM1/9/22
to linux...@vger.kernel.org, Jens Axboe, gli...@google.com, linux-...@vger.kernel.org, syzkall...@googlegroups.com, syzbot
bio_truncate() clears the buffer outside of last block of bdev, however
current bio_truncate() is using the wrong offset of page. So it can
return the uninitialized data.

This happened when both of truncated/corrupted FS and userspace (via
bdev) are trying to read the last of bdev.

Reported-by: syzbot+ac94ae...@syzkaller.appspotmail.com
Signed-off-by: OGAWA Hirofumi <hiro...@mail.parknet.co.jp>
---
block/bio.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/block/bio.c b/block/bio.c
index a6fb6a0..25f1ed2 100644
--- a/block/bio.c 2021-11-01 09:19:05.999472589 +0900
+++ b/block/bio.c 2022-01-09 17:40:09.010438012 +0900
@@ -567,7 +567,8 @@ void bio_truncate(struct bio *bio, unsig
offset = new_size - done;
else
offset = 0;
- zero_user(bv.bv_page, offset, bv.bv_len - offset);
+ zero_user(bv.bv_page, bv.bv_offset + offset,
+ bv.bv_len - offset);
truncated = true;
}
done += bv.bv_len;
_

--
OGAWA Hirofumi <hiro...@mail.parknet.co.jp>

Ming Lei

unread,
Jan 10, 2022, 3:00:46 AM1/10/22
to OGAWA Hirofumi, linux...@vger.kernel.org, Jens Axboe, gli...@google.com, linux-...@vger.kernel.org, syzkall...@googlegroups.com, syzbot
Looks correct:

Reviewed-by: Ming Lei <ming...@redhat.com>

--
Ming

OGAWA Hirofumi

unread,
Jan 19, 2022, 11:43:13 PM1/19/22
to Ming Lei, linux...@vger.kernel.org, Jens Axboe, gli...@google.com, linux-...@vger.kernel.org, syzkall...@googlegroups.com, syzbot
ping?
--
OGAWA Hirofumi <hiro...@mail.parknet.co.jp>

Jens Axboe

unread,
Jan 20, 2022, 8:30:26 AM1/20/22
to OGAWA Hirofumi, linux...@vger.kernel.org, syzbot, gli...@google.com, linux-...@vger.kernel.org, syzkall...@googlegroups.com
On Sun, 09 Jan 2022 18:36:43 +0900, OGAWA Hirofumi wrote:
> bio_truncate() clears the buffer outside of last block of bdev, however
> current bio_truncate() is using the wrong offset of page. So it can
> return the uninitialized data.
>
> This happened when both of truncated/corrupted FS and userspace (via
> bdev) are trying to read the last of bdev.
>
> [...]

Applied, thanks!

[1/1] block: Fix wrong offset in bio_truncate()
commit: 3ee859e384d453d6ac68bfd5971f630d9fa46ad3

Best regards,
--
Jens Axboe


Reply all
Reply to author
Forward
0 new messages