KASAN: slab-out-of-bounds Read in squashfs_get_id

KASAN: slab-out-of-bounds Read in squashfs_get_id

[syzbot]

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

Re: KASAN: slab-out-of-bounds Read in squashfs_get_id

[Fox Chen]

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

Re: [Linux-kernel-mentees] KASAN: slab-out-of-bounds Read in squashfs_get_id

[Dmitry Vyukov via Linux-kernel-mentees]

[-- 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

Re: [Linux-kernel-mentees] KASAN: slab-out-of-bounds Read in squashfs_get_id

[Fox Chen]

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

Re: [Linux-kernel-mentees] KASAN: slab-out-of-bounds Read in squashfs_get_id

[Dmitry Vyukov via Linux-kernel-mentees]

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

Re: [Linux-kernel-mentees] KASAN: slab-out-of-bounds Read in squashfs_get_id

[Fox Chen]

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

Re: [Linux-kernel-mentees] KASAN: slab-out-of-bounds Read in squashfs_get_id

[Dmitry Vyukov via Linux-kernel-mentees]

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

Re: [Linux-kernel-mentees] KASAN: slab-out-of-bounds Read in squashfs_get_id

[Fox Chen]

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

Re: [Linux-kernel-mentees] KASAN: slab-out-of-bounds Read in squashfs_get_id

[Lukas Bulwahn]

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

Re: [Linux-kernel-mentees] KASAN: slab-out-of-bounds Read in squashfs_get_id

[Fox Chen]

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

Re: [Linux-kernel-mentees] KASAN: slab-out-of-bounds Read in squashfs_get_id

[Dmitry Vyukov via Linux-kernel-mentees]

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

Re: [Linux-kernel-mentees] KASAN: slab-out-of-bounds Read in squashfs_get_id

[Greg KH]

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

Re: [Linux-kernel-mentees] KASAN: slab-out-of-bounds Read in squashfs_get_id

[Fox Chen]

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

Re: [syzbot] KASAN: slab-out-of-bounds Read in squashfs_get_id

[syzbot]

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

Re: [syzbot] KASAN: slab-out-of-bounds Read in squashfs_get_id

[Dmitry Vyukov]

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