* Re: [syzbot] KASAN: use-after-free Write in udf_close_lvid [not found] <00000000000056e02f05dfb6e11a@google.com> @ 2022-05-24 10:32 ` Jan Kara 2022-05-24 10:46 ` Pali Rohár 2024-02-18 18:20 ` [syzbot] [udf?] " syzbot 1 sibling, 1 reply; 6+ messages in thread From: Jan Kara @ 2022-05-24 10:32 UTC (permalink / raw) To: syzbot Cc: akpm, alden.tondettar, hch, jack, jack, linux-kernel, pali, syzkaller-bugs, linux-fsdevel Hello! I had a look into this bug and I actually think this reproducer program does something that is always going to be problematic. The reproducer has: #{"threaded":true,"repeat":true,"procs":6,"slowdown":1,"sandbox":"","close_fds":false} syz_mount_image$udf(...) r0 = syz_open_dev$loop(&(0x7f0000000080), 0x0, 0x109002) mmap(addr, 0x600000, PROT_WRITE, MAP_SHARED | MAP_FIXED, r0, 0x0) pipe(addr) So the reproducer effectively corrupts random loop devices with output from pipe(2) syscall while there are filesystems mounted on them by other threads. This is a guaranteed way to shoot yourself in the foot and crash the kernel. You can say the kernel should not allow writing to mounted devices and I'd generally agree but there are some cornercases (e.g. bootloaders or lowlevel filesystem tools) which happen to do this so we cannot forbid that due to compatibility reasons. So syzbot probably needs to implement some internal logic not to futz with loop devices that are currently mounted. Honza On Mon 23-05-22 17:17:21, syzbot wrote: > Hello, > > syzbot found the following issue on: > > HEAD commit: 4b0986a3613c Linux 5.18 > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=125ba355f00000 > kernel config: https://syzkaller.appspot.com/x/.config?x=1350d397b63b3036 > dashboard link: https://syzkaller.appspot.com/bug?extid=60864ed35b1073540d57 > compiler: Debian clang version 13.0.1-++20220126092033+75e33f71c2da-1~exp1~20220126212112.63, GNU ld (GNU Binutils for Debian) 2.35.2 > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1732a04df00000 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15189639f00000 > > The issue was bisected to: > > commit 781d2a9a2fc7d0be53a072794dc03ef6de770f3d > Author: Jan Kara <jack@suse.cz> > Date: Mon May 3 09:39:03 2021 +0000 > > udf: Check LVID earlier > > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=14deecd3f00000 > final oops: https://syzkaller.appspot.com/x/report.txt?x=16deecd3f00000 > console output: https://syzkaller.appspot.com/x/log.txt?x=12deecd3f00000 > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+60864ed35b1073540d57@syzkaller.appspotmail.com > Fixes: 781d2a9a2fc7 ("udf: Check LVID earlier") > > UDF-fs: error (device loop0): udf_fill_super: Error in udf_iget, block=96, partition=0 > ================================================================== > BUG: KASAN: use-after-free in udf_close_lvid+0x68a/0x980 fs/udf/super.c:2072 > Write of size 1 at addr ffff8880839e0190 by task syz-executor234/3615 > > CPU: 1 PID: 3615 Comm: syz-executor234 Not tainted 5.18.0-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 > Call Trace: > <TASK> > __dump_stack lib/dump_stack.c:88 [inline] > dump_stack_lvl+0x1e3/0x2cb lib/dump_stack.c:106 > print_address_description+0x65/0x4b0 mm/kasan/report.c:313 > print_report+0xf4/0x210 mm/kasan/report.c:429 > kasan_report+0xfb/0x130 mm/kasan/report.c:491 > udf_close_lvid+0x68a/0x980 fs/udf/super.c:2072 > udf_fill_super+0xde8/0x1b20 fs/udf/super.c:2309 > mount_bdev+0x26c/0x3a0 fs/super.c:1367 > legacy_get_tree+0xea/0x180 fs/fs_context.c:610 > vfs_get_tree+0x88/0x270 fs/super.c:1497 > do_new_mount+0x289/0xad0 fs/namespace.c:3040 > do_mount fs/namespace.c:3383 [inline] > __do_sys_mount fs/namespace.c:3591 [inline] > __se_sys_mount+0x2e3/0x3d0 fs/namespace.c:3568 > do_syscall_x64 arch/x86/entry/common.c:50 [inline] > do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 > entry_SYSCALL_64_after_hwframe+0x44/0xae > RIP: 0033:0x7fd64e59b08a > Code: 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff eb d2 e8 a8 00 00 00 0f 1f 84 00 00 00 00 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 > RSP: 002b:00007fd64e546168 EFLAGS: 00000286 ORIG_RAX: 00000000000000a5 > RAX: ffffffffffffffda RBX: 00007fd64e5461c0 RCX: 00007fd64e59b08a > RDX: 0000000020000000 RSI: 0000000020000700 RDI: 00007fd64e546180 > RBP: 000000000000000e R08: 00007fd64e5461c0 R09: 00007fd64e5466b8 > R10: 0000000000000810 R11: 0000000000000286 R12: 00007fd64e546180 > R13: 0000000020000350 R14: 0000000000000003 R15: 0000000000000004 > </TASK> > > The buggy address belongs to the physical page: > page:ffffea00020e7800 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x839e0 > flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff) > raw: 00fff00000000000 ffffea00020e7808 ffffea00020e7808 0000000000000000 > raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 > page dumped because: kasan: bad access detected > page_owner info is not present (never set?) > > Memory state around the buggy address: > ffff8880839e0080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > ffff8880839e0100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > >ffff8880839e0180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > ^ > ffff8880839e0200: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > ffff8880839e0280: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > ================================================================== > > > --- > 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. > For information about bisection process see: https://goo.gl/tpsmEJ#bisection > syzbot can test patches for this issue, for details see: > https://goo.gl/tpsmEJ#testing-patches -- Jan Kara <jack@suse.com> SUSE Labs, CR ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [syzbot] KASAN: use-after-free Write in udf_close_lvid 2022-05-24 10:32 ` [syzbot] KASAN: use-after-free Write in udf_close_lvid Jan Kara @ 2022-05-24 10:46 ` Pali Rohár 2022-05-24 11:37 ` Jan Kara 0 siblings, 1 reply; 6+ messages in thread From: Pali Rohár @ 2022-05-24 10:46 UTC (permalink / raw) To: Jan Kara Cc: syzbot, akpm, alden.tondettar, hch, jack, linux-kernel, syzkaller-bugs, linux-fsdevel On Tuesday 24 May 2022 12:32:46 Jan Kara wrote: > > Hello! > > I had a look into this bug and I actually think this reproducer program does > something that is always going to be problematic. The reproducer has: > > #{"threaded":true,"repeat":true,"procs":6,"slowdown":1,"sandbox":"","close_fds":false} > > syz_mount_image$udf(...) > r0 = syz_open_dev$loop(&(0x7f0000000080), 0x0, 0x109002) > mmap(addr, 0x600000, PROT_WRITE, MAP_SHARED | MAP_FIXED, r0, 0x0) > pipe(addr) > > So the reproducer effectively corrupts random loop devices with output from > pipe(2) syscall while there are filesystems mounted on them by other > threads. This is a guaranteed way to shoot yourself in the foot and crash > the kernel. You can say the kernel should not allow writing to mounted devices > and I'd generally agree but there are some cornercases (e.g. bootloaders or > lowlevel filesystem tools) which happen to do this so we cannot forbid that due > to compatibility reasons. So syzbot probably needs to implement some > internal logic not to futz with loop devices that are currently mounted. > > Honza Hello! Bootloaders and other similar software in most cases needs to update first sector or sectors with bootloader data or main superblock of filesystem (where are metadata like label or UUIDs)... In most cases these "write" operations do not touch filesystem data. So I'm thinking if it would not make sense to add some kernel config option to disallow write operations on mounted block devices, with some filesystem hook/callback which can allow writing to specific block. E.g. UDF filesystem does not use first 32kB of disk and userspace software can overwrite it as it wants even when fs is mounted, without crashing kernel. So that udf hook/callback would allow write access to this area. Userspace applications always invent "smart" things and I think it is a good idea to protect kernel if it is possible. I understand that there is need to overwrite mounted block device. Updating bootloader stored at the beginning of the rootfs disk is important operation. Also changing filesystem label at runtime / mounted fs is something which users want and it is legitimate requirement. For UDF this change is not easy operation and userspace software (e.g. udflabel) needs to update lot of blocks on device, which can really break mounted udf fs. > > On Mon 23-05-22 17:17:21, syzbot wrote: > > Hello, > > > > syzbot found the following issue on: > > > > HEAD commit: 4b0986a3613c Linux 5.18 > > git tree: upstream > > console output: https://syzkaller.appspot.com/x/log.txt?x=125ba355f00000 > > kernel config: https://syzkaller.appspot.com/x/.config?x=1350d397b63b3036 > > dashboard link: https://syzkaller.appspot.com/bug?extid=60864ed35b1073540d57 > > compiler: Debian clang version 13.0.1-++20220126092033+75e33f71c2da-1~exp1~20220126212112.63, GNU ld (GNU Binutils for Debian) 2.35.2 > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1732a04df00000 > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15189639f00000 > > > > The issue was bisected to: > > > > commit 781d2a9a2fc7d0be53a072794dc03ef6de770f3d > > Author: Jan Kara <jack@suse.cz> > > Date: Mon May 3 09:39:03 2021 +0000 > > > > udf: Check LVID earlier > > > > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=14deecd3f00000 > > final oops: https://syzkaller.appspot.com/x/report.txt?x=16deecd3f00000 > > console output: https://syzkaller.appspot.com/x/log.txt?x=12deecd3f00000 > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > > Reported-by: syzbot+60864ed35b1073540d57@syzkaller.appspotmail.com > > Fixes: 781d2a9a2fc7 ("udf: Check LVID earlier") > > > > UDF-fs: error (device loop0): udf_fill_super: Error in udf_iget, block=96, partition=0 > > ================================================================== > > BUG: KASAN: use-after-free in udf_close_lvid+0x68a/0x980 fs/udf/super.c:2072 > > Write of size 1 at addr ffff8880839e0190 by task syz-executor234/3615 > > > > CPU: 1 PID: 3615 Comm: syz-executor234 Not tainted 5.18.0-syzkaller #0 > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 > > Call Trace: > > <TASK> > > __dump_stack lib/dump_stack.c:88 [inline] > > dump_stack_lvl+0x1e3/0x2cb lib/dump_stack.c:106 > > print_address_description+0x65/0x4b0 mm/kasan/report.c:313 > > print_report+0xf4/0x210 mm/kasan/report.c:429 > > kasan_report+0xfb/0x130 mm/kasan/report.c:491 > > udf_close_lvid+0x68a/0x980 fs/udf/super.c:2072 > > udf_fill_super+0xde8/0x1b20 fs/udf/super.c:2309 > > mount_bdev+0x26c/0x3a0 fs/super.c:1367 > > legacy_get_tree+0xea/0x180 fs/fs_context.c:610 > > vfs_get_tree+0x88/0x270 fs/super.c:1497 > > do_new_mount+0x289/0xad0 fs/namespace.c:3040 > > do_mount fs/namespace.c:3383 [inline] > > __do_sys_mount fs/namespace.c:3591 [inline] > > __se_sys_mount+0x2e3/0x3d0 fs/namespace.c:3568 > > do_syscall_x64 arch/x86/entry/common.c:50 [inline] > > do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 > > entry_SYSCALL_64_after_hwframe+0x44/0xae > > RIP: 0033:0x7fd64e59b08a > > Code: 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff eb d2 e8 a8 00 00 00 0f 1f 84 00 00 00 00 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 > > RSP: 002b:00007fd64e546168 EFLAGS: 00000286 ORIG_RAX: 00000000000000a5 > > RAX: ffffffffffffffda RBX: 00007fd64e5461c0 RCX: 00007fd64e59b08a > > RDX: 0000000020000000 RSI: 0000000020000700 RDI: 00007fd64e546180 > > RBP: 000000000000000e R08: 00007fd64e5461c0 R09: 00007fd64e5466b8 > > R10: 0000000000000810 R11: 0000000000000286 R12: 00007fd64e546180 > > R13: 0000000020000350 R14: 0000000000000003 R15: 0000000000000004 > > </TASK> > > > > The buggy address belongs to the physical page: > > page:ffffea00020e7800 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x839e0 > > flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff) > > raw: 00fff00000000000 ffffea00020e7808 ffffea00020e7808 0000000000000000 > > raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 > > page dumped because: kasan: bad access detected > > page_owner info is not present (never set?) > > > > Memory state around the buggy address: > > ffff8880839e0080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > > ffff8880839e0100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > > >ffff8880839e0180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > > ^ > > ffff8880839e0200: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > > ffff8880839e0280: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > > ================================================================== > > > > > > --- > > 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. > > For information about bisection process see: https://goo.gl/tpsmEJ#bisection > > syzbot can test patches for this issue, for details see: > > https://goo.gl/tpsmEJ#testing-patches > -- > Jan Kara <jack@suse.com> > SUSE Labs, CR ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [syzbot] KASAN: use-after-free Write in udf_close_lvid 2022-05-24 10:46 ` Pali Rohár @ 2022-05-24 11:37 ` Jan Kara 2022-05-24 14:43 ` Dmitry Vyukov 0 siblings, 1 reply; 6+ messages in thread From: Jan Kara @ 2022-05-24 11:37 UTC (permalink / raw) To: Pali Rohár Cc: Jan Kara, syzbot, akpm, alden.tondettar, hch, jack, linux-kernel, syzkaller-bugs, linux-fsdevel On Tue 24-05-22 12:46:58, Pali Rohár wrote: > On Tuesday 24 May 2022 12:32:46 Jan Kara wrote: > > > > Hello! > > > > I had a look into this bug and I actually think this reproducer program does > > something that is always going to be problematic. The reproducer has: > > > > #{"threaded":true,"repeat":true,"procs":6,"slowdown":1,"sandbox":"","close_fds":false} > > > > syz_mount_image$udf(...) > > r0 = syz_open_dev$loop(&(0x7f0000000080), 0x0, 0x109002) > > mmap(addr, 0x600000, PROT_WRITE, MAP_SHARED | MAP_FIXED, r0, 0x0) > > pipe(addr) > > > > So the reproducer effectively corrupts random loop devices with output from > > pipe(2) syscall while there are filesystems mounted on them by other > > threads. This is a guaranteed way to shoot yourself in the foot and crash > > the kernel. You can say the kernel should not allow writing to mounted devices > > and I'd generally agree but there are some cornercases (e.g. bootloaders or > > lowlevel filesystem tools) which happen to do this so we cannot forbid that due > > to compatibility reasons. So syzbot probably needs to implement some > > internal logic not to futz with loop devices that are currently mounted. > > > > Honza > > Hello! Bootloaders and other similar software in most cases needs to > update first sector or sectors with bootloader data or main superblock > of filesystem (where are metadata like label or UUIDs)... In most cases > these "write" operations do not touch filesystem data. Well, we generally try to move away from updating superblock directly by userspace - e.g. these days we have ioctls to update label or uuid so that coordination with the kernel is done properly. But there are still cases where this happens. > So I'm thinking if it would not make sense to add some kernel config > option to disallow write operations on mounted block devices, with some > filesystem hook/callback which can allow writing to specific block. > > E.g. UDF filesystem does not use first 32kB of disk and userspace > software can overwrite it as it wants even when fs is mounted, without > crashing kernel. So that udf hook/callback would allow write access to > this area. > > Userspace applications always invent "smart" things and I think it is a > good idea to protect kernel if it is possible. > > I understand that there is need to overwrite mounted block device. > Updating bootloader stored at the beginning of the rootfs disk is > important operation. Also changing filesystem label at runtime / mounted > fs is something which users want and it is legitimate requirement. For > UDF this change is not easy operation and userspace software (e.g. > udflabel) needs to update lot of blocks on device, which can really > break mounted udf fs. Well, the difficulty is with identifying where writing is OK and where not. It is not always is simple range at the beginning of the device where writes can happen (although that probably covers majority of cases). But thinking more about it the problem is not so much with applications modifying disk contents (we don't trust disk contents much) but with applications modifying buffer cache where we believe we have validated data structures. So we could somehow disallow buffer cache modification under mounted filesystem. Either the filesystem and app view of buffer cache would be inconsistent or apps would be doing direct IO when the filesystem is mounted. Either option has its consequences but maybe we could create something working out of that. Honza > > On Mon 23-05-22 17:17:21, syzbot wrote: > > > Hello, > > > > > > syzbot found the following issue on: > > > > > > HEAD commit: 4b0986a3613c Linux 5.18 > > > git tree: upstream > > > console output: https://syzkaller.appspot.com/x/log.txt?x=125ba355f00000 > > > kernel config: https://syzkaller.appspot.com/x/.config?x=1350d397b63b3036 > > > dashboard link: https://syzkaller.appspot.com/bug?extid=60864ed35b1073540d57 > > > compiler: Debian clang version 13.0.1-++20220126092033+75e33f71c2da-1~exp1~20220126212112.63, GNU ld (GNU Binutils for Debian) 2.35.2 > > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1732a04df00000 > > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15189639f00000 > > > > > > The issue was bisected to: > > > > > > commit 781d2a9a2fc7d0be53a072794dc03ef6de770f3d > > > Author: Jan Kara <jack@suse.cz> > > > Date: Mon May 3 09:39:03 2021 +0000 > > > > > > udf: Check LVID earlier > > > > > > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=14deecd3f00000 > > > final oops: https://syzkaller.appspot.com/x/report.txt?x=16deecd3f00000 > > > console output: https://syzkaller.appspot.com/x/log.txt?x=12deecd3f00000 > > > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > > > Reported-by: syzbot+60864ed35b1073540d57@syzkaller.appspotmail.com > > > Fixes: 781d2a9a2fc7 ("udf: Check LVID earlier") > > > > > > UDF-fs: error (device loop0): udf_fill_super: Error in udf_iget, block=96, partition=0 > > > ================================================================== > > > BUG: KASAN: use-after-free in udf_close_lvid+0x68a/0x980 fs/udf/super.c:2072 > > > Write of size 1 at addr ffff8880839e0190 by task syz-executor234/3615 > > > > > > CPU: 1 PID: 3615 Comm: syz-executor234 Not tainted 5.18.0-syzkaller #0 > > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 > > > Call Trace: > > > <TASK> > > > __dump_stack lib/dump_stack.c:88 [inline] > > > dump_stack_lvl+0x1e3/0x2cb lib/dump_stack.c:106 > > > print_address_description+0x65/0x4b0 mm/kasan/report.c:313 > > > print_report+0xf4/0x210 mm/kasan/report.c:429 > > > kasan_report+0xfb/0x130 mm/kasan/report.c:491 > > > udf_close_lvid+0x68a/0x980 fs/udf/super.c:2072 > > > udf_fill_super+0xde8/0x1b20 fs/udf/super.c:2309 > > > mount_bdev+0x26c/0x3a0 fs/super.c:1367 > > > legacy_get_tree+0xea/0x180 fs/fs_context.c:610 > > > vfs_get_tree+0x88/0x270 fs/super.c:1497 > > > do_new_mount+0x289/0xad0 fs/namespace.c:3040 > > > do_mount fs/namespace.c:3383 [inline] > > > __do_sys_mount fs/namespace.c:3591 [inline] > > > __se_sys_mount+0x2e3/0x3d0 fs/namespace.c:3568 > > > do_syscall_x64 arch/x86/entry/common.c:50 [inline] > > > do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 > > > entry_SYSCALL_64_after_hwframe+0x44/0xae > > > RIP: 0033:0x7fd64e59b08a > > > Code: 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff eb d2 e8 a8 00 00 00 0f 1f 84 00 00 00 00 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 > > > RSP: 002b:00007fd64e546168 EFLAGS: 00000286 ORIG_RAX: 00000000000000a5 > > > RAX: ffffffffffffffda RBX: 00007fd64e5461c0 RCX: 00007fd64e59b08a > > > RDX: 0000000020000000 RSI: 0000000020000700 RDI: 00007fd64e546180 > > > RBP: 000000000000000e R08: 00007fd64e5461c0 R09: 00007fd64e5466b8 > > > R10: 0000000000000810 R11: 0000000000000286 R12: 00007fd64e546180 > > > R13: 0000000020000350 R14: 0000000000000003 R15: 0000000000000004 > > > </TASK> > > > > > > The buggy address belongs to the physical page: > > > page:ffffea00020e7800 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x839e0 > > > flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff) > > > raw: 00fff00000000000 ffffea00020e7808 ffffea00020e7808 0000000000000000 > > > raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 > > > page dumped because: kasan: bad access detected > > > page_owner info is not present (never set?) > > > > > > Memory state around the buggy address: > > > ffff8880839e0080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > > > ffff8880839e0100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > > > >ffff8880839e0180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > > > ^ > > > ffff8880839e0200: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > > > ffff8880839e0280: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > > > ================================================================== > > > > > > > > > --- > > > 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. > > > For information about bisection process see: https://goo.gl/tpsmEJ#bisection > > > syzbot can test patches for this issue, for details see: > > > https://goo.gl/tpsmEJ#testing-patches > > -- > > Jan Kara <jack@suse.com> > > SUSE Labs, CR -- Jan Kara <jack@suse.com> SUSE Labs, CR ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [syzbot] KASAN: use-after-free Write in udf_close_lvid 2022-05-24 11:37 ` Jan Kara @ 2022-05-24 14:43 ` Dmitry Vyukov 0 siblings, 0 replies; 6+ messages in thread From: Dmitry Vyukov @ 2022-05-24 14:43 UTC (permalink / raw) To: Jan Kara Cc: Pali Rohár, syzbot, akpm, alden.tondettar, hch, jack, linux-kernel, syzkaller-bugs, linux-fsdevel On Tue, 24 May 2022 at 13:37, Jan Kara <jack@suse.cz> wrote: > > On Tue 24-05-22 12:46:58, Pali Rohár wrote: > > On Tuesday 24 May 2022 12:32:46 Jan Kara wrote: > > > > > > Hello! > > > > > > I had a look into this bug and I actually think this reproducer program does > > > something that is always going to be problematic. The reproducer has: > > > > > > #{"threaded":true,"repeat":true,"procs":6,"slowdown":1,"sandbox":"","close_fds":false} > > > > > > syz_mount_image$udf(...) > > > r0 = syz_open_dev$loop(&(0x7f0000000080), 0x0, 0x109002) > > > mmap(addr, 0x600000, PROT_WRITE, MAP_SHARED | MAP_FIXED, r0, 0x0) > > > pipe(addr) > > > > > > So the reproducer effectively corrupts random loop devices with output from > > > pipe(2) syscall while there are filesystems mounted on them by other > > > threads. This is a guaranteed way to shoot yourself in the foot and crash > > > the kernel. You can say the kernel should not allow writing to mounted devices > > > and I'd generally agree but there are some cornercases (e.g. bootloaders or > > > lowlevel filesystem tools) which happen to do this so we cannot forbid that due > > > to compatibility reasons. So syzbot probably needs to implement some > > > internal logic not to futz with loop devices that are currently mounted. > > > > > > Honza > > > > Hello! Bootloaders and other similar software in most cases needs to > > update first sector or sectors with bootloader data or main superblock > > of filesystem (where are metadata like label or UUIDs)... In most cases > > these "write" operations do not touch filesystem data. > > Well, we generally try to move away from updating superblock directly by > userspace - e.g. these days we have ioctls to update label or uuid so that > coordination with the kernel is done properly. But there are still cases > where this happens. > > > So I'm thinking if it would not make sense to add some kernel config > > option to disallow write operations on mounted block devices, with some > > filesystem hook/callback which can allow writing to specific block. > > > > E.g. UDF filesystem does not use first 32kB of disk and userspace > > software can overwrite it as it wants even when fs is mounted, without > > crashing kernel. So that udf hook/callback would allow write access to > > this area. > > > > Userspace applications always invent "smart" things and I think it is a > > good idea to protect kernel if it is possible. > > > > I understand that there is need to overwrite mounted block device. > > Updating bootloader stored at the beginning of the rootfs disk is > > important operation. Also changing filesystem label at runtime / mounted > > fs is something which users want and it is legitimate requirement. For > > UDF this change is not easy operation and userspace software (e.g. > > udflabel) needs to update lot of blocks on device, which can really > > break mounted udf fs. > > Well, the difficulty is with identifying where writing is OK and where not. > It is not always is simple range at the beginning of the device where > writes can happen (although that probably covers majority of cases). But > thinking more about it the problem is not so much with applications > modifying disk contents (we don't trust disk contents much) but with > applications modifying buffer cache where we believe we have validated data > structures. So we could somehow disallow buffer cache modification under > mounted filesystem. Either the filesystem and app view of buffer cache > would be inconsistent or apps would be doing direct IO when the filesystem > is mounted. Either option has its consequences but maybe we could create > something working out of that. Did not know it's not OK to write loop-associated fd. It's quite hard to prohibit the fuzzer from doing this. It's possible to prohibit whole syscalls, or opening particular files, or executing particular ioctl commands. But there are lots of interesting ways how an fd can be shared/messed with. We could prohibit opening /dev/loop*, or associating loop with fd, but it will inhibit all useful loop testing. And will also prohibit testing mounting of all filesystems. It will be good if the kernel provides some config that prohibits such unsafe operation. Or, of course, if it prohibits only "buffer cache modification". > > > On Mon 23-05-22 17:17:21, syzbot wrote: > > > > Hello, > > > > > > > > syzbot found the following issue on: > > > > > > > > HEAD commit: 4b0986a3613c Linux 5.18 > > > > git tree: upstream > > > > console output: https://syzkaller.appspot.com/x/log.txt?x=125ba355f00000 > > > > kernel config: https://syzkaller.appspot.com/x/.config?x=1350d397b63b3036 > > > > dashboard link: https://syzkaller.appspot.com/bug?extid=60864ed35b1073540d57 > > > > compiler: Debian clang version 13.0.1-++20220126092033+75e33f71c2da-1~exp1~20220126212112.63, GNU ld (GNU Binutils for Debian) 2.35.2 > > > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1732a04df00000 > > > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15189639f00000 > > > > > > > > The issue was bisected to: > > > > > > > > commit 781d2a9a2fc7d0be53a072794dc03ef6de770f3d > > > > Author: Jan Kara <jack@suse.cz> > > > > Date: Mon May 3 09:39:03 2021 +0000 > > > > > > > > udf: Check LVID earlier > > > > > > > > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=14deecd3f00000 > > > > final oops: https://syzkaller.appspot.com/x/report.txt?x=16deecd3f00000 > > > > console output: https://syzkaller.appspot.com/x/log.txt?x=12deecd3f00000 > > > > > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > > > > Reported-by: syzbot+60864ed35b1073540d57@syzkaller.appspotmail.com > > > > Fixes: 781d2a9a2fc7 ("udf: Check LVID earlier") > > > > > > > > UDF-fs: error (device loop0): udf_fill_super: Error in udf_iget, block=96, partition=0 > > > > ================================================================== > > > > BUG: KASAN: use-after-free in udf_close_lvid+0x68a/0x980 fs/udf/super.c:2072 > > > > Write of size 1 at addr ffff8880839e0190 by task syz-executor234/3615 > > > > > > > > CPU: 1 PID: 3615 Comm: syz-executor234 Not tainted 5.18.0-syzkaller #0 > > > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 > > > > Call Trace: > > > > <TASK> > > > > __dump_stack lib/dump_stack.c:88 [inline] > > > > dump_stack_lvl+0x1e3/0x2cb lib/dump_stack.c:106 > > > > print_address_description+0x65/0x4b0 mm/kasan/report.c:313 > > > > print_report+0xf4/0x210 mm/kasan/report.c:429 > > > > kasan_report+0xfb/0x130 mm/kasan/report.c:491 > > > > udf_close_lvid+0x68a/0x980 fs/udf/super.c:2072 > > > > udf_fill_super+0xde8/0x1b20 fs/udf/super.c:2309 > > > > mount_bdev+0x26c/0x3a0 fs/super.c:1367 > > > > legacy_get_tree+0xea/0x180 fs/fs_context.c:610 > > > > vfs_get_tree+0x88/0x270 fs/super.c:1497 > > > > do_new_mount+0x289/0xad0 fs/namespace.c:3040 > > > > do_mount fs/namespace.c:3383 [inline] > > > > __do_sys_mount fs/namespace.c:3591 [inline] > > > > __se_sys_mount+0x2e3/0x3d0 fs/namespace.c:3568 > > > > do_syscall_x64 arch/x86/entry/common.c:50 [inline] > > > > do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 > > > > entry_SYSCALL_64_after_hwframe+0x44/0xae > > > > RIP: 0033:0x7fd64e59b08a > > > > Code: 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff eb d2 e8 a8 00 00 00 0f 1f 84 00 00 00 00 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 > > > > RSP: 002b:00007fd64e546168 EFLAGS: 00000286 ORIG_RAX: 00000000000000a5 > > > > RAX: ffffffffffffffda RBX: 00007fd64e5461c0 RCX: 00007fd64e59b08a > > > > RDX: 0000000020000000 RSI: 0000000020000700 RDI: 00007fd64e546180 > > > > RBP: 000000000000000e R08: 00007fd64e5461c0 R09: 00007fd64e5466b8 > > > > R10: 0000000000000810 R11: 0000000000000286 R12: 00007fd64e546180 > > > > R13: 0000000020000350 R14: 0000000000000003 R15: 0000000000000004 > > > > </TASK> > > > > > > > > The buggy address belongs to the physical page: > > > > page:ffffea00020e7800 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x839e0 > > > > flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff) > > > > raw: 00fff00000000000 ffffea00020e7808 ffffea00020e7808 0000000000000000 > > > > raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 > > > > page dumped because: kasan: bad access detected > > > > page_owner info is not present (never set?) > > > > > > > > Memory state around the buggy address: > > > > ffff8880839e0080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > > > > ffff8880839e0100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > > > > >ffff8880839e0180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > > > > ^ > > > > ffff8880839e0200: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > > > > ffff8880839e0280: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff > > > > ================================================================== > > > > > > > > > > > > --- > > > > 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. > > > > For information about bisection process see: https://goo.gl/tpsmEJ#bisection > > > > syzbot can test patches for this issue, for details see: > > > > https://goo.gl/tpsmEJ#testing-patches > > > -- > > > Jan Kara <jack@suse.com> > > > SUSE Labs, CR > -- > Jan Kara <jack@suse.com> > SUSE Labs, CR > > -- > 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/20220524113704.gdwvao43b23hyf7z%40quack3.lan. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [syzbot] [udf?] KASAN: use-after-free Write in udf_close_lvid [not found] <00000000000056e02f05dfb6e11a@google.com> 2022-05-24 10:32 ` [syzbot] KASAN: use-after-free Write in udf_close_lvid Jan Kara @ 2024-02-18 18:20 ` syzbot 2024-02-19 11:51 ` Jan Kara 1 sibling, 1 reply; 6+ messages in thread From: syzbot @ 2024-02-18 18:20 UTC (permalink / raw) To: akpm, alden.tondettar, axboe, brauner, dvyukov, hch, hdanton, jack, jack, linux-fsdevel, linux-kernel, pali, syzkaller-bugs syzbot suspects this issue was fixed by commit: commit 6f861765464f43a71462d52026fbddfc858239a5 Author: Jan Kara <jack@suse.cz> Date: Wed Nov 1 17:43:10 2023 +0000 fs: Block writes to mounted block devices bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=12c941c2180000 start commit: f016f7547aee Merge tag 'gpio-fixes-for-v6.7-rc8' of git://.. git tree: upstream kernel config: https://syzkaller.appspot.com/x/.config?x=f8e72bae38c079e4 dashboard link: https://syzkaller.appspot.com/bug?extid=60864ed35b1073540d57 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13c2caf9e80000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=11f518f9e80000 If the result looks correct, please mark the issue as fixed by replying with: #syz fix: fs: Block writes to mounted block devices For information about bisection process see: https://goo.gl/tpsmEJ#bisection ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [syzbot] [udf?] KASAN: use-after-free Write in udf_close_lvid 2024-02-18 18:20 ` [syzbot] [udf?] " syzbot @ 2024-02-19 11:51 ` Jan Kara 0 siblings, 0 replies; 6+ messages in thread From: Jan Kara @ 2024-02-19 11:51 UTC (permalink / raw) To: syzbot Cc: akpm, alden.tondettar, axboe, brauner, dvyukov, hch, hdanton, jack, jack, linux-fsdevel, linux-kernel, pali, syzkaller-bugs On Sun 18-02-24 10:20:04, syzbot wrote: > syzbot suspects this issue was fixed by commit: > > commit 6f861765464f43a71462d52026fbddfc858239a5 > Author: Jan Kara <jack@suse.cz> > Date: Wed Nov 1 17:43:10 2023 +0000 > > fs: Block writes to mounted block devices > > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=12c941c2180000 > start commit: f016f7547aee Merge tag 'gpio-fixes-for-v6.7-rc8' of git://.. > git tree: upstream > kernel config: https://syzkaller.appspot.com/x/.config?x=f8e72bae38c079e4 > dashboard link: https://syzkaller.appspot.com/bug?extid=60864ed35b1073540d57 > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13c2caf9e80000 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=11f518f9e80000 > > If the result looks correct, please mark the issue as fixed by replying with: Yes, this was expected :) #syz fix: fs: Block writes to mounted block devices Honza -- Jan Kara <jack@suse.com> SUSE Labs, CR ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2024-02-19 11:51 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <00000000000056e02f05dfb6e11a@google.com>
2022-05-24 10:32 ` [syzbot] KASAN: use-after-free Write in udf_close_lvid Jan Kara
2022-05-24 10:46 ` Pali Rohár
2022-05-24 11:37 ` Jan Kara
2022-05-24 14:43 ` Dmitry Vyukov
2024-02-18 18:20 ` [syzbot] [udf?] " syzbot
2024-02-19 11:51 ` Jan Kara
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).