* KASAN: slab-out-of-bounds Read in squashfs_get_id
@ 2020-09-25 14:48 syzbot
2020-10-14 7:52 ` Fox Chen
` (2 more replies)
0 siblings, 3 replies; 15+ messages in thread
From: syzbot @ 2020-09-25 14:48 UTC (permalink / raw)
To: linux-kernel, phillip, syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: 171d4ff7 Merge tag 'mmc-v5.9-rc4-2' of git://git.kernel.or..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1597ead3900000
kernel config: https://syzkaller.appspot.com/x/.config?x=af502ec9a451c9fc
dashboard link: https://syzkaller.appspot.com/bug?extid=8e28bba73ed1772a6802
compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/ c2443155a0fb245c8f17f2c1c72b6ea391e86e81)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=172ff481900000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17c3e6c5900000
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+8e28bba73ed1772a6802@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: slab-out-of-bounds in squashfs_get_id+0xb9/0x1c0 fs/squashfs/id.c:38
Read of size 8 at addr ffff8880a9684b98 by task syz-executor329/6836
CPU: 1 PID: 6836 Comm: syz-executor329 Not tainted 5.9.0-rc6-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1d6/0x29e lib/dump_stack.c:118
print_address_description+0x66/0x620 mm/kasan/report.c:383
__kasan_report mm/kasan/report.c:513 [inline]
kasan_report+0x132/0x1d0 mm/kasan/report.c:530
squashfs_get_id+0xb9/0x1c0 fs/squashfs/id.c:38
squashfs_new_inode fs/squashfs/inode.c:51 [inline]
squashfs_read_inode+0x155/0x2170 fs/squashfs/inode.c:120
squashfs_fill_super+0x1478/0x1790 fs/squashfs/super.c:310
get_tree_bdev+0x3e9/0x5f0 fs/super.c:1342
vfs_get_tree+0x88/0x270 fs/super.c:1547
do_new_mount fs/namespace.c:2875 [inline]
path_mount+0x179d/0x29e0 fs/namespace.c:3192
do_mount fs/namespace.c:3205 [inline]
__do_sys_mount fs/namespace.c:3413 [inline]
__se_sys_mount+0x126/0x180 fs/namespace.c:3390
do_syscall_64+0x31/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x446d1a
Code: b8 08 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 fd ad fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 0f 83 da ad fb ff c3 66 0f 1f 84 00 00 00 00 00
RSP: 002b:00007ffd7dd4f8b8 EFLAGS: 00000293 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 00007ffd7dd4f910 RCX: 0000000000446d1a
RDX: 0000000020000000 RSI: 0000000020000100 RDI: 00007ffd7dd4f8d0
RBP: 00007ffd7dd4f8d0 R08: 00007ffd7dd4f910 R09: 00007ffd00000015
R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000001
R13: 0000000000000004 R14: 0000000000000003 R15: 0000000000000003
Allocated by task 3913:
kasan_save_stack mm/kasan/common.c:48 [inline]
kasan_set_track mm/kasan/common.c:56 [inline]
__kasan_kmalloc+0x100/0x130 mm/kasan/common.c:461
kmalloc_node include/linux/slab.h:577 [inline]
__vmalloc_area_node mm/vmalloc.c:2429 [inline]
__vmalloc_node_range+0x2c7/0x870 mm/vmalloc.c:2511
module_alloc+0x7e/0x90 arch/x86/kernel/module.c:75
bpf_jit_binary_alloc+0x123/0x230 kernel/bpf/core.c:871
bpf_int_jit_compile+0x7995/0x8920 arch/x86/net/bpf_jit_comp.c:1911
bpf_prog_select_runtime+0x76d/0xa60 kernel/bpf/core.c:1807
bpf_migrate_filter net/core/filter.c:1290 [inline]
bpf_prepare_filter+0xec2/0x1140 net/core/filter.c:1338
bpf_prog_create_from_user+0x2ad/0x3e0 net/core/filter.c:1432
seccomp_prepare_filter kernel/seccomp.c:567 [inline]
seccomp_prepare_user_filter kernel/seccomp.c:604 [inline]
seccomp_set_mode_filter kernel/seccomp.c:1546 [inline]
do_seccomp+0x852/0x20b0 kernel/seccomp.c:1661
do_syscall_64+0x31/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
The buggy address belongs to the object at ffff8880a9684b80
which belongs to the cache kmalloc-32 of size 32
The buggy address is located 24 bytes inside of
32-byte region [ffff8880a9684b80, ffff8880a9684ba0)
The buggy address belongs to the page:
page:00000000f697ca3d refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff8880a9684fc1 pfn:0xa9684
flags: 0xfffe0000000200(slab)
raw: 00fffe0000000200 ffffea0002a5d5c8 ffffea0002a98588 ffff8880aa440100
raw: ffff8880a9684fc1 ffff8880a9684000 000000010000003f 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8880a9684a80: fa fb fb fb fc fc fc fc fa fb fb fb fc fc fc fc
ffff8880a9684b00: 00 fc fc fc fc fc fc fc fa fb fb fb fc fc fc fc
>ffff8880a9684b80: 00 fc fc fc fc fc fc fc fa fb fb fb fc fc fc fc
^
ffff8880a9684c00: fa fb fb fb fc fc fc fc fa fb fb fb fc fc fc fc
ffff8880a9684c80: 00 00 01 fc fc fc fc fc fa fb fb fb fc fc fc fc
==================================================================
---
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 syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: KASAN: slab-out-of-bounds Read in squashfs_get_id 2020-09-25 14:48 KASAN: slab-out-of-bounds Read in squashfs_get_id syzbot @ 2020-10-14 7:52 ` Fox Chen [not found] ` <300c32a1-a0de-4f05-b467-0822b3d21733n@googlegroups.com> 2021-03-11 11:23 ` [syzbot] " syzbot 2 siblings, 0 replies; 15+ messages in thread From: Fox Chen @ 2020-10-14 7:52 UTC (permalink / raw) To: phillip, syzkaller-bugs; +Cc: linux-kernel, gregkh Hi, I found this bug was caused by either uid/gid info in superblocks or id_index_table is corrupted. The uid/gid index is larger than the size of msblk->id_table. Should I add a sanity check to squashfs_get_id?? The complete solution is to record the size of msblk->id_table in msblk and check uid/gid index each time in squashfs_get_id. However, this requires a change to msblk struct. A simple solution is to calculate the max available room for uid/gid table by doing msblk->xattr_table - msblk->id_table[0] and check if index is larger than this. While this provides some sort of check, it is imperfect because id_table can be smaller than that. Both of them work out for this bug. thanks, fox On Friday, September 25, 2020 at 10:48:18 PM UTC+8 syzbot wrote: Hello, syzbot found the following issue on: HEAD commit: 171d4ff7 Merge tag 'mmc-v5.9-rc4-2' of git://git.kernel.or.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=1597ead3900000 kernel config: https://syzkaller.appspot.com/x/.config?x=af502ec9a451c9fc dashboard link: https://syzkaller.appspot.com/bug?extid=8e28bba73ed1772a6802 compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/ c2443155a0fb245c8f17f2c1c72b6ea391e86e81) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=172ff481900000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17c3e6c5900000 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+8e28bb...@syzkaller.appspotmail.com ================================================================== BUG: KASAN: slab-out-of-bounds in squashfs_get_id+0xb9/0x1c0 fs/squashfs/id.c:38 Read of size 8 at addr ffff8880a9684b98 by task syz-executor329/6836 CPU: 1 PID: 6836 Comm: syz-executor329 Not tainted 5.9.0-rc6-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1d6/0x29e lib/dump_stack.c:118 print_address_description+0x66/0x620 mm/kasan/report.c:383 __kasan_report mm/kasan/report.c:513 [inline] kasan_report+0x132/0x1d0 mm/kasan/report.c:530 squashfs_get_id+0xb9/0x1c0 fs/squashfs/id.c:38 squashfs_new_inode fs/squashfs/inode.c:51 [inline] squashfs_read_inode+0x155/0x2170 fs/squashfs/inode.c:120 squashfs_fill_super+0x1478/0x1790 fs/squashfs/super.c:310 get_tree_bdev+0x3e9/0x5f0 fs/super.c:1342 vfs_get_tree+0x88/0x270 fs/super.c:1547 do_new_mount fs/namespace.c:2875 [inline] path_mount+0x179d/0x29e0 fs/namespace.c:3192 do_mount fs/namespace.c:3205 [inline] __do_sys_mount fs/namespace.c:3413 [inline] __se_sys_mount+0x126/0x180 fs/namespace.c:3390 do_syscall_64+0x31/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x446d1a Code: b8 08 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 fd ad fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 0f 83 da ad fb ff c3 66 0f 1f 84 00 00 00 00 00 RSP: 002b:00007ffd7dd4f8b8 EFLAGS: 00000293 ORIG_RAX: 00000000000000a5 RAX: ffffffffffffffda RBX: 00007ffd7dd4f910 RCX: 0000000000446d1a RDX: 0000000020000000 RSI: 0000000020000100 RDI: 00007ffd7dd4f8d0 RBP: 00007ffd7dd4f8d0 R08: 00007ffd7dd4f910 R09: 00007ffd00000015 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000001 R13: 0000000000000004 R14: 0000000000000003 R15: 0000000000000003 Allocated by task 3913: kasan_save_stack mm/kasan/common.c:48 [inline] kasan_set_track mm/kasan/common.c:56 [inline] __kasan_kmalloc+0x100/0x130 mm/kasan/common.c:461 kmalloc_node include/linux/slab.h:577 [inline] __vmalloc_area_node mm/vmalloc.c:2429 [inline] __vmalloc_node_range+0x2c7/0x870 mm/vmalloc.c:2511 module_alloc+0x7e/0x90 arch/x86/kernel/module.c:75 bpf_jit_binary_alloc+0x123/0x230 kernel/bpf/core.c:871 bpf_int_jit_compile+0x7995/0x8920 arch/x86/net/bpf_jit_comp.c:1911 bpf_prog_select_runtime+0x76d/0xa60 kernel/bpf/core.c:1807 bpf_migrate_filter net/core/filter.c:1290 [inline] bpf_prepare_filter+0xec2/0x1140 net/core/filter.c:1338 bpf_prog_create_from_user+0x2ad/0x3e0 net/core/filter.c:1432 seccomp_prepare_filter kernel/seccomp.c:567 [inline] seccomp_prepare_user_filter kernel/seccomp.c:604 [inline] seccomp_set_mode_filter kernel/seccomp.c:1546 [inline] do_seccomp+0x852/0x20b0 kernel/seccomp.c:1661 do_syscall_64+0x31/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 The buggy address belongs to the object at ffff8880a9684b80 which belongs to the cache kmalloc-32 of size 32 The buggy address is located 24 bytes inside of 32-byte region [ffff8880a9684b80, ffff8880a9684ba0) The buggy address belongs to the page: page:00000000f697ca3d refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff8880a9684fc1 pfn:0xa9684 flags: 0xfffe0000000200(slab) raw: 00fffe0000000200 ffffea0002a5d5c8 ffffea0002a98588 ffff8880aa440100 raw: ffff8880a9684fc1 ffff8880a9684000 000000010000003f 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8880a9684a80: fa fb fb fb fc fc fc fc fa fb fb fb fc fc fc fc ffff8880a9684b00: 00 fc fc fc fc fc fc fc fa fb fb fb fc fc fc fc >ffff8880a9684b80: 00 fc fc fc fc fc fc fc fa fb fb fb fc fc fc fc ^ ffff8880a9684c00: fa fb fb fb fc fc fc fc fa fb fb fb fc fc fc fc ffff8880a9684c80: 00 00 01 fc fc fc fc fc fa fb fb fb fc fc fc fc ================================================================== --- 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. syzbot can test patches for this issue, for details see: https://goo.gl/tpsmEJ#testing-patches ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <300c32a1-a0de-4f05-b467-0822b3d21733n@googlegroups.com>]
* Re: [Linux-kernel-mentees] KASAN: slab-out-of-bounds Read in squashfs_get_id [not found] ` <300c32a1-a0de-4f05-b467-0822b3d21733n@googlegroups.com> @ 2020-10-14 7:57 ` Dmitry Vyukov via Linux-kernel-mentees 2020-10-14 8:02 ` Fox Chen 0 siblings, 1 reply; 15+ messages in thread From: Dmitry Vyukov via Linux-kernel-mentees @ 2020-10-14 7:57 UTC (permalink / raw) To: Fox Chen; +Cc: linux-kernel-mentees, syzkaller-bugs [-- Attachment #1.1: Type: text/plain, Size: 6845 bytes --] FYI Gmail has a setting of making Replay All the default button. On Wed, Oct 14, 2020 at 9:39 AM Fox Chen <foxhlchen@gmail.com> wrote: > Hi, > > I found this bug was caused by either uid/gid info in superblocks or > id_index_table is corrupted. The uid/gid index is larger than the size of > msblk->id_table. > > Should I add a sanity check to squashfs_get_id?? > > > The complete solution is to record the size of msblk->id_table in msblk > and check uid/gid index each time in squashfs_get_id. However, this > requires a change to msblk struct. > > A simple solution is to calculate the max available room for uid/gid table > by doing msblk->xattr_table - msblk->id_table[0] and check if index is > larger than this. While this provides some sort of check, it is imperfect > because id_table can be smaller than that. > > Both of them work out for this bug. > > > thanks, > fox > > On Friday, September 25, 2020 at 10:48:18 PM UTC+8 syzbot wrote: > >> Hello, >> >> syzbot found the following issue on: >> >> HEAD commit: 171d4ff7 Merge tag 'mmc-v5.9-rc4-2' of git://git.kernel.or.. >> git tree: upstream >> console output: https://syzkaller.appspot.com/x/log.txt?x=1597ead3900000 >> kernel config: https://syzkaller.appspot.com/x/.config?x=af502ec9a451c9fc >> dashboard link: >> https://syzkaller.appspot.com/bug?extid=8e28bba73ed1772a6802 >> compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/ >> c2443155a0fb245c8f17f2c1c72b6ea391e86e81) >> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=172ff481900000 >> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17c3e6c5900000 >> >> IMPORTANT: if you fix the issue, please add the following tag to the >> commit: >> Reported-by: syzbot+8e28bb...@syzkaller.appspotmail.com >> >> ================================================================== >> BUG: KASAN: slab-out-of-bounds in squashfs_get_id+0xb9/0x1c0 >> fs/squashfs/id.c:38 >> Read of size 8 at addr ffff8880a9684b98 by task syz-executor329/6836 >> >> CPU: 1 PID: 6836 Comm: syz-executor329 Not tainted 5.9.0-rc6-syzkaller #0 >> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS >> Google 01/01/2011 >> Call Trace: >> __dump_stack lib/dump_stack.c:77 [inline] >> dump_stack+0x1d6/0x29e lib/dump_stack.c:118 >> print_address_description+0x66/0x620 mm/kasan/report.c:383 >> __kasan_report mm/kasan/report.c:513 [inline] >> kasan_report+0x132/0x1d0 mm/kasan/report.c:530 >> squashfs_get_id+0xb9/0x1c0 fs/squashfs/id.c:38 >> squashfs_new_inode fs/squashfs/inode.c:51 [inline] >> squashfs_read_inode+0x155/0x2170 fs/squashfs/inode.c:120 >> squashfs_fill_super+0x1478/0x1790 fs/squashfs/super.c:310 >> get_tree_bdev+0x3e9/0x5f0 fs/super.c:1342 >> vfs_get_tree+0x88/0x270 fs/super.c:1547 >> do_new_mount fs/namespace.c:2875 [inline] >> path_mount+0x179d/0x29e0 fs/namespace.c:3192 >> do_mount fs/namespace.c:3205 [inline] >> __do_sys_mount fs/namespace.c:3413 [inline] >> __se_sys_mount+0x126/0x180 fs/namespace.c:3390 >> do_syscall_64+0x31/0x70 arch/x86/entry/common.c:46 >> entry_SYSCALL_64_after_hwframe+0x44/0xa9 >> RIP: 0033:0x446d1a >> Code: b8 08 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 fd ad fb ff c3 66 2e >> 0f 1f 84 00 00 00 00 00 66 90 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 >> ff ff 0f 83 da ad fb ff c3 66 0f 1f 84 00 00 00 00 00 >> RSP: 002b:00007ffd7dd4f8b8 EFLAGS: 00000293 ORIG_RAX: 00000000000000a5 >> RAX: ffffffffffffffda RBX: 00007ffd7dd4f910 RCX: 0000000000446d1a >> RDX: 0000000020000000 RSI: 0000000020000100 RDI: 00007ffd7dd4f8d0 >> RBP: 00007ffd7dd4f8d0 R08: 00007ffd7dd4f910 R09: 00007ffd00000015 >> R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000001 >> R13: 0000000000000004 R14: 0000000000000003 R15: 0000000000000003 >> >> Allocated by task 3913: >> kasan_save_stack mm/kasan/common.c:48 [inline] >> kasan_set_track mm/kasan/common.c:56 [inline] >> __kasan_kmalloc+0x100/0x130 mm/kasan/common.c:461 >> kmalloc_node include/linux/slab.h:577 [inline] >> __vmalloc_area_node mm/vmalloc.c:2429 [inline] >> __vmalloc_node_range+0x2c7/0x870 mm/vmalloc.c:2511 >> module_alloc+0x7e/0x90 arch/x86/kernel/module.c:75 >> bpf_jit_binary_alloc+0x123/0x230 kernel/bpf/core.c:871 >> bpf_int_jit_compile+0x7995/0x8920 arch/x86/net/bpf_jit_comp.c:1911 >> bpf_prog_select_runtime+0x76d/0xa60 kernel/bpf/core.c:1807 >> bpf_migrate_filter net/core/filter.c:1290 [inline] >> bpf_prepare_filter+0xec2/0x1140 net/core/filter.c:1338 >> bpf_prog_create_from_user+0x2ad/0x3e0 net/core/filter.c:1432 >> seccomp_prepare_filter kernel/seccomp.c:567 [inline] >> seccomp_prepare_user_filter kernel/seccomp.c:604 [inline] >> seccomp_set_mode_filter kernel/seccomp.c:1546 [inline] >> do_seccomp+0x852/0x20b0 kernel/seccomp.c:1661 >> do_syscall_64+0x31/0x70 arch/x86/entry/common.c:46 >> entry_SYSCALL_64_after_hwframe+0x44/0xa9 >> >> The buggy address belongs to the object at ffff8880a9684b80 >> which belongs to the cache kmalloc-32 of size 32 >> The buggy address is located 24 bytes inside of >> 32-byte region [ffff8880a9684b80, ffff8880a9684ba0) >> The buggy address belongs to the page: >> page:00000000f697ca3d refcount:1 mapcount:0 mapping:0000000000000000 >> index:0xffff8880a9684fc1 pfn:0xa9684 >> flags: 0xfffe0000000200(slab) >> raw: 00fffe0000000200 ffffea0002a5d5c8 ffffea0002a98588 ffff8880aa440100 >> raw: ffff8880a9684fc1 ffff8880a9684000 000000010000003f 0000000000000000 >> page dumped because: kasan: bad access detected >> >> Memory state around the buggy address: >> ffff8880a9684a80: fa fb fb fb fc fc fc fc fa fb fb fb fc fc fc fc >> ffff8880a9684b00: 00 fc fc fc fc fc fc fc fa fb fb fb fc fc fc fc >> >ffff8880a9684b80: 00 fc fc fc fc fc fc fc fa fb fb fb fc fc fc fc >> ^ >> ffff8880a9684c00: fa fb fb fb fc fc fc fc fa fb fb fb fc fc fc fc >> ffff8880a9684c80: 00 00 01 fc fc fc fc fc fa fb fb fb fc fc fc fc >> ================================================================== >> >> >> --- >> 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. >> syzbot can test patches for this issue, for details see: >> https://goo.gl/tpsmEJ#testing-patches >> > -- > You received this message because you are subscribed to the Google Groups > "syzkaller-bugs" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to syzkaller-bugs+unsubscribe@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/syzkaller-bugs/300c32a1-a0de-4f05-b467-0822b3d21733n%40googlegroups.com > <https://groups.google.com/d/msgid/syzkaller-bugs/300c32a1-a0de-4f05-b467-0822b3d21733n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > [-- Attachment #1.2: Type: text/html, Size: 8815 bytes --] [-- Attachment #2: Type: text/plain, Size: 201 bytes --] _______________________________________________ Linux-kernel-mentees mailing list Linux-kernel-mentees@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Linux-kernel-mentees] KASAN: slab-out-of-bounds Read in squashfs_get_id 2020-10-14 7:57 ` [Linux-kernel-mentees] " Dmitry Vyukov via Linux-kernel-mentees @ 2020-10-14 8:02 ` Fox Chen 2020-10-14 8:27 ` Dmitry Vyukov via Linux-kernel-mentees 0 siblings, 1 reply; 15+ messages in thread From: Fox Chen @ 2020-10-14 8:02 UTC (permalink / raw) To: Dmitry Vyukov; +Cc: linux-kernel-mentees, syzkaller-bugs Oh, Thank you, Dmitry! I firstly replied to this from https://groups.google.com/g/syzkaller-bugs/c/SPtlDDI7jmw/m/BtgjaCcDAwAJ. I don't know why "reply all" only replies to syzkaller-bugs and I didn't notice that. Sorry about that. On Wed, Oct 14, 2020 at 3:57 PM Dmitry Vyukov <dvyukov@google.com> wrote: > > FYI Gmail has a setting of making Replay All the default button. > > > On Wed, Oct 14, 2020 at 9:39 AM Fox Chen <foxhlchen@gmail.com> wrote: >> >> Hi, >> >> I found this bug was caused by either uid/gid info in superblocks or id_index_table is corrupted. The uid/gid index is larger than the size of msblk->id_table. >> >> Should I add a sanity check to squashfs_get_id?? >> >> >> The complete solution is to record the size of msblk->id_table in msblk and check uid/gid index each time in squashfs_get_id. However, this requires a change to msblk struct. >> >> A simple solution is to calculate the max available room for uid/gid table by doing msblk->xattr_table - msblk->id_table[0] and check if index is larger than this. While this provides some sort of check, it is imperfect because id_table can be smaller than that. >> >> Both of them work out for this bug. >> >> >> thanks, >> fox >> >> On Friday, September 25, 2020 at 10:48:18 PM UTC+8 syzbot wrote: >>> >>> Hello, >>> >>> syzbot found the following issue on: >>> >>> HEAD commit: 171d4ff7 Merge tag 'mmc-v5.9-rc4-2' of git://git.kernel.or.. >>> git tree: upstream >>> console output: https://syzkaller.appspot.com/x/log.txt?x=1597ead3900000 >>> kernel config: https://syzkaller.appspot.com/x/.config?x=af502ec9a451c9fc >>> dashboard link: https://syzkaller.appspot.com/bug?extid=8e28bba73ed1772a6802 >>> compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/ c2443155a0fb245c8f17f2c1c72b6ea391e86e81) >>> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=172ff481900000 >>> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17c3e6c5900000 >>> >>> IMPORTANT: if you fix the issue, please add the following tag to the commit: >>> Reported-by: syzbot+8e28bb...@syzkaller.appspotmail.com >>> >>> ================================================================== >>> BUG: KASAN: slab-out-of-bounds in squashfs_get_id+0xb9/0x1c0 fs/squashfs/id.c:38 >>> Read of size 8 at addr ffff8880a9684b98 by task syz-executor329/6836 >>> >>> CPU: 1 PID: 6836 Comm: syz-executor329 Not tainted 5.9.0-rc6-syzkaller #0 >>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 >>> Call Trace: >>> __dump_stack lib/dump_stack.c:77 [inline] >>> dump_stack+0x1d6/0x29e lib/dump_stack.c:118 >>> print_address_description+0x66/0x620 mm/kasan/report.c:383 >>> __kasan_report mm/kasan/report.c:513 [inline] >>> kasan_report+0x132/0x1d0 mm/kasan/report.c:530 >>> squashfs_get_id+0xb9/0x1c0 fs/squashfs/id.c:38 >>> squashfs_new_inode fs/squashfs/inode.c:51 [inline] >>> squashfs_read_inode+0x155/0x2170 fs/squashfs/inode.c:120 >>> squashfs_fill_super+0x1478/0x1790 fs/squashfs/super.c:310 >>> get_tree_bdev+0x3e9/0x5f0 fs/super.c:1342 >>> vfs_get_tree+0x88/0x270 fs/super.c:1547 >>> do_new_mount fs/namespace.c:2875 [inline] >>> path_mount+0x179d/0x29e0 fs/namespace.c:3192 >>> do_mount fs/namespace.c:3205 [inline] >>> __do_sys_mount fs/namespace.c:3413 [inline] >>> __se_sys_mount+0x126/0x180 fs/namespace.c:3390 >>> do_syscall_64+0x31/0x70 arch/x86/entry/common.c:46 >>> entry_SYSCALL_64_after_hwframe+0x44/0xa9 >>> RIP: 0033:0x446d1a >>> Code: b8 08 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 fd ad fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 0f 83 da ad fb ff c3 66 0f 1f 84 00 00 00 00 00 >>> RSP: 002b:00007ffd7dd4f8b8 EFLAGS: 00000293 ORIG_RAX: 00000000000000a5 >>> RAX: ffffffffffffffda RBX: 00007ffd7dd4f910 RCX: 0000000000446d1a >>> RDX: 0000000020000000 RSI: 0000000020000100 RDI: 00007ffd7dd4f8d0 >>> RBP: 00007ffd7dd4f8d0 R08: 00007ffd7dd4f910 R09: 00007ffd00000015 >>> R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000001 >>> R13: 0000000000000004 R14: 0000000000000003 R15: 0000000000000003 >>> >>> Allocated by task 3913: >>> kasan_save_stack mm/kasan/common.c:48 [inline] >>> kasan_set_track mm/kasan/common.c:56 [inline] >>> __kasan_kmalloc+0x100/0x130 mm/kasan/common.c:461 >>> kmalloc_node include/linux/slab.h:577 [inline] >>> __vmalloc_area_node mm/vmalloc.c:2429 [inline] >>> __vmalloc_node_range+0x2c7/0x870 mm/vmalloc.c:2511 >>> module_alloc+0x7e/0x90 arch/x86/kernel/module.c:75 >>> bpf_jit_binary_alloc+0x123/0x230 kernel/bpf/core.c:871 >>> bpf_int_jit_compile+0x7995/0x8920 arch/x86/net/bpf_jit_comp.c:1911 >>> bpf_prog_select_runtime+0x76d/0xa60 kernel/bpf/core.c:1807 >>> bpf_migrate_filter net/core/filter.c:1290 [inline] >>> bpf_prepare_filter+0xec2/0x1140 net/core/filter.c:1338 >>> bpf_prog_create_from_user+0x2ad/0x3e0 net/core/filter.c:1432 >>> seccomp_prepare_filter kernel/seccomp.c:567 [inline] >>> seccomp_prepare_user_filter kernel/seccomp.c:604 [inline] >>> seccomp_set_mode_filter kernel/seccomp.c:1546 [inline] >>> do_seccomp+0x852/0x20b0 kernel/seccomp.c:1661 >>> do_syscall_64+0x31/0x70 arch/x86/entry/common.c:46 >>> entry_SYSCALL_64_after_hwframe+0x44/0xa9 >>> >>> The buggy address belongs to the object at ffff8880a9684b80 >>> which belongs to the cache kmalloc-32 of size 32 >>> The buggy address is located 24 bytes inside of >>> 32-byte region [ffff8880a9684b80, ffff8880a9684ba0) >>> The buggy address belongs to the page: >>> page:00000000f697ca3d refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff8880a9684fc1 pfn:0xa9684 >>> flags: 0xfffe0000000200(slab) >>> raw: 00fffe0000000200 ffffea0002a5d5c8 ffffea0002a98588 ffff8880aa440100 >>> raw: ffff8880a9684fc1 ffff8880a9684000 000000010000003f 0000000000000000 >>> page dumped because: kasan: bad access detected >>> >>> Memory state around the buggy address: >>> ffff8880a9684a80: fa fb fb fb fc fc fc fc fa fb fb fb fc fc fc fc >>> ffff8880a9684b00: 00 fc fc fc fc fc fc fc fa fb fb fb fc fc fc fc >>> >ffff8880a9684b80: 00 fc fc fc fc fc fc fc fa fb fb fb fc fc fc fc >>> ^ >>> ffff8880a9684c00: fa fb fb fb fc fc fc fc fa fb fb fb fc fc fc fc >>> ffff8880a9684c80: 00 00 01 fc fc fc fc fc fa fb fb fb fc fc fc fc >>> ================================================================== >>> >>> >>> --- >>> 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. >>> syzbot can test patches for this issue, for details see: >>> https://goo.gl/tpsmEJ#testing-patches >> >> -- >> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group. >> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com. >> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/300c32a1-a0de-4f05-b467-0822b3d21733n%40googlegroups.com. _______________________________________________ Linux-kernel-mentees mailing list Linux-kernel-mentees@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Linux-kernel-mentees] KASAN: slab-out-of-bounds Read in squashfs_get_id 2020-10-14 8:02 ` Fox Chen @ 2020-10-14 8:27 ` Dmitry Vyukov via Linux-kernel-mentees 2020-10-14 9:13 ` Fox Chen 0 siblings, 1 reply; 15+ messages in thread From: Dmitry Vyukov via Linux-kernel-mentees @ 2020-10-14 8:27 UTC (permalink / raw) To: Fox Chen; +Cc: linux-kernel-mentees, syzkaller-bugs On Wed, Oct 14, 2020 at 10:02 AM Fox Chen <foxhlchen@gmail.com> wrote: > > Oh, Thank you, Dmitry! > > I firstly replied to this from > https://groups.google.com/g/syzkaller-bugs/c/SPtlDDI7jmw/m/BtgjaCcDAwAJ. > I don't know why "reply all" only replies to syzkaller-bugs and I > didn't notice that. > > Sorry about that. Oh, from groups. Yes, that won't work for the kernel. That also generated an HTML email, which is generally not welcome on kernel mailing lists. > On Wed, Oct 14, 2020 at 3:57 PM Dmitry Vyukov <dvyukov@google.com> wrote: > > > > FYI Gmail has a setting of making Replay All the default button. > > > > > > On Wed, Oct 14, 2020 at 9:39 AM Fox Chen <foxhlchen@gmail.com> wrote: > >> > >> Hi, > >> > >> I found this bug was caused by either uid/gid info in superblocks or id_index_table is corrupted. The uid/gid index is larger than the size of msblk->id_table. > >> > >> Should I add a sanity check to squashfs_get_id?? > >> > >> > >> The complete solution is to record the size of msblk->id_table in msblk and check uid/gid index each time in squashfs_get_id. However, this requires a change to msblk struct. > >> > >> A simple solution is to calculate the max available room for uid/gid table by doing msblk->xattr_table - msblk->id_table[0] and check if index is larger than this. While this provides some sort of check, it is imperfect because id_table can be smaller than that. > >> > >> Both of them work out for this bug. > >> > >> > >> thanks, > >> fox > >> > >> On Friday, September 25, 2020 at 10:48:18 PM UTC+8 syzbot wrote: > >>> > >>> Hello, > >>> > >>> syzbot found the following issue on: > >>> > >>> HEAD commit: 171d4ff7 Merge tag 'mmc-v5.9-rc4-2' of git://git.kernel.or.. > >>> git tree: upstream > >>> console output: https://syzkaller.appspot.com/x/log.txt?x=1597ead3900000 > >>> kernel config: https://syzkaller.appspot.com/x/.config?x=af502ec9a451c9fc > >>> dashboard link: https://syzkaller.appspot.com/bug?extid=8e28bba73ed1772a6802 > >>> compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/ c2443155a0fb245c8f17f2c1c72b6ea391e86e81) > >>> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=172ff481900000 > >>> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17c3e6c5900000 > >>> > >>> IMPORTANT: if you fix the issue, please add the following tag to the commit: > >>> Reported-by: syzbot+8e28bb...@syzkaller.appspotmail.com > >>> > >>> ================================================================== > >>> BUG: KASAN: slab-out-of-bounds in squashfs_get_id+0xb9/0x1c0 fs/squashfs/id.c:38 > >>> Read of size 8 at addr ffff8880a9684b98 by task syz-executor329/6836 > >>> > >>> CPU: 1 PID: 6836 Comm: syz-executor329 Not tainted 5.9.0-rc6-syzkaller #0 > >>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 > >>> Call Trace: > >>> __dump_stack lib/dump_stack.c:77 [inline] > >>> dump_stack+0x1d6/0x29e lib/dump_stack.c:118 > >>> print_address_description+0x66/0x620 mm/kasan/report.c:383 > >>> __kasan_report mm/kasan/report.c:513 [inline] > >>> kasan_report+0x132/0x1d0 mm/kasan/report.c:530 > >>> squashfs_get_id+0xb9/0x1c0 fs/squashfs/id.c:38 > >>> squashfs_new_inode fs/squashfs/inode.c:51 [inline] > >>> squashfs_read_inode+0x155/0x2170 fs/squashfs/inode.c:120 > >>> squashfs_fill_super+0x1478/0x1790 fs/squashfs/super.c:310 > >>> get_tree_bdev+0x3e9/0x5f0 fs/super.c:1342 > >>> vfs_get_tree+0x88/0x270 fs/super.c:1547 > >>> do_new_mount fs/namespace.c:2875 [inline] > >>> path_mount+0x179d/0x29e0 fs/namespace.c:3192 > >>> do_mount fs/namespace.c:3205 [inline] > >>> __do_sys_mount fs/namespace.c:3413 [inline] > >>> __se_sys_mount+0x126/0x180 fs/namespace.c:3390 > >>> do_syscall_64+0x31/0x70 arch/x86/entry/common.c:46 > >>> entry_SYSCALL_64_after_hwframe+0x44/0xa9 > >>> RIP: 0033:0x446d1a > >>> Code: b8 08 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 fd ad fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 0f 83 da ad fb ff c3 66 0f 1f 84 00 00 00 00 00 > >>> RSP: 002b:00007ffd7dd4f8b8 EFLAGS: 00000293 ORIG_RAX: 00000000000000a5 > >>> RAX: ffffffffffffffda RBX: 00007ffd7dd4f910 RCX: 0000000000446d1a > >>> RDX: 0000000020000000 RSI: 0000000020000100 RDI: 00007ffd7dd4f8d0 > >>> RBP: 00007ffd7dd4f8d0 R08: 00007ffd7dd4f910 R09: 00007ffd00000015 > >>> R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000001 > >>> R13: 0000000000000004 R14: 0000000000000003 R15: 0000000000000003 > >>> > >>> Allocated by task 3913: > >>> kasan_save_stack mm/kasan/common.c:48 [inline] > >>> kasan_set_track mm/kasan/common.c:56 [inline] > >>> __kasan_kmalloc+0x100/0x130 mm/kasan/common.c:461 > >>> kmalloc_node include/linux/slab.h:577 [inline] > >>> __vmalloc_area_node mm/vmalloc.c:2429 [inline] > >>> __vmalloc_node_range+0x2c7/0x870 mm/vmalloc.c:2511 > >>> module_alloc+0x7e/0x90 arch/x86/kernel/module.c:75 > >>> bpf_jit_binary_alloc+0x123/0x230 kernel/bpf/core.c:871 > >>> bpf_int_jit_compile+0x7995/0x8920 arch/x86/net/bpf_jit_comp.c:1911 > >>> bpf_prog_select_runtime+0x76d/0xa60 kernel/bpf/core.c:1807 > >>> bpf_migrate_filter net/core/filter.c:1290 [inline] > >>> bpf_prepare_filter+0xec2/0x1140 net/core/filter.c:1338 > >>> bpf_prog_create_from_user+0x2ad/0x3e0 net/core/filter.c:1432 > >>> seccomp_prepare_filter kernel/seccomp.c:567 [inline] > >>> seccomp_prepare_user_filter kernel/seccomp.c:604 [inline] > >>> seccomp_set_mode_filter kernel/seccomp.c:1546 [inline] > >>> do_seccomp+0x852/0x20b0 kernel/seccomp.c:1661 > >>> do_syscall_64+0x31/0x70 arch/x86/entry/common.c:46 > >>> entry_SYSCALL_64_after_hwframe+0x44/0xa9 > >>> > >>> The buggy address belongs to the object at ffff8880a9684b80 > >>> which belongs to the cache kmalloc-32 of size 32 > >>> The buggy address is located 24 bytes inside of > >>> 32-byte region [ffff8880a9684b80, ffff8880a9684ba0) > >>> The buggy address belongs to the page: > >>> page:00000000f697ca3d refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff8880a9684fc1 pfn:0xa9684 > >>> flags: 0xfffe0000000200(slab) > >>> raw: 00fffe0000000200 ffffea0002a5d5c8 ffffea0002a98588 ffff8880aa440100 > >>> raw: ffff8880a9684fc1 ffff8880a9684000 000000010000003f 0000000000000000 > >>> page dumped because: kasan: bad access detected > >>> > >>> Memory state around the buggy address: > >>> ffff8880a9684a80: fa fb fb fb fc fc fc fc fa fb fb fb fc fc fc fc > >>> ffff8880a9684b00: 00 fc fc fc fc fc fc fc fa fb fb fb fc fc fc fc > >>> >ffff8880a9684b80: 00 fc fc fc fc fc fc fc fa fb fb fb fc fc fc fc > >>> ^ > >>> ffff8880a9684c00: fa fb fb fb fc fc fc fc fa fb fb fb fc fc fc fc > >>> ffff8880a9684c80: 00 00 01 fc fc fc fc fc fa fb fb fb fc fc fc fc > >>> ================================================================== > >>> > >>> > >>> --- > >>> 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. > >>> syzbot can test patches for this issue, for details see: > >>> https://goo.gl/tpsmEJ#testing-patches > >> > >> -- > >> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group. > >> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com. > >> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/300c32a1-a0de-4f05-b467-0822b3d21733n%40googlegroups.com. _______________________________________________ Linux-kernel-mentees mailing list Linux-kernel-mentees@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Linux-kernel-mentees] KASAN: slab-out-of-bounds Read in squashfs_get_id 2020-10-14 8:27 ` Dmitry Vyukov via Linux-kernel-mentees @ 2020-10-14 9:13 ` Fox Chen 2020-10-14 9:21 ` Dmitry Vyukov via Linux-kernel-mentees 2020-10-14 9:53 ` Greg KH 0 siblings, 2 replies; 15+ messages in thread From: Fox Chen @ 2020-10-14 9:13 UTC (permalink / raw) To: Dmitry Vyukov; +Cc: linux-kernel-mentees, syzkaller-bugs On Wed, Oct 14, 2020 at 4:27 PM Dmitry Vyukov <dvyukov@google.com> wrote: > > Oh, from groups. Yes, that won't work for the kernel. That also > generated an HTML email, which is generally not welcome on kernel > mailing lists. > Got it! thank you! If I miss the original email, without using "groups", how can I reply to the thread?? Apart from manually copying/pasting the content, recipients, and setting in-reply-to, Is there any convenient way?? _______________________________________________ Linux-kernel-mentees mailing list Linux-kernel-mentees@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Linux-kernel-mentees] KASAN: slab-out-of-bounds Read in squashfs_get_id 2020-10-14 9:13 ` Fox Chen @ 2020-10-14 9:21 ` Dmitry Vyukov via Linux-kernel-mentees 2020-10-14 9:24 ` Fox Chen 2020-10-14 9:28 ` Lukas Bulwahn 2020-10-14 9:53 ` Greg KH 1 sibling, 2 replies; 15+ messages in thread From: Dmitry Vyukov via Linux-kernel-mentees @ 2020-10-14 9:21 UTC (permalink / raw) To: Fox Chen; +Cc: linux-kernel-mentees, syzkaller-bugs On Wed, Oct 14, 2020 at 11:13 AM Fox Chen <foxhlchen@gmail.com> wrote: > > Oh, from groups. Yes, that won't work for the kernel. That also > > generated an HTML email, which is generally not welcome on kernel > > mailing lists. > > > > Got it! thank you! > > If I miss the original email, without using "groups", how can I reply > to the thread?? > Apart from manually copying/pasting the content, recipients, and > setting in-reply-to, Is there any convenient way?? No, unfortunately, no convenient way. Nature of email-based development workflow. I think I've seen some web archives in the past that allowed you to forward an email to yourself, and then you can reply to it normally. But I don't remember where it was. Maybe you can find it. _______________________________________________ Linux-kernel-mentees mailing list Linux-kernel-mentees@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Linux-kernel-mentees] KASAN: slab-out-of-bounds Read in squashfs_get_id 2020-10-14 9:21 ` Dmitry Vyukov via Linux-kernel-mentees @ 2020-10-14 9:24 ` Fox Chen 2020-10-14 9:28 ` Lukas Bulwahn 1 sibling, 0 replies; 15+ messages in thread From: Fox Chen @ 2020-10-14 9:24 UTC (permalink / raw) To: Dmitry Vyukov; +Cc: linux-kernel-mentees, syzkaller-bugs umm, bittersweet :) Thank you, I'll check it out. _______________________________________________ Linux-kernel-mentees mailing list Linux-kernel-mentees@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Linux-kernel-mentees] KASAN: slab-out-of-bounds Read in squashfs_get_id 2020-10-14 9:21 ` Dmitry Vyukov via Linux-kernel-mentees 2020-10-14 9:24 ` Fox Chen @ 2020-10-14 9:28 ` Lukas Bulwahn 2020-10-14 9:33 ` Fox Chen 2020-10-14 9:36 ` Dmitry Vyukov via Linux-kernel-mentees 1 sibling, 2 replies; 15+ messages in thread From: Lukas Bulwahn @ 2020-10-14 9:28 UTC (permalink / raw) To: Dmitry Vyukov; +Cc: syzkaller-bugs, linux-kernel-mentees, Fox Chen On Wed, Oct 14, 2020 at 11:21 AM Dmitry Vyukov via Linux-kernel-mentees <linux-kernel-mentees@lists.linuxfoundation.org> wrote: > > On Wed, Oct 14, 2020 at 11:13 AM Fox Chen <foxhlchen@gmail.com> wrote: > > > Oh, from groups. Yes, that won't work for the kernel. That also > > > generated an HTML email, which is generally not welcome on kernel > > > mailing lists. > > > > > > > Got it! thank you! > > > > If I miss the original email, without using "groups", how can I reply > > to the thread?? > > Apart from manually copying/pasting the content, recipients, and > > setting in-reply-to, Is there any convenient way?? > > No, unfortunately, no convenient way. Nature of email-based > development workflow. > > I think I've seen some web archives in the past that allowed you to > forward an email to yourself, and then you can reply to it normally. > But I don't remember where it was. Maybe you can find it. > If the mailing list is archived on lore.kernel.org (https://lore.kernel.org/lists.html), you can search the email there and you will find a suitable mailto link (which might work for your client) Alternatively, you can download an mbox, load that with an email client, and then respond from mutt, pine etc. syzkaller-bugs is not archived at lore.kernel.org, but I assumed all those emails there also go out to lkml. If useful, we could ask to archive syzkaller-bugs on lore.kernel.org as well. Lukas _______________________________________________ Linux-kernel-mentees mailing list Linux-kernel-mentees@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Linux-kernel-mentees] KASAN: slab-out-of-bounds Read in squashfs_get_id 2020-10-14 9:28 ` Lukas Bulwahn @ 2020-10-14 9:33 ` Fox Chen 2020-10-14 9:36 ` Dmitry Vyukov via Linux-kernel-mentees 1 sibling, 0 replies; 15+ messages in thread From: Fox Chen @ 2020-10-14 9:33 UTC (permalink / raw) To: Lukas Bulwahn; +Cc: syzkaller-bugs, linux-kernel-mentees, Dmitry Vyukov Hi Lukas, > If the mailing list is archived on lore.kernel.org > (https://lore.kernel.org/lists.html), you can search the email there > and you will find a suitable mailto link (which might work for your > client) > > Alternatively, you can download an mbox, load that with an email > client, and then respond from mutt, pine etc. Oh, Great! > syzkaller-bugs is not archived at lore.kernel.org, but I assumed all > those emails there also go out to lkml. > > If useful, we could ask to archive syzkaller-bugs on lore.kernel.org as well. > Yes, that would be helpful. thanks, fox _______________________________________________ Linux-kernel-mentees mailing list Linux-kernel-mentees@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Linux-kernel-mentees] KASAN: slab-out-of-bounds Read in squashfs_get_id 2020-10-14 9:28 ` Lukas Bulwahn 2020-10-14 9:33 ` Fox Chen @ 2020-10-14 9:36 ` Dmitry Vyukov via Linux-kernel-mentees 1 sibling, 0 replies; 15+ messages in thread From: Dmitry Vyukov via Linux-kernel-mentees @ 2020-10-14 9:36 UTC (permalink / raw) To: Lukas Bulwahn; +Cc: syzkaller-bugs, linux-kernel-mentees, Fox Chen On Wed, Oct 14, 2020 at 11:28 AM Lukas Bulwahn <lukas.bulwahn@gmail.com> wrote: > > On Wed, Oct 14, 2020 at 11:21 AM Dmitry Vyukov via > Linux-kernel-mentees <linux-kernel-mentees@lists.linuxfoundation.org> > wrote: > > > > On Wed, Oct 14, 2020 at 11:13 AM Fox Chen <foxhlchen@gmail.com> wrote: > > > > Oh, from groups. Yes, that won't work for the kernel. That also > > > > generated an HTML email, which is generally not welcome on kernel > > > > mailing lists. > > > > > > > > > > Got it! thank you! > > > > > > If I miss the original email, without using "groups", how can I reply > > > to the thread?? > > > Apart from manually copying/pasting the content, recipients, and > > > setting in-reply-to, Is there any convenient way?? > > > > No, unfortunately, no convenient way. Nature of email-based > > development workflow. > > > > I think I've seen some web archives in the past that allowed you to > > forward an email to yourself, and then you can reply to it normally. > > But I don't remember where it was. Maybe you can find it. > > > > If the mailing list is archived on lore.kernel.org > (https://lore.kernel.org/lists.html), you can search the email there > and you will find a suitable mailto link (which might work for your > client) > > Alternatively, you can download an mbox, load that with an email > client, and then respond from mutt, pine etc. > > syzkaller-bugs is not archived at lore.kernel.org, but I assumed all > those emails there also go out to lkml. > > If useful, we could ask to archive syzkaller-bugs on lore.kernel.org as well. All syzbot emails are also CCed to LKML, so searching linux-kernel should do. _______________________________________________ Linux-kernel-mentees mailing list Linux-kernel-mentees@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Linux-kernel-mentees] KASAN: slab-out-of-bounds Read in squashfs_get_id 2020-10-14 9:13 ` Fox Chen 2020-10-14 9:21 ` Dmitry Vyukov via Linux-kernel-mentees @ 2020-10-14 9:53 ` Greg KH 2020-10-14 12:51 ` Fox Chen 1 sibling, 1 reply; 15+ messages in thread From: Greg KH @ 2020-10-14 9:53 UTC (permalink / raw) To: Fox Chen; +Cc: syzkaller-bugs, linux-kernel-mentees, Dmitry Vyukov On Wed, Oct 14, 2020 at 05:13:29PM +0800, Fox Chen wrote: > On Wed, Oct 14, 2020 at 4:27 PM Dmitry Vyukov <dvyukov@google.com> wrote: > > > > Oh, from groups. Yes, that won't work for the kernel. That also > > generated an HTML email, which is generally not welcome on kernel > > mailing lists. > > > > Got it! thank you! > > If I miss the original email, without using "groups", how can I reply > to the thread?? If the tool lets you, just download the "raw" message, and load it in your email client and respond to it from there. I know lore.kernel.org has the option to save it this way, then just use a mail client like mutt: mutt -f message_downloaded.txt and away you go. If your email client does not let you do this, perhaps you need a better email client :) thanks, greg k-h _______________________________________________ Linux-kernel-mentees mailing list Linux-kernel-mentees@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Linux-kernel-mentees] KASAN: slab-out-of-bounds Read in squashfs_get_id 2020-10-14 9:53 ` Greg KH @ 2020-10-14 12:51 ` Fox Chen 0 siblings, 0 replies; 15+ messages in thread From: Fox Chen @ 2020-10-14 12:51 UTC (permalink / raw) To: Greg KH, Dmitry Vyukov, Anant Thazhemadam Cc: syzkaller-bugs, linux-kernel-mentees Hi Anant, Dmitry, Greg, Wow, mbox & raw work. lore has mailto link, just on-click, even more convenient. And, yes, I've found the mail on linux-kernel list. Thank you all for the help! :) Cheers! fox _______________________________________________ Linux-kernel-mentees mailing list Linux-kernel-mentees@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [syzbot] KASAN: slab-out-of-bounds Read in squashfs_get_id 2020-09-25 14:48 KASAN: slab-out-of-bounds Read in squashfs_get_id syzbot 2020-10-14 7:52 ` Fox Chen [not found] ` <300c32a1-a0de-4f05-b467-0822b3d21733n@googlegroups.com> @ 2021-03-11 11:23 ` syzbot 2021-03-11 15:04 ` Dmitry Vyukov 2 siblings, 1 reply; 15+ messages in thread From: syzbot @ 2021-03-11 11:23 UTC (permalink / raw) To: akpm, foxhlchen, gregkh, linux-kernel, phillip, syzkaller-bugs, torvalds syzbot suspects this issue was fixed by commit: commit e812cbbbbbb15adbbbee176baa1e8bda53059bf0 Author: Phillip Lougher <phillip@squashfs.org.uk> Date: Tue Feb 9 21:41:50 2021 +0000 squashfs: avoid out of bounds writes in decompressors bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=11bfa48ad00000 start commit: cd796ed3 Merge tag 'trace-v5.10-rc7' of git://git.kernel.o.. git tree: upstream kernel config: https://syzkaller.appspot.com/x/.config?x=59df2a4dced5f928 dashboard link: https://syzkaller.appspot.com/bug?extid=8e28bba73ed1772a6802 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1138f80f500000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=125e080f500000 If the result looks correct, please mark the issue as fixed by replying with: #syz fix: squashfs: avoid out of bounds writes in decompressors For information about bisection process see: https://goo.gl/tpsmEJ#bisection ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [syzbot] KASAN: slab-out-of-bounds Read in squashfs_get_id 2021-03-11 11:23 ` [syzbot] " syzbot @ 2021-03-11 15:04 ` Dmitry Vyukov 0 siblings, 0 replies; 15+ messages in thread From: Dmitry Vyukov @ 2021-03-11 15:04 UTC (permalink / raw) To: syzbot Cc: Andrew Morton, Fox Chen, Greg Kroah-Hartman, LKML, phillip, syzkaller-bugs, Linus Torvalds On Thu, Mar 11, 2021 at 12:23 PM syzbot <syzbot+8e28bba73ed1772a6802@syzkaller.appspotmail.com> wrote: > > syzbot suspects this issue was fixed by commit: > > commit e812cbbbbbb15adbbbee176baa1e8bda53059bf0 > Author: Phillip Lougher <phillip@squashfs.org.uk> > Date: Tue Feb 9 21:41:50 2021 +0000 > > squashfs: avoid out of bounds writes in decompressors > > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=11bfa48ad00000 > start commit: cd796ed3 Merge tag 'trace-v5.10-rc7' of git://git.kernel.o.. > git tree: upstream > kernel config: https://syzkaller.appspot.com/x/.config?x=59df2a4dced5f928 > dashboard link: https://syzkaller.appspot.com/bug?extid=8e28bba73ed1772a6802 > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1138f80f500000 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=125e080f500000 > > If the result looks correct, please mark the issue as fixed by replying with: > > #syz fix: squashfs: avoid out of bounds writes in decompressors > > For information about bisection process see: https://goo.gl/tpsmEJ#bisection Looks reasonable: #syz fix: squashfs: avoid out of bounds writes in decompressors ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2021-03-11 15:05 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-09-25 14:48 KASAN: slab-out-of-bounds Read in squashfs_get_id syzbot
2020-10-14 7:52 ` Fox Chen
[not found] ` <300c32a1-a0de-4f05-b467-0822b3d21733n@googlegroups.com>
2020-10-14 7:57 ` [Linux-kernel-mentees] " Dmitry Vyukov via Linux-kernel-mentees
2020-10-14 8:02 ` Fox Chen
2020-10-14 8:27 ` Dmitry Vyukov via Linux-kernel-mentees
2020-10-14 9:13 ` Fox Chen
2020-10-14 9:21 ` Dmitry Vyukov via Linux-kernel-mentees
2020-10-14 9:24 ` Fox Chen
2020-10-14 9:28 ` Lukas Bulwahn
2020-10-14 9:33 ` Fox Chen
2020-10-14 9:36 ` Dmitry Vyukov via Linux-kernel-mentees
2020-10-14 9:53 ` Greg KH
2020-10-14 12:51 ` Fox Chen
2021-03-11 11:23 ` [syzbot] " syzbot
2021-03-11 15:04 ` Dmitry Vyukov
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.