On 2022/11/30 3:15, Viacheslav Dubeyko wrote: > >> On Nov 28, 2022, at 6:39 PM, Liu Shixin <liushixin2@xxxxxxxxxx> wrote: >> >> syzbot found a slab-out-of-bounds Read in hfsplus_uni2asc: >> >> BUG: KASAN: slab-out-of-bounds in hfsplus_uni2asc+0x683/0x1290 fs/hfsplus/unicode.c:179 >> Read of size 2 at addr ffff88801887a40c by task syz-executor412/3632 >> >> CPU: 1 PID: 3632 Comm: syz-executor412 Not tainted 6.1.0-rc6-syzkaller-00315-gfaf68e3523c2 #0 >> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 >> Call Trace: >> <TASK> >> __dump_stack lib/dump_stack.c:88 [inline] >> dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106 >> print_address_description+0x74/0x340 mm/kasan/report.c:284 >> print_report+0x107/0x1f0 mm/kasan/report.c:395 >> kasan_report+0xcd/0x100 mm/kasan/report.c:495 >> hfsplus_uni2asc+0x683/0x1290 fs/hfsplus/unicode.c:179 >> hfsplus_readdir+0x8be/0x1230 fs/hfsplus/dir.c:207 >> iterate_dir+0x257/0x5f0 >> __do_sys_getdents64 fs/readdir.c:369 [inline] >> __se_sys_getdents64+0x1db/0x4c0 fs/readdir.c:354 >> do_syscall_x64 arch/x86/entry/common.c:50 [inline] >> do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 >> entry_SYSCALL_64_after_hwframe+0x63/0xcd >> >> The length of arrags ustr->unicode is HFSPLUS_MAX_STRLEN. Limit the value >> of ustr->length to no more than HFSPLUS_MAX_STRLEN. >> >> Reported-by: syzbot+076d963e115823c4b9be@xxxxxxxxxxxxxxxxxxxxxxxxx >> Signed-off-by: Liu Shixin <liushixin2@xxxxxxxxxx> >> --- >> fs/hfsplus/unicode.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/fs/hfsplus/unicode.c b/fs/hfsplus/unicode.c >> index 73342c925a4b..3df43a176acb 100644 >> --- a/fs/hfsplus/unicode.c >> +++ b/fs/hfsplus/unicode.c >> @@ -133,6 +133,8 @@ int hfsplus_uni2asc(struct super_block *sb, >> op = astr; >> ip = ustr->unicode; >> ustrlen = be16_to_cpu(ustr->length); >> + if (ustrlen > HFSPLUS_MAX_STRLEN) >> + ustrlen = HFSPLUS_MAX_STRLEN; > Hmmm.. It’s strange. As far as I can see, we read ustr from the volume > because be16_to_cpu() is used. But how ustrlen can be bigger than HFSPLUS_MAX_STRLEN > if we read it from volume? Do we have corrupted volume? What the environment of > the issue? > > Thanks, > Slava. The bug is reported by syzbot. You can find the reprodution program there. Link: https://syzkaller.appspot.com/bug?id=8a0515c326633c38c5145308835518579ea8af1e It seems that there is a corrupted volume. But I don't know much about this so I'm not sure. Is there any useful information here? I noticed that syzbot found another bug of hfsplus recently, which seem to related to corrupted volume too. https://syzkaller.appspot.com/bug?id=9fa98e04385363b08013093b659020d8dedae2ec Thanks, . > >> len = *len_p; >> ce1 = NULL; >> compose = !test_bit(HFSPLUS_SB_NODECOMPOSE, &HFSPLUS_SB(sb)->flags); >> -- >> 2.25.1 >> > . >
