* [syzbot] BUG: unable to handle kernel NULL pointer dereference in folio_mark_dirty @ 2021-12-04 9:55 syzbot 2021-12-07 1:56 ` [f2fs-dev] " Andrew Morton 0 siblings, 1 reply; 15+ messages in thread From: syzbot @ 2021-12-04 9:55 UTC (permalink / raw) To: akpm, linux-kernel, linux-mm, syzkaller-bugs Hello, syzbot found the following issue on: HEAD commit: 58e1100fdc59 MAINTAINERS: co-maintain random.c git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=1362881eb00000 kernel config: https://syzkaller.appspot.com/x/.config?x=e9ea28d2c3c2c389 dashboard link: https://syzkaller.appspot.com/bug?extid=7cd473c2cac13fd2dd72 compiler: Debian clang version 11.0.1-2, GNU ld (GNU Binutils for Debian) 2.35.2 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+7cd473c2cac13fd2dd72@syzkaller.appspotmail.com BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0010) - not-present page PGD 70764067 P4D 70764067 PUD 0 Oops: 0010 [#1] PREEMPT SMP KASAN CPU: 1 PID: 6541 Comm: syz-executor.3 Not tainted 5.16.0-rc3-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:0x0 Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. RSP: 0018:ffffc900027ff7f8 EFLAGS: 00010246 RAX: 1ffffffff14fef03 RBX: ffffffff8a7f7818 RCX: ffff88801b40d700 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffea0002790ec0 RBP: dffffc0000000000 R08: ffffffff81b0fa16 R09: fffff940004f21d9 R10: fffff940004f21d9 R11: 0000000000000000 R12: ffff88806c11c7b0 R13: 0000000000000000 R14: 1ffffd40004f21d9 R15: ffffea0002790ec0 FS: 0000555557165400(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffffffffd6 CR3: 0000000030d85000 CR4: 00000000003526e0 Call Trace: <TASK> folio_mark_dirty+0x136/0x270 mm/page-writeback.c:2639 f2fs_update_meta_page+0x4b/0x380 fs/f2fs/segment.c:2485 do_checkpoint fs/f2fs/checkpoint.c:1513 [inline] f2fs_write_checkpoint+0x31ad/0x5430 fs/f2fs/checkpoint.c:1674 f2fs_issue_checkpoint+0x361/0x4e0 sync_filesystem+0x19c/0x1f0 fs/sync.c:63 generic_shutdown_super+0x6b/0x300 fs/super.c:448 kill_block_super+0x79/0xd0 fs/super.c:1397 kill_f2fs_super+0x2f9/0x3c0 fs/f2fs/super.c:4478 deactivate_locked_super+0xa7/0xf0 fs/super.c:335 cleanup_mnt+0x462/0x510 fs/namespace.c:1137 task_work_run+0x146/0x1c0 kernel/task_work.c:164 tracehook_notify_resume include/linux/tracehook.h:189 [inline] exit_to_user_mode_loop kernel/entry/common.c:175 [inline] exit_to_user_mode_prepare+0x209/0x220 kernel/entry/common.c:207 __syscall_exit_to_user_mode_work kernel/entry/common.c:289 [inline] syscall_exit_to_user_mode+0x2e/0x70 kernel/entry/common.c:300 do_syscall_64+0x53/0xd0 arch/x86/entry/common.c:86 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f6cfdd59f57 Code: ff ff ff f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 31 f6 e9 09 00 00 00 66 0f 1f 84 00 00 00 00 00 b8 a6 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fffcbddcad8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00007f6cfdd59f57 RDX: 00007fffcbddcbac RSI: 000000000000000a RDI: 00007fffcbddcba0 RBP: 00007fffcbddcba0 R08: 00000000ffffffff R09: 00007fffcbddc970 R10: 0000555557166903 R11: 0000000000000246 R12: 00007f6cfddb2105 R13: 00007fffcbdddc60 R14: 0000555557166810 R15: 00007fffcbdddca0 </TASK> Modules linked in: CR2: 0000000000000000 ---[ end trace 08eda5a5e35b48a0 ]--- RIP: 0010:0x0 Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. RSP: 0018:ffffc900027ff7f8 EFLAGS: 00010246 RAX: 1ffffffff14fef03 RBX: ffffffff8a7f7818 RCX: ffff88801b40d700 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffea0002790ec0 RBP: dffffc0000000000 R08: ffffffff81b0fa16 R09: fffff940004f21d9 R10: fffff940004f21d9 R11: 0000000000000000 R12: ffff88806c11c7b0 R13: 0000000000000000 R14: 1ffffd40004f21d9 R15: ffffea0002790ec0 FS: 0000555557165400(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffffffffd6 CR3: 0000000030d85000 CR4: 00000000003526e0 --- 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [syzbot] BUG: unable to handle kernel NULL pointer dereference in folio_mark_dirty 2021-12-04 9:55 [syzbot] BUG: unable to handle kernel NULL pointer dereference in folio_mark_dirty syzbot @ 2021-12-07 1:56 ` Andrew Morton 0 siblings, 0 replies; 15+ messages in thread From: Andrew Morton @ 2021-12-07 1:56 UTC (permalink / raw) To: syzbot Cc: linux-kernel, linux-mm, syzkaller-bugs, linux-f2fs-devel, Matthew Wilcox On Sat, 04 Dec 2021 01:55:17 -0800 syzbot <syzbot+7cd473c2cac13fd2dd72@syzkaller.appspotmail.com> wrote: > Hello, > > syzbot found the following issue on: > > HEAD commit: 58e1100fdc59 MAINTAINERS: co-maintain random.c > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=1362881eb00000 > kernel config: https://syzkaller.appspot.com/x/.config?x=e9ea28d2c3c2c389 > dashboard link: https://syzkaller.appspot.com/bug?extid=7cd473c2cac13fd2dd72 > compiler: Debian clang version 11.0.1-2, GNU ld (GNU Binutils for Debian) 2.35.2 > > Unfortunately, I don't have any reproducer for this issue yet. > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+7cd473c2cac13fd2dd72@syzkaller.appspotmail.com > > BUG: kernel NULL pointer dereference, address: 0000000000000000 cc linux-f2fs-devel@lists.sourceforge.net And willy, who might help with diagnosing this. But it does seem that f2fs got itself a NULL page* then put it in places where it shouldn't have. > #PF: supervisor instruction fetch in kernel mode > #PF: error_code(0x0010) - not-present page > PGD 70764067 P4D 70764067 PUD 0 > Oops: 0010 [#1] PREEMPT SMP KASAN > CPU: 1 PID: 6541 Comm: syz-executor.3 Not tainted 5.16.0-rc3-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 > RIP: 0010:0x0 > Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. > RSP: 0018:ffffc900027ff7f8 EFLAGS: 00010246 > RAX: 1ffffffff14fef03 RBX: ffffffff8a7f7818 RCX: ffff88801b40d700 > RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffea0002790ec0 > RBP: dffffc0000000000 R08: ffffffff81b0fa16 R09: fffff940004f21d9 > R10: fffff940004f21d9 R11: 0000000000000000 R12: ffff88806c11c7b0 > R13: 0000000000000000 R14: 1ffffd40004f21d9 R15: ffffea0002790ec0 > FS: 0000555557165400(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: ffffffffffffffd6 CR3: 0000000030d85000 CR4: 00000000003526e0 > Call Trace: > <TASK> > folio_mark_dirty+0x136/0x270 mm/page-writeback.c:2639 > f2fs_update_meta_page+0x4b/0x380 fs/f2fs/segment.c:2485 > do_checkpoint fs/f2fs/checkpoint.c:1513 [inline] > f2fs_write_checkpoint+0x31ad/0x5430 fs/f2fs/checkpoint.c:1674 > f2fs_issue_checkpoint+0x361/0x4e0 > sync_filesystem+0x19c/0x1f0 fs/sync.c:63 > generic_shutdown_super+0x6b/0x300 fs/super.c:448 > kill_block_super+0x79/0xd0 fs/super.c:1397 > kill_f2fs_super+0x2f9/0x3c0 fs/f2fs/super.c:4478 > deactivate_locked_super+0xa7/0xf0 fs/super.c:335 > cleanup_mnt+0x462/0x510 fs/namespace.c:1137 > task_work_run+0x146/0x1c0 kernel/task_work.c:164 > tracehook_notify_resume include/linux/tracehook.h:189 [inline] > exit_to_user_mode_loop kernel/entry/common.c:175 [inline] > exit_to_user_mode_prepare+0x209/0x220 kernel/entry/common.c:207 > __syscall_exit_to_user_mode_work kernel/entry/common.c:289 [inline] > syscall_exit_to_user_mode+0x2e/0x70 kernel/entry/common.c:300 > do_syscall_64+0x53/0xd0 arch/x86/entry/common.c:86 > entry_SYSCALL_64_after_hwframe+0x44/0xae > RIP: 0033:0x7f6cfdd59f57 > Code: ff ff ff f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 31 f6 e9 09 00 00 00 66 0f 1f 84 00 00 00 00 00 b8 a6 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 > RSP: 002b:00007fffcbddcad8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6 > RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00007f6cfdd59f57 > RDX: 00007fffcbddcbac RSI: 000000000000000a RDI: 00007fffcbddcba0 > RBP: 00007fffcbddcba0 R08: 00000000ffffffff R09: 00007fffcbddc970 > R10: 0000555557166903 R11: 0000000000000246 R12: 00007f6cfddb2105 > R13: 00007fffcbdddc60 R14: 0000555557166810 R15: 00007fffcbdddca0 > </TASK> > Modules linked in: > CR2: 0000000000000000 > ---[ end trace 08eda5a5e35b48a0 ]--- > RIP: 0010:0x0 > Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. > RSP: 0018:ffffc900027ff7f8 EFLAGS: 00010246 > RAX: 1ffffffff14fef03 RBX: ffffffff8a7f7818 RCX: ffff88801b40d700 > RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffea0002790ec0 > RBP: dffffc0000000000 R08: ffffffff81b0fa16 R09: fffff940004f21d9 > R10: fffff940004f21d9 R11: 0000000000000000 R12: ffff88806c11c7b0 > R13: 0000000000000000 R14: 1ffffd40004f21d9 R15: ffffea0002790ec0 > FS: 0000555557165400(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: ffffffffffffffd6 CR3: 0000000030d85000 CR4: 00000000003526e0 > > > --- > 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [f2fs-dev] [syzbot] BUG: unable to handle kernel NULL pointer dereference in folio_mark_dirty @ 2021-12-07 1:56 ` Andrew Morton 0 siblings, 0 replies; 15+ messages in thread From: Andrew Morton @ 2021-12-07 1:56 UTC (permalink / raw) To: syzbot Cc: linux-mm, syzkaller-bugs, linux-kernel, Matthew Wilcox, linux-f2fs-devel On Sat, 04 Dec 2021 01:55:17 -0800 syzbot <syzbot+7cd473c2cac13fd2dd72@syzkaller.appspotmail.com> wrote: > Hello, > > syzbot found the following issue on: > > HEAD commit: 58e1100fdc59 MAINTAINERS: co-maintain random.c > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=1362881eb00000 > kernel config: https://syzkaller.appspot.com/x/.config?x=e9ea28d2c3c2c389 > dashboard link: https://syzkaller.appspot.com/bug?extid=7cd473c2cac13fd2dd72 > compiler: Debian clang version 11.0.1-2, GNU ld (GNU Binutils for Debian) 2.35.2 > > Unfortunately, I don't have any reproducer for this issue yet. > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+7cd473c2cac13fd2dd72@syzkaller.appspotmail.com > > BUG: kernel NULL pointer dereference, address: 0000000000000000 cc linux-f2fs-devel@lists.sourceforge.net And willy, who might help with diagnosing this. But it does seem that f2fs got itself a NULL page* then put it in places where it shouldn't have. > #PF: supervisor instruction fetch in kernel mode > #PF: error_code(0x0010) - not-present page > PGD 70764067 P4D 70764067 PUD 0 > Oops: 0010 [#1] PREEMPT SMP KASAN > CPU: 1 PID: 6541 Comm: syz-executor.3 Not tainted 5.16.0-rc3-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 > RIP: 0010:0x0 > Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. > RSP: 0018:ffffc900027ff7f8 EFLAGS: 00010246 > RAX: 1ffffffff14fef03 RBX: ffffffff8a7f7818 RCX: ffff88801b40d700 > RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffea0002790ec0 > RBP: dffffc0000000000 R08: ffffffff81b0fa16 R09: fffff940004f21d9 > R10: fffff940004f21d9 R11: 0000000000000000 R12: ffff88806c11c7b0 > R13: 0000000000000000 R14: 1ffffd40004f21d9 R15: ffffea0002790ec0 > FS: 0000555557165400(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: ffffffffffffffd6 CR3: 0000000030d85000 CR4: 00000000003526e0 > Call Trace: > <TASK> > folio_mark_dirty+0x136/0x270 mm/page-writeback.c:2639 > f2fs_update_meta_page+0x4b/0x380 fs/f2fs/segment.c:2485 > do_checkpoint fs/f2fs/checkpoint.c:1513 [inline] > f2fs_write_checkpoint+0x31ad/0x5430 fs/f2fs/checkpoint.c:1674 > f2fs_issue_checkpoint+0x361/0x4e0 > sync_filesystem+0x19c/0x1f0 fs/sync.c:63 > generic_shutdown_super+0x6b/0x300 fs/super.c:448 > kill_block_super+0x79/0xd0 fs/super.c:1397 > kill_f2fs_super+0x2f9/0x3c0 fs/f2fs/super.c:4478 > deactivate_locked_super+0xa7/0xf0 fs/super.c:335 > cleanup_mnt+0x462/0x510 fs/namespace.c:1137 > task_work_run+0x146/0x1c0 kernel/task_work.c:164 > tracehook_notify_resume include/linux/tracehook.h:189 [inline] > exit_to_user_mode_loop kernel/entry/common.c:175 [inline] > exit_to_user_mode_prepare+0x209/0x220 kernel/entry/common.c:207 > __syscall_exit_to_user_mode_work kernel/entry/common.c:289 [inline] > syscall_exit_to_user_mode+0x2e/0x70 kernel/entry/common.c:300 > do_syscall_64+0x53/0xd0 arch/x86/entry/common.c:86 > entry_SYSCALL_64_after_hwframe+0x44/0xae > RIP: 0033:0x7f6cfdd59f57 > Code: ff ff ff f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 31 f6 e9 09 00 00 00 66 0f 1f 84 00 00 00 00 00 b8 a6 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 > RSP: 002b:00007fffcbddcad8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6 > RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00007f6cfdd59f57 > RDX: 00007fffcbddcbac RSI: 000000000000000a RDI: 00007fffcbddcba0 > RBP: 00007fffcbddcba0 R08: 00000000ffffffff R09: 00007fffcbddc970 > R10: 0000555557166903 R11: 0000000000000246 R12: 00007f6cfddb2105 > R13: 00007fffcbdddc60 R14: 0000555557166810 R15: 00007fffcbdddca0 > </TASK> > Modules linked in: > CR2: 0000000000000000 > ---[ end trace 08eda5a5e35b48a0 ]--- > RIP: 0010:0x0 > Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. > RSP: 0018:ffffc900027ff7f8 EFLAGS: 00010246 > RAX: 1ffffffff14fef03 RBX: ffffffff8a7f7818 RCX: ffff88801b40d700 > RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffea0002790ec0 > RBP: dffffc0000000000 R08: ffffffff81b0fa16 R09: fffff940004f21d9 > R10: fffff940004f21d9 R11: 0000000000000000 R12: ffff88806c11c7b0 > R13: 0000000000000000 R14: 1ffffd40004f21d9 R15: ffffea0002790ec0 > FS: 0000555557165400(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: ffffffffffffffd6 CR3: 0000000030d85000 CR4: 00000000003526e0 > > > --- > 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. _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [syzbot] BUG: unable to handle kernel NULL pointer dereference in folio_mark_dirty 2021-12-07 1:56 ` [f2fs-dev] " Andrew Morton @ 2021-12-07 4:19 ` Matthew Wilcox -1 siblings, 0 replies; 15+ messages in thread From: Matthew Wilcox @ 2021-12-07 4:19 UTC (permalink / raw) To: Andrew Morton Cc: syzbot, linux-kernel, linux-mm, syzkaller-bugs, linux-f2fs-devel On Mon, Dec 06, 2021 at 05:56:31PM -0800, Andrew Morton wrote: > > BUG: kernel NULL pointer dereference, address: 0000000000000000 > > cc linux-f2fs-devel@lists.sourceforge.net > > And willy, who might help with diagnosing this. But it does seem that > f2fs got itself a NULL page* then put it in places where it shouldn't have. I'm surprised it got that far. void f2fs_update_meta_page(struct f2fs_sb_info *sbi, void *src, block_t blk_addr) { struct page *page = f2fs_grab_meta_page(sbi, blk_addr); memcpy(page_address(page), src, PAGE_SIZE); set_page_dirty(page); f2fs_put_page(page, 1); } How does page_address(NULL) not crash first? Or return an address that can be the target of a memcpy()? > > #PF: supervisor instruction fetch in kernel mode > > #PF: error_code(0x0010) - not-present page > > PGD 70764067 P4D 70764067 PUD 0 > > Oops: 0010 [#1] PREEMPT SMP KASAN > > CPU: 1 PID: 6541 Comm: syz-executor.3 Not tainted 5.16.0-rc3-syzkaller #0 > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 > > RIP: 0010:0x0 > > Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. > > RSP: 0018:ffffc900027ff7f8 EFLAGS: 00010246 > > RAX: 1ffffffff14fef03 RBX: ffffffff8a7f7818 RCX: ffff88801b40d700 > > RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffea0002790ec0 > > RBP: dffffc0000000000 R08: ffffffff81b0fa16 R09: fffff940004f21d9 > > R10: fffff940004f21d9 R11: 0000000000000000 R12: ffff88806c11c7b0 > > R13: 0000000000000000 R14: 1ffffd40004f21d9 R15: ffffea0002790ec0 > > FS: 0000555557165400(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 > > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > CR2: ffffffffffffffd6 CR3: 0000000030d85000 CR4: 00000000003526e0 > > Call Trace: > > <TASK> > > folio_mark_dirty+0x136/0x270 mm/page-writeback.c:2639 > > f2fs_update_meta_page+0x4b/0x380 fs/f2fs/segment.c:2485 > > do_checkpoint fs/f2fs/checkpoint.c:1513 [inline] > > f2fs_write_checkpoint+0x31ad/0x5430 fs/f2fs/checkpoint.c:1674 > > f2fs_issue_checkpoint+0x361/0x4e0 > > sync_filesystem+0x19c/0x1f0 fs/sync.c:63 > > generic_shutdown_super+0x6b/0x300 fs/super.c:448 > > kill_block_super+0x79/0xd0 fs/super.c:1397 > > kill_f2fs_super+0x2f9/0x3c0 fs/f2fs/super.c:4478 > > deactivate_locked_super+0xa7/0xf0 fs/super.c:335 > > cleanup_mnt+0x462/0x510 fs/namespace.c:1137 > > task_work_run+0x146/0x1c0 kernel/task_work.c:164 > > tracehook_notify_resume include/linux/tracehook.h:189 [inline] > > exit_to_user_mode_loop kernel/entry/common.c:175 [inline] > > exit_to_user_mode_prepare+0x209/0x220 kernel/entry/common.c:207 > > __syscall_exit_to_user_mode_work kernel/entry/common.c:289 [inline] > > syscall_exit_to_user_mode+0x2e/0x70 kernel/entry/common.c:300 > > do_syscall_64+0x53/0xd0 arch/x86/entry/common.c:86 > > entry_SYSCALL_64_after_hwframe+0x44/0xae > > RIP: 0033:0x7f6cfdd59f57 > > Code: ff ff ff f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 31 f6 e9 09 00 00 00 66 0f 1f 84 00 00 00 00 00 b8 a6 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 > > RSP: 002b:00007fffcbddcad8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6 > > RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00007f6cfdd59f57 > > RDX: 00007fffcbddcbac RSI: 000000000000000a RDI: 00007fffcbddcba0 > > RBP: 00007fffcbddcba0 R08: 00000000ffffffff R09: 00007fffcbddc970 > > R10: 0000555557166903 R11: 0000000000000246 R12: 00007f6cfddb2105 > > R13: 00007fffcbdddc60 R14: 0000555557166810 R15: 00007fffcbdddca0 > > </TASK> > > Modules linked in: > > CR2: 0000000000000000 > > ---[ end trace 08eda5a5e35b48a0 ]--- > > RIP: 0010:0x0 > > Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. > > RSP: 0018:ffffc900027ff7f8 EFLAGS: 00010246 > > RAX: 1ffffffff14fef03 RBX: ffffffff8a7f7818 RCX: ffff88801b40d700 > > RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffea0002790ec0 > > RBP: dffffc0000000000 R08: ffffffff81b0fa16 R09: fffff940004f21d9 > > R10: fffff940004f21d9 R11: 0000000000000000 R12: ffff88806c11c7b0 > > R13: 0000000000000000 R14: 1ffffd40004f21d9 R15: ffffea0002790ec0 > > FS: 0000555557165400(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 > > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > CR2: ffffffffffffffd6 CR3: 0000000030d85000 CR4: 00000000003526e0 > > > > > > --- > > 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [f2fs-dev] [syzbot] BUG: unable to handle kernel NULL pointer dereference in folio_mark_dirty @ 2021-12-07 4:19 ` Matthew Wilcox 0 siblings, 0 replies; 15+ messages in thread From: Matthew Wilcox @ 2021-12-07 4:19 UTC (permalink / raw) To: Andrew Morton Cc: syzbot, linux-mm, syzkaller-bugs, linux-kernel, linux-f2fs-devel On Mon, Dec 06, 2021 at 05:56:31PM -0800, Andrew Morton wrote: > > BUG: kernel NULL pointer dereference, address: 0000000000000000 > > cc linux-f2fs-devel@lists.sourceforge.net > > And willy, who might help with diagnosing this. But it does seem that > f2fs got itself a NULL page* then put it in places where it shouldn't have. I'm surprised it got that far. void f2fs_update_meta_page(struct f2fs_sb_info *sbi, void *src, block_t blk_addr) { struct page *page = f2fs_grab_meta_page(sbi, blk_addr); memcpy(page_address(page), src, PAGE_SIZE); set_page_dirty(page); f2fs_put_page(page, 1); } How does page_address(NULL) not crash first? Or return an address that can be the target of a memcpy()? > > #PF: supervisor instruction fetch in kernel mode > > #PF: error_code(0x0010) - not-present page > > PGD 70764067 P4D 70764067 PUD 0 > > Oops: 0010 [#1] PREEMPT SMP KASAN > > CPU: 1 PID: 6541 Comm: syz-executor.3 Not tainted 5.16.0-rc3-syzkaller #0 > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 > > RIP: 0010:0x0 > > Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. > > RSP: 0018:ffffc900027ff7f8 EFLAGS: 00010246 > > RAX: 1ffffffff14fef03 RBX: ffffffff8a7f7818 RCX: ffff88801b40d700 > > RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffea0002790ec0 > > RBP: dffffc0000000000 R08: ffffffff81b0fa16 R09: fffff940004f21d9 > > R10: fffff940004f21d9 R11: 0000000000000000 R12: ffff88806c11c7b0 > > R13: 0000000000000000 R14: 1ffffd40004f21d9 R15: ffffea0002790ec0 > > FS: 0000555557165400(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 > > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > CR2: ffffffffffffffd6 CR3: 0000000030d85000 CR4: 00000000003526e0 > > Call Trace: > > <TASK> > > folio_mark_dirty+0x136/0x270 mm/page-writeback.c:2639 > > f2fs_update_meta_page+0x4b/0x380 fs/f2fs/segment.c:2485 > > do_checkpoint fs/f2fs/checkpoint.c:1513 [inline] > > f2fs_write_checkpoint+0x31ad/0x5430 fs/f2fs/checkpoint.c:1674 > > f2fs_issue_checkpoint+0x361/0x4e0 > > sync_filesystem+0x19c/0x1f0 fs/sync.c:63 > > generic_shutdown_super+0x6b/0x300 fs/super.c:448 > > kill_block_super+0x79/0xd0 fs/super.c:1397 > > kill_f2fs_super+0x2f9/0x3c0 fs/f2fs/super.c:4478 > > deactivate_locked_super+0xa7/0xf0 fs/super.c:335 > > cleanup_mnt+0x462/0x510 fs/namespace.c:1137 > > task_work_run+0x146/0x1c0 kernel/task_work.c:164 > > tracehook_notify_resume include/linux/tracehook.h:189 [inline] > > exit_to_user_mode_loop kernel/entry/common.c:175 [inline] > > exit_to_user_mode_prepare+0x209/0x220 kernel/entry/common.c:207 > > __syscall_exit_to_user_mode_work kernel/entry/common.c:289 [inline] > > syscall_exit_to_user_mode+0x2e/0x70 kernel/entry/common.c:300 > > do_syscall_64+0x53/0xd0 arch/x86/entry/common.c:86 > > entry_SYSCALL_64_after_hwframe+0x44/0xae > > RIP: 0033:0x7f6cfdd59f57 > > Code: ff ff ff f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 31 f6 e9 09 00 00 00 66 0f 1f 84 00 00 00 00 00 b8 a6 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 > > RSP: 002b:00007fffcbddcad8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6 > > RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00007f6cfdd59f57 > > RDX: 00007fffcbddcbac RSI: 000000000000000a RDI: 00007fffcbddcba0 > > RBP: 00007fffcbddcba0 R08: 00000000ffffffff R09: 00007fffcbddc970 > > R10: 0000555557166903 R11: 0000000000000246 R12: 00007f6cfddb2105 > > R13: 00007fffcbdddc60 R14: 0000555557166810 R15: 00007fffcbdddca0 > > </TASK> > > Modules linked in: > > CR2: 0000000000000000 > > ---[ end trace 08eda5a5e35b48a0 ]--- > > RIP: 0010:0x0 > > Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. > > RSP: 0018:ffffc900027ff7f8 EFLAGS: 00010246 > > RAX: 1ffffffff14fef03 RBX: ffffffff8a7f7818 RCX: ffff88801b40d700 > > RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffea0002790ec0 > > RBP: dffffc0000000000 R08: ffffffff81b0fa16 R09: fffff940004f21d9 > > R10: fffff940004f21d9 R11: 0000000000000000 R12: ffff88806c11c7b0 > > R13: 0000000000000000 R14: 1ffffd40004f21d9 R15: ffffea0002790ec0 > > FS: 0000555557165400(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 > > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > CR2: ffffffffffffffd6 CR3: 0000000030d85000 CR4: 00000000003526e0 > > > > > > --- > > 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. _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [syzbot] BUG: unable to handle kernel NULL pointer dereference in folio_mark_dirty 2021-12-07 1:56 ` [f2fs-dev] " Andrew Morton @ 2021-12-07 4:30 ` Matthew Wilcox -1 siblings, 0 replies; 15+ messages in thread From: Matthew Wilcox @ 2021-12-07 4:30 UTC (permalink / raw) To: Andrew Morton Cc: syzbot, linux-kernel, linux-mm, syzkaller-bugs, linux-f2fs-devel On Mon, Dec 06, 2021 at 05:56:31PM -0800, Andrew Morton wrote: > On Sat, 04 Dec 2021 01:55:17 -0800 syzbot <syzbot+7cd473c2cac13fd2dd72@syzkaller.appspotmail.com> wrote: > > > Hello, > > > > syzbot found the following issue on: > > > > HEAD commit: 58e1100fdc59 MAINTAINERS: co-maintain random.c > > git tree: upstream > > console output: https://syzkaller.appspot.com/x/log.txt?x=1362881eb00000 > > kernel config: https://syzkaller.appspot.com/x/.config?x=e9ea28d2c3c2c389 > > dashboard link: https://syzkaller.appspot.com/bug?extid=7cd473c2cac13fd2dd72 > > compiler: Debian clang version 11.0.1-2, GNU ld (GNU Binutils for Debian) 2.35.2 > > > > Unfortunately, I don't have any reproducer for this issue yet. > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > > Reported-by: syzbot+7cd473c2cac13fd2dd72@syzkaller.appspotmail.com > > > > BUG: kernel NULL pointer dereference, address: 0000000000000000 > > cc linux-f2fs-devel@lists.sourceforge.net > > And willy, who might help with diagnosing this. But it does seem that > f2fs got itself a NULL page* then put it in places where it shouldn't have. Oh -- it's not a NULL data pointer. It's a NULL instruction pointer. > > #PF: supervisor instruction fetch in kernel mode > > #PF: error_code(0x0010) - not-present page > > PGD 70764067 P4D 70764067 PUD 0 > > Oops: 0010 [#1] PREEMPT SMP KASAN > > CPU: 1 PID: 6541 Comm: syz-executor.3 Not tainted 5.16.0-rc3-syzkaller #0 > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 > > RIP: 0010:0x0 > > Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. > > RSP: 0018:ffffc900027ff7f8 EFLAGS: 00010246 > > RAX: 1ffffffff14fef03 RBX: ffffffff8a7f7818 RCX: ffff88801b40d700 > > RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffea0002790ec0 > > RBP: dffffc0000000000 R08: ffffffff81b0fa16 R09: fffff940004f21d9 > > R10: fffff940004f21d9 R11: 0000000000000000 R12: ffff88806c11c7b0 > > R13: 0000000000000000 R14: 1ffffd40004f21d9 R15: ffffea0002790ec0 > > FS: 0000555557165400(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 > > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > CR2: ffffffffffffffd6 CR3: 0000000030d85000 CR4: 00000000003526e0 > > Call Trace: > > <TASK> > > folio_mark_dirty+0x136/0x270 mm/page-writeback.c:2639 if (likely(mapping)) { ... if (folio_test_reclaim(folio)) folio_clear_reclaim(folio); return mapping->a_ops->set_page_dirty(&folio->page); how do we get to a NULL ->set_page_dirty for a metadata page's mapping->a_ops? This is definitely an f2fs expert question. > > f2fs_update_meta_page+0x4b/0x380 fs/f2fs/segment.c:2485 > > do_checkpoint fs/f2fs/checkpoint.c:1513 [inline] > > f2fs_write_checkpoint+0x31ad/0x5430 fs/f2fs/checkpoint.c:1674 > > f2fs_issue_checkpoint+0x361/0x4e0 > > sync_filesystem+0x19c/0x1f0 fs/sync.c:63 > > generic_shutdown_super+0x6b/0x300 fs/super.c:448 > > kill_block_super+0x79/0xd0 fs/super.c:1397 > > kill_f2fs_super+0x2f9/0x3c0 fs/f2fs/super.c:4478 > > deactivate_locked_super+0xa7/0xf0 fs/super.c:335 > > cleanup_mnt+0x462/0x510 fs/namespace.c:1137 > > task_work_run+0x146/0x1c0 kernel/task_work.c:164 > > tracehook_notify_resume include/linux/tracehook.h:189 [inline] > > exit_to_user_mode_loop kernel/entry/common.c:175 [inline] > > exit_to_user_mode_prepare+0x209/0x220 kernel/entry/common.c:207 > > __syscall_exit_to_user_mode_work kernel/entry/common.c:289 [inline] > > syscall_exit_to_user_mode+0x2e/0x70 kernel/entry/common.c:300 > > do_syscall_64+0x53/0xd0 arch/x86/entry/common.c:86 > > entry_SYSCALL_64_after_hwframe+0x44/0xae > > RIP: 0033:0x7f6cfdd59f57 > > Code: ff ff ff f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 31 f6 e9 09 00 00 00 66 0f 1f 84 00 00 00 00 00 b8 a6 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 > > RSP: 002b:00007fffcbddcad8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6 > > RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00007f6cfdd59f57 > > RDX: 00007fffcbddcbac RSI: 000000000000000a RDI: 00007fffcbddcba0 > > RBP: 00007fffcbddcba0 R08: 00000000ffffffff R09: 00007fffcbddc970 > > R10: 0000555557166903 R11: 0000000000000246 R12: 00007f6cfddb2105 > > R13: 00007fffcbdddc60 R14: 0000555557166810 R15: 00007fffcbdddca0 > > </TASK> > > Modules linked in: > > CR2: 0000000000000000 > > ---[ end trace 08eda5a5e35b48a0 ]--- > > RIP: 0010:0x0 > > Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. > > RSP: 0018:ffffc900027ff7f8 EFLAGS: 00010246 > > RAX: 1ffffffff14fef03 RBX: ffffffff8a7f7818 RCX: ffff88801b40d700 > > RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffea0002790ec0 > > RBP: dffffc0000000000 R08: ffffffff81b0fa16 R09: fffff940004f21d9 > > R10: fffff940004f21d9 R11: 0000000000000000 R12: ffff88806c11c7b0 > > R13: 0000000000000000 R14: 1ffffd40004f21d9 R15: ffffea0002790ec0 > > FS: 0000555557165400(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 > > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > CR2: ffffffffffffffd6 CR3: 0000000030d85000 CR4: 00000000003526e0 > > > > > > --- > > 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [f2fs-dev] [syzbot] BUG: unable to handle kernel NULL pointer dereference in folio_mark_dirty @ 2021-12-07 4:30 ` Matthew Wilcox 0 siblings, 0 replies; 15+ messages in thread From: Matthew Wilcox @ 2021-12-07 4:30 UTC (permalink / raw) To: Andrew Morton Cc: syzbot, linux-mm, syzkaller-bugs, linux-kernel, linux-f2fs-devel On Mon, Dec 06, 2021 at 05:56:31PM -0800, Andrew Morton wrote: > On Sat, 04 Dec 2021 01:55:17 -0800 syzbot <syzbot+7cd473c2cac13fd2dd72@syzkaller.appspotmail.com> wrote: > > > Hello, > > > > syzbot found the following issue on: > > > > HEAD commit: 58e1100fdc59 MAINTAINERS: co-maintain random.c > > git tree: upstream > > console output: https://syzkaller.appspot.com/x/log.txt?x=1362881eb00000 > > kernel config: https://syzkaller.appspot.com/x/.config?x=e9ea28d2c3c2c389 > > dashboard link: https://syzkaller.appspot.com/bug?extid=7cd473c2cac13fd2dd72 > > compiler: Debian clang version 11.0.1-2, GNU ld (GNU Binutils for Debian) 2.35.2 > > > > Unfortunately, I don't have any reproducer for this issue yet. > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > > Reported-by: syzbot+7cd473c2cac13fd2dd72@syzkaller.appspotmail.com > > > > BUG: kernel NULL pointer dereference, address: 0000000000000000 > > cc linux-f2fs-devel@lists.sourceforge.net > > And willy, who might help with diagnosing this. But it does seem that > f2fs got itself a NULL page* then put it in places where it shouldn't have. Oh -- it's not a NULL data pointer. It's a NULL instruction pointer. > > #PF: supervisor instruction fetch in kernel mode > > #PF: error_code(0x0010) - not-present page > > PGD 70764067 P4D 70764067 PUD 0 > > Oops: 0010 [#1] PREEMPT SMP KASAN > > CPU: 1 PID: 6541 Comm: syz-executor.3 Not tainted 5.16.0-rc3-syzkaller #0 > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 > > RIP: 0010:0x0 > > Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. > > RSP: 0018:ffffc900027ff7f8 EFLAGS: 00010246 > > RAX: 1ffffffff14fef03 RBX: ffffffff8a7f7818 RCX: ffff88801b40d700 > > RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffea0002790ec0 > > RBP: dffffc0000000000 R08: ffffffff81b0fa16 R09: fffff940004f21d9 > > R10: fffff940004f21d9 R11: 0000000000000000 R12: ffff88806c11c7b0 > > R13: 0000000000000000 R14: 1ffffd40004f21d9 R15: ffffea0002790ec0 > > FS: 0000555557165400(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 > > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > CR2: ffffffffffffffd6 CR3: 0000000030d85000 CR4: 00000000003526e0 > > Call Trace: > > <TASK> > > folio_mark_dirty+0x136/0x270 mm/page-writeback.c:2639 if (likely(mapping)) { ... if (folio_test_reclaim(folio)) folio_clear_reclaim(folio); return mapping->a_ops->set_page_dirty(&folio->page); how do we get to a NULL ->set_page_dirty for a metadata page's mapping->a_ops? This is definitely an f2fs expert question. > > f2fs_update_meta_page+0x4b/0x380 fs/f2fs/segment.c:2485 > > do_checkpoint fs/f2fs/checkpoint.c:1513 [inline] > > f2fs_write_checkpoint+0x31ad/0x5430 fs/f2fs/checkpoint.c:1674 > > f2fs_issue_checkpoint+0x361/0x4e0 > > sync_filesystem+0x19c/0x1f0 fs/sync.c:63 > > generic_shutdown_super+0x6b/0x300 fs/super.c:448 > > kill_block_super+0x79/0xd0 fs/super.c:1397 > > kill_f2fs_super+0x2f9/0x3c0 fs/f2fs/super.c:4478 > > deactivate_locked_super+0xa7/0xf0 fs/super.c:335 > > cleanup_mnt+0x462/0x510 fs/namespace.c:1137 > > task_work_run+0x146/0x1c0 kernel/task_work.c:164 > > tracehook_notify_resume include/linux/tracehook.h:189 [inline] > > exit_to_user_mode_loop kernel/entry/common.c:175 [inline] > > exit_to_user_mode_prepare+0x209/0x220 kernel/entry/common.c:207 > > __syscall_exit_to_user_mode_work kernel/entry/common.c:289 [inline] > > syscall_exit_to_user_mode+0x2e/0x70 kernel/entry/common.c:300 > > do_syscall_64+0x53/0xd0 arch/x86/entry/common.c:86 > > entry_SYSCALL_64_after_hwframe+0x44/0xae > > RIP: 0033:0x7f6cfdd59f57 > > Code: ff ff ff f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 31 f6 e9 09 00 00 00 66 0f 1f 84 00 00 00 00 00 b8 a6 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 > > RSP: 002b:00007fffcbddcad8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6 > > RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00007f6cfdd59f57 > > RDX: 00007fffcbddcbac RSI: 000000000000000a RDI: 00007fffcbddcba0 > > RBP: 00007fffcbddcba0 R08: 00000000ffffffff R09: 00007fffcbddc970 > > R10: 0000555557166903 R11: 0000000000000246 R12: 00007f6cfddb2105 > > R13: 00007fffcbdddc60 R14: 0000555557166810 R15: 00007fffcbdddca0 > > </TASK> > > Modules linked in: > > CR2: 0000000000000000 > > ---[ end trace 08eda5a5e35b48a0 ]--- > > RIP: 0010:0x0 > > Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. > > RSP: 0018:ffffc900027ff7f8 EFLAGS: 00010246 > > RAX: 1ffffffff14fef03 RBX: ffffffff8a7f7818 RCX: ffff88801b40d700 > > RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffea0002790ec0 > > RBP: dffffc0000000000 R08: ffffffff81b0fa16 R09: fffff940004f21d9 > > R10: fffff940004f21d9 R11: 0000000000000000 R12: ffff88806c11c7b0 > > R13: 0000000000000000 R14: 1ffffd40004f21d9 R15: ffffea0002790ec0 > > FS: 0000555557165400(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 > > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > CR2: ffffffffffffffd6 CR3: 0000000030d85000 CR4: 00000000003526e0 > > > > > > --- > > 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. _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [f2fs-dev] [syzbot] BUG: unable to handle kernel NULL pointer dereference in folio_mark_dirty 2021-12-07 4:30 ` [f2fs-dev] " Matthew Wilcox @ 2021-12-07 21:39 ` Jaegeuk Kim -1 siblings, 0 replies; 15+ messages in thread From: Jaegeuk Kim @ 2021-12-07 21:39 UTC (permalink / raw) To: Matthew Wilcox Cc: Andrew Morton, syzbot, linux-mm, syzkaller-bugs, linux-kernel, linux-f2fs-devel On 12/07, Matthew Wilcox wrote: > On Mon, Dec 06, 2021 at 05:56:31PM -0800, Andrew Morton wrote: > > On Sat, 04 Dec 2021 01:55:17 -0800 syzbot <syzbot+7cd473c2cac13fd2dd72@syzkaller.appspotmail.com> wrote: > > > > > Hello, > > > > > > syzbot found the following issue on: > > > > > > HEAD commit: 58e1100fdc59 MAINTAINERS: co-maintain random.c > > > git tree: upstream > > > console output: https://syzkaller.appspot.com/x/log.txt?x=1362881eb00000 > > > kernel config: https://syzkaller.appspot.com/x/.config?x=e9ea28d2c3c2c389 > > > dashboard link: https://syzkaller.appspot.com/bug?extid=7cd473c2cac13fd2dd72 > > > compiler: Debian clang version 11.0.1-2, GNU ld (GNU Binutils for Debian) 2.35.2 > > > > > > Unfortunately, I don't have any reproducer for this issue yet. > > > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > > > Reported-by: syzbot+7cd473c2cac13fd2dd72@syzkaller.appspotmail.com > > > > > > BUG: kernel NULL pointer dereference, address: 0000000000000000 > > > > cc linux-f2fs-devel@lists.sourceforge.net > > > > And willy, who might help with diagnosing this. But it does seem that > > f2fs got itself a NULL page* then put it in places where it shouldn't have. > > Oh -- it's not a NULL data pointer. It's a NULL instruction pointer. > > > > #PF: supervisor instruction fetch in kernel mode > > > #PF: error_code(0x0010) - not-present page > > > PGD 70764067 P4D 70764067 PUD 0 > > > Oops: 0010 [#1] PREEMPT SMP KASAN > > > CPU: 1 PID: 6541 Comm: syz-executor.3 Not tainted 5.16.0-rc3-syzkaller #0 > > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 > > > RIP: 0010:0x0 > > > Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. > > > RSP: 0018:ffffc900027ff7f8 EFLAGS: 00010246 > > > RAX: 1ffffffff14fef03 RBX: ffffffff8a7f7818 RCX: ffff88801b40d700 > > > RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffea0002790ec0 > > > RBP: dffffc0000000000 R08: ffffffff81b0fa16 R09: fffff940004f21d9 > > > R10: fffff940004f21d9 R11: 0000000000000000 R12: ffff88806c11c7b0 > > > R13: 0000000000000000 R14: 1ffffd40004f21d9 R15: ffffea0002790ec0 > > > FS: 0000555557165400(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 > > > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > > CR2: ffffffffffffffd6 CR3: 0000000030d85000 CR4: 00000000003526e0 > > > Call Trace: > > > <TASK> > > > folio_mark_dirty+0x136/0x270 mm/page-writeback.c:2639 > > if (likely(mapping)) { > ... > if (folio_test_reclaim(folio)) > folio_clear_reclaim(folio); > return mapping->a_ops->set_page_dirty(&folio->page); > > how do we get to a NULL ->set_page_dirty for a metadata page's > mapping->a_ops? This is definitely an f2fs expert question. I can't find anything in f2fs, since that page was got by f2fs_grab_meta_page along with grab_cache_page() that we never unlocked it. 40 struct page *f2fs_grab_meta_page(struct f2fs_sb_info *sbi, pgoff_t index) 41 { 42 struct address_space *mapping = META_MAPPING(sbi); 43 struct page *page; 44 repeat: 45 page = f2fs_grab_cache_page(mapping, index, false); -> grab_cache_page(mapping, index); 46 if (!page) { 47 cond_resched(); 48 goto repeat; 49 } 50 f2fs_wait_on_page_writeback(page, META, true, true); 51 if (!PageUptodate(page)) 52 SetPageUptodate(page); 53 return page; 54 } Suspecting something in folio wrt folio_mapping()? 81 bool set_page_dirty(struct page *page) 82 { 83 return folio_mark_dirty(page_folio(page)); 84 } > > > > f2fs_update_meta_page+0x4b/0x380 fs/f2fs/segment.c:2485 > > > do_checkpoint fs/f2fs/checkpoint.c:1513 [inline] > > > f2fs_write_checkpoint+0x31ad/0x5430 fs/f2fs/checkpoint.c:1674 > > > f2fs_issue_checkpoint+0x361/0x4e0 > > > sync_filesystem+0x19c/0x1f0 fs/sync.c:63 > > > generic_shutdown_super+0x6b/0x300 fs/super.c:448 > > > kill_block_super+0x79/0xd0 fs/super.c:1397 > > > kill_f2fs_super+0x2f9/0x3c0 fs/f2fs/super.c:4478 > > > deactivate_locked_super+0xa7/0xf0 fs/super.c:335 > > > cleanup_mnt+0x462/0x510 fs/namespace.c:1137 > > > task_work_run+0x146/0x1c0 kernel/task_work.c:164 > > > tracehook_notify_resume include/linux/tracehook.h:189 [inline] > > > exit_to_user_mode_loop kernel/entry/common.c:175 [inline] > > > exit_to_user_mode_prepare+0x209/0x220 kernel/entry/common.c:207 > > > __syscall_exit_to_user_mode_work kernel/entry/common.c:289 [inline] > > > syscall_exit_to_user_mode+0x2e/0x70 kernel/entry/common.c:300 > > > do_syscall_64+0x53/0xd0 arch/x86/entry/common.c:86 > > > entry_SYSCALL_64_after_hwframe+0x44/0xae > > > RIP: 0033:0x7f6cfdd59f57 > > > Code: ff ff ff f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 31 f6 e9 09 00 00 00 66 0f 1f 84 00 00 00 00 00 b8 a6 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 > > > RSP: 002b:00007fffcbddcad8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6 > > > RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00007f6cfdd59f57 > > > RDX: 00007fffcbddcbac RSI: 000000000000000a RDI: 00007fffcbddcba0 > > > RBP: 00007fffcbddcba0 R08: 00000000ffffffff R09: 00007fffcbddc970 > > > R10: 0000555557166903 R11: 0000000000000246 R12: 00007f6cfddb2105 > > > R13: 00007fffcbdddc60 R14: 0000555557166810 R15: 00007fffcbdddca0 > > > </TASK> > > > Modules linked in: > > > CR2: 0000000000000000 > > > ---[ end trace 08eda5a5e35b48a0 ]--- > > > RIP: 0010:0x0 > > > Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. > > > RSP: 0018:ffffc900027ff7f8 EFLAGS: 00010246 > > > RAX: 1ffffffff14fef03 RBX: ffffffff8a7f7818 RCX: ffff88801b40d700 > > > RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffea0002790ec0 > > > RBP: dffffc0000000000 R08: ffffffff81b0fa16 R09: fffff940004f21d9 > > > R10: fffff940004f21d9 R11: 0000000000000000 R12: ffff88806c11c7b0 > > > R13: 0000000000000000 R14: 1ffffd40004f21d9 R15: ffffea0002790ec0 > > > FS: 0000555557165400(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 > > > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > > CR2: ffffffffffffffd6 CR3: 0000000030d85000 CR4: 00000000003526e0 > > > > > > > > > --- > > > 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. > > > _______________________________________________ > Linux-f2fs-devel mailing list > Linux-f2fs-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [f2fs-dev] [syzbot] BUG: unable to handle kernel NULL pointer dereference in folio_mark_dirty @ 2021-12-07 21:39 ` Jaegeuk Kim 0 siblings, 0 replies; 15+ messages in thread From: Jaegeuk Kim @ 2021-12-07 21:39 UTC (permalink / raw) To: Matthew Wilcox Cc: syzbot, syzkaller-bugs, linux-kernel, linux-f2fs-devel, linux-mm, Andrew Morton On 12/07, Matthew Wilcox wrote: > On Mon, Dec 06, 2021 at 05:56:31PM -0800, Andrew Morton wrote: > > On Sat, 04 Dec 2021 01:55:17 -0800 syzbot <syzbot+7cd473c2cac13fd2dd72@syzkaller.appspotmail.com> wrote: > > > > > Hello, > > > > > > syzbot found the following issue on: > > > > > > HEAD commit: 58e1100fdc59 MAINTAINERS: co-maintain random.c > > > git tree: upstream > > > console output: https://syzkaller.appspot.com/x/log.txt?x=1362881eb00000 > > > kernel config: https://syzkaller.appspot.com/x/.config?x=e9ea28d2c3c2c389 > > > dashboard link: https://syzkaller.appspot.com/bug?extid=7cd473c2cac13fd2dd72 > > > compiler: Debian clang version 11.0.1-2, GNU ld (GNU Binutils for Debian) 2.35.2 > > > > > > Unfortunately, I don't have any reproducer for this issue yet. > > > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > > > Reported-by: syzbot+7cd473c2cac13fd2dd72@syzkaller.appspotmail.com > > > > > > BUG: kernel NULL pointer dereference, address: 0000000000000000 > > > > cc linux-f2fs-devel@lists.sourceforge.net > > > > And willy, who might help with diagnosing this. But it does seem that > > f2fs got itself a NULL page* then put it in places where it shouldn't have. > > Oh -- it's not a NULL data pointer. It's a NULL instruction pointer. > > > > #PF: supervisor instruction fetch in kernel mode > > > #PF: error_code(0x0010) - not-present page > > > PGD 70764067 P4D 70764067 PUD 0 > > > Oops: 0010 [#1] PREEMPT SMP KASAN > > > CPU: 1 PID: 6541 Comm: syz-executor.3 Not tainted 5.16.0-rc3-syzkaller #0 > > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 > > > RIP: 0010:0x0 > > > Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. > > > RSP: 0018:ffffc900027ff7f8 EFLAGS: 00010246 > > > RAX: 1ffffffff14fef03 RBX: ffffffff8a7f7818 RCX: ffff88801b40d700 > > > RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffea0002790ec0 > > > RBP: dffffc0000000000 R08: ffffffff81b0fa16 R09: fffff940004f21d9 > > > R10: fffff940004f21d9 R11: 0000000000000000 R12: ffff88806c11c7b0 > > > R13: 0000000000000000 R14: 1ffffd40004f21d9 R15: ffffea0002790ec0 > > > FS: 0000555557165400(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 > > > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > > CR2: ffffffffffffffd6 CR3: 0000000030d85000 CR4: 00000000003526e0 > > > Call Trace: > > > <TASK> > > > folio_mark_dirty+0x136/0x270 mm/page-writeback.c:2639 > > if (likely(mapping)) { > ... > if (folio_test_reclaim(folio)) > folio_clear_reclaim(folio); > return mapping->a_ops->set_page_dirty(&folio->page); > > how do we get to a NULL ->set_page_dirty for a metadata page's > mapping->a_ops? This is definitely an f2fs expert question. I can't find anything in f2fs, since that page was got by f2fs_grab_meta_page along with grab_cache_page() that we never unlocked it. 40 struct page *f2fs_grab_meta_page(struct f2fs_sb_info *sbi, pgoff_t index) 41 { 42 struct address_space *mapping = META_MAPPING(sbi); 43 struct page *page; 44 repeat: 45 page = f2fs_grab_cache_page(mapping, index, false); -> grab_cache_page(mapping, index); 46 if (!page) { 47 cond_resched(); 48 goto repeat; 49 } 50 f2fs_wait_on_page_writeback(page, META, true, true); 51 if (!PageUptodate(page)) 52 SetPageUptodate(page); 53 return page; 54 } Suspecting something in folio wrt folio_mapping()? 81 bool set_page_dirty(struct page *page) 82 { 83 return folio_mark_dirty(page_folio(page)); 84 } > > > > f2fs_update_meta_page+0x4b/0x380 fs/f2fs/segment.c:2485 > > > do_checkpoint fs/f2fs/checkpoint.c:1513 [inline] > > > f2fs_write_checkpoint+0x31ad/0x5430 fs/f2fs/checkpoint.c:1674 > > > f2fs_issue_checkpoint+0x361/0x4e0 > > > sync_filesystem+0x19c/0x1f0 fs/sync.c:63 > > > generic_shutdown_super+0x6b/0x300 fs/super.c:448 > > > kill_block_super+0x79/0xd0 fs/super.c:1397 > > > kill_f2fs_super+0x2f9/0x3c0 fs/f2fs/super.c:4478 > > > deactivate_locked_super+0xa7/0xf0 fs/super.c:335 > > > cleanup_mnt+0x462/0x510 fs/namespace.c:1137 > > > task_work_run+0x146/0x1c0 kernel/task_work.c:164 > > > tracehook_notify_resume include/linux/tracehook.h:189 [inline] > > > exit_to_user_mode_loop kernel/entry/common.c:175 [inline] > > > exit_to_user_mode_prepare+0x209/0x220 kernel/entry/common.c:207 > > > __syscall_exit_to_user_mode_work kernel/entry/common.c:289 [inline] > > > syscall_exit_to_user_mode+0x2e/0x70 kernel/entry/common.c:300 > > > do_syscall_64+0x53/0xd0 arch/x86/entry/common.c:86 > > > entry_SYSCALL_64_after_hwframe+0x44/0xae > > > RIP: 0033:0x7f6cfdd59f57 > > > Code: ff ff ff f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 31 f6 e9 09 00 00 00 66 0f 1f 84 00 00 00 00 00 b8 a6 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 > > > RSP: 002b:00007fffcbddcad8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6 > > > RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00007f6cfdd59f57 > > > RDX: 00007fffcbddcbac RSI: 000000000000000a RDI: 00007fffcbddcba0 > > > RBP: 00007fffcbddcba0 R08: 00000000ffffffff R09: 00007fffcbddc970 > > > R10: 0000555557166903 R11: 0000000000000246 R12: 00007f6cfddb2105 > > > R13: 00007fffcbdddc60 R14: 0000555557166810 R15: 00007fffcbdddca0 > > > </TASK> > > > Modules linked in: > > > CR2: 0000000000000000 > > > ---[ end trace 08eda5a5e35b48a0 ]--- > > > RIP: 0010:0x0 > > > Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. > > > RSP: 0018:ffffc900027ff7f8 EFLAGS: 00010246 > > > RAX: 1ffffffff14fef03 RBX: ffffffff8a7f7818 RCX: ffff88801b40d700 > > > RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffea0002790ec0 > > > RBP: dffffc0000000000 R08: ffffffff81b0fa16 R09: fffff940004f21d9 > > > R10: fffff940004f21d9 R11: 0000000000000000 R12: ffff88806c11c7b0 > > > R13: 0000000000000000 R14: 1ffffd40004f21d9 R15: ffffea0002790ec0 > > > FS: 0000555557165400(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 > > > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > > CR2: ffffffffffffffd6 CR3: 0000000030d85000 CR4: 00000000003526e0 > > > > > > > > > --- > > > 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. > > > _______________________________________________ > Linux-f2fs-devel mailing list > Linux-f2fs-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [f2fs-dev] [syzbot] BUG: unable to handle kernel NULL pointer dereference in folio_mark_dirty 2021-12-07 21:39 ` Jaegeuk Kim @ 2021-12-07 22:00 ` Matthew Wilcox -1 siblings, 0 replies; 15+ messages in thread From: Matthew Wilcox @ 2021-12-07 22:00 UTC (permalink / raw) To: Jaegeuk Kim Cc: Andrew Morton, syzbot, linux-mm, syzkaller-bugs, linux-kernel, linux-f2fs-devel On Tue, Dec 07, 2021 at 01:39:06PM -0800, Jaegeuk Kim wrote: > On 12/07, Matthew Wilcox wrote: > > > > Call Trace: > > > > <TASK> > > > > folio_mark_dirty+0x136/0x270 mm/page-writeback.c:2639 > > > > if (likely(mapping)) { > > ... > > if (folio_test_reclaim(folio)) > > folio_clear_reclaim(folio); > > return mapping->a_ops->set_page_dirty(&folio->page); > > > > how do we get to a NULL ->set_page_dirty for a metadata page's > > mapping->a_ops? This is definitely an f2fs expert question. > > I can't find anything in f2fs, since that page was got by f2fs_grab_meta_page > along with grab_cache_page() that we never unlocked it. > > 40 struct page *f2fs_grab_meta_page(struct f2fs_sb_info *sbi, pgoff_t index) > 41 { > 42 struct address_space *mapping = META_MAPPING(sbi); > 43 struct page *page; > 44 repeat: > 45 page = f2fs_grab_cache_page(mapping, index, false); > > -> grab_cache_page(mapping, index); > > 46 if (!page) { > 47 cond_resched(); > 48 goto repeat; > 49 } > 50 f2fs_wait_on_page_writeback(page, META, true, true); > 51 if (!PageUptodate(page)) > 52 SetPageUptodate(page); > 53 return page; > 54 } > > > Suspecting something in folio wrt folio_mapping()? > > 81 bool set_page_dirty(struct page *page) > 82 { > 83 return folio_mark_dirty(page_folio(page)); > 84 } ... huh? How could folio_mapping() be getting this wrong? page_folio() does the same thing as compound_head() -- as far as I know you don't use compound pages for f2fs metadata, so this basically just casts the page to a struct folio. folio_mapping() is just like the old page_mapping() (see commit 2f52578f9c64). Unless you've done something like set the swapcache bit on your metadata page, it's just going to return folio->mapping (ie the same as page->mapping). ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [f2fs-dev] [syzbot] BUG: unable to handle kernel NULL pointer dereference in folio_mark_dirty @ 2021-12-07 22:00 ` Matthew Wilcox 0 siblings, 0 replies; 15+ messages in thread From: Matthew Wilcox @ 2021-12-07 22:00 UTC (permalink / raw) To: Jaegeuk Kim Cc: syzbot, syzkaller-bugs, linux-kernel, linux-f2fs-devel, linux-mm, Andrew Morton On Tue, Dec 07, 2021 at 01:39:06PM -0800, Jaegeuk Kim wrote: > On 12/07, Matthew Wilcox wrote: > > > > Call Trace: > > > > <TASK> > > > > folio_mark_dirty+0x136/0x270 mm/page-writeback.c:2639 > > > > if (likely(mapping)) { > > ... > > if (folio_test_reclaim(folio)) > > folio_clear_reclaim(folio); > > return mapping->a_ops->set_page_dirty(&folio->page); > > > > how do we get to a NULL ->set_page_dirty for a metadata page's > > mapping->a_ops? This is definitely an f2fs expert question. > > I can't find anything in f2fs, since that page was got by f2fs_grab_meta_page > along with grab_cache_page() that we never unlocked it. > > 40 struct page *f2fs_grab_meta_page(struct f2fs_sb_info *sbi, pgoff_t index) > 41 { > 42 struct address_space *mapping = META_MAPPING(sbi); > 43 struct page *page; > 44 repeat: > 45 page = f2fs_grab_cache_page(mapping, index, false); > > -> grab_cache_page(mapping, index); > > 46 if (!page) { > 47 cond_resched(); > 48 goto repeat; > 49 } > 50 f2fs_wait_on_page_writeback(page, META, true, true); > 51 if (!PageUptodate(page)) > 52 SetPageUptodate(page); > 53 return page; > 54 } > > > Suspecting something in folio wrt folio_mapping()? > > 81 bool set_page_dirty(struct page *page) > 82 { > 83 return folio_mark_dirty(page_folio(page)); > 84 } ... huh? How could folio_mapping() be getting this wrong? page_folio() does the same thing as compound_head() -- as far as I know you don't use compound pages for f2fs metadata, so this basically just casts the page to a struct folio. folio_mapping() is just like the old page_mapping() (see commit 2f52578f9c64). Unless you've done something like set the swapcache bit on your metadata page, it's just going to return folio->mapping (ie the same as page->mapping). _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [f2fs-dev] [syzbot] BUG: unable to handle kernel NULL pointer dereference in folio_mark_dirty 2021-12-07 22:00 ` Matthew Wilcox @ 2021-12-07 22:10 ` Jaegeuk Kim -1 siblings, 0 replies; 15+ messages in thread From: Jaegeuk Kim @ 2021-12-07 22:10 UTC (permalink / raw) To: Matthew Wilcox Cc: Andrew Morton, syzbot, linux-mm, syzkaller-bugs, linux-kernel, linux-f2fs-devel On 12/07, Matthew Wilcox wrote: > On Tue, Dec 07, 2021 at 01:39:06PM -0800, Jaegeuk Kim wrote: > > On 12/07, Matthew Wilcox wrote: > > > > > Call Trace: > > > > > <TASK> > > > > > folio_mark_dirty+0x136/0x270 mm/page-writeback.c:2639 > > > > > > if (likely(mapping)) { > > > ... > > > if (folio_test_reclaim(folio)) > > > folio_clear_reclaim(folio); > > > return mapping->a_ops->set_page_dirty(&folio->page); > > > > > > how do we get to a NULL ->set_page_dirty for a metadata page's > > > mapping->a_ops? This is definitely an f2fs expert question. > > > > I can't find anything in f2fs, since that page was got by f2fs_grab_meta_page > > along with grab_cache_page() that we never unlocked it. > > > > 40 struct page *f2fs_grab_meta_page(struct f2fs_sb_info *sbi, pgoff_t index) > > 41 { > > 42 struct address_space *mapping = META_MAPPING(sbi); > > 43 struct page *page; > > 44 repeat: > > 45 page = f2fs_grab_cache_page(mapping, index, false); > > > > -> grab_cache_page(mapping, index); > > > > 46 if (!page) { > > 47 cond_resched(); > > 48 goto repeat; > > 49 } > > 50 f2fs_wait_on_page_writeback(page, META, true, true); > > 51 if (!PageUptodate(page)) > > 52 SetPageUptodate(page); > > 53 return page; > > 54 } > > > > > > Suspecting something in folio wrt folio_mapping()? > > > > 81 bool set_page_dirty(struct page *page) > > 82 { > > 83 return folio_mark_dirty(page_folio(page)); > > 84 } > > ... huh? How could folio_mapping() be getting this wrong? Dunno. > page_folio() does the same thing as compound_head() -- as far as I know > you don't use compound pages for f2fs metadata, so this basically just > casts the page to a struct folio. > > folio_mapping() is just like the old page_mapping() (see commit > 2f52578f9c64). Unless you've done something like set the swapcache > bit on your metadata page, it's just going to return folio->mapping > (ie the same as page->mapping). Hmm, I've never seen this call stack before, so simply started to suspect folio. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [f2fs-dev] [syzbot] BUG: unable to handle kernel NULL pointer dereference in folio_mark_dirty @ 2021-12-07 22:10 ` Jaegeuk Kim 0 siblings, 0 replies; 15+ messages in thread From: Jaegeuk Kim @ 2021-12-07 22:10 UTC (permalink / raw) To: Matthew Wilcox Cc: syzbot, syzkaller-bugs, linux-kernel, linux-f2fs-devel, linux-mm, Andrew Morton On 12/07, Matthew Wilcox wrote: > On Tue, Dec 07, 2021 at 01:39:06PM -0800, Jaegeuk Kim wrote: > > On 12/07, Matthew Wilcox wrote: > > > > > Call Trace: > > > > > <TASK> > > > > > folio_mark_dirty+0x136/0x270 mm/page-writeback.c:2639 > > > > > > if (likely(mapping)) { > > > ... > > > if (folio_test_reclaim(folio)) > > > folio_clear_reclaim(folio); > > > return mapping->a_ops->set_page_dirty(&folio->page); > > > > > > how do we get to a NULL ->set_page_dirty for a metadata page's > > > mapping->a_ops? This is definitely an f2fs expert question. > > > > I can't find anything in f2fs, since that page was got by f2fs_grab_meta_page > > along with grab_cache_page() that we never unlocked it. > > > > 40 struct page *f2fs_grab_meta_page(struct f2fs_sb_info *sbi, pgoff_t index) > > 41 { > > 42 struct address_space *mapping = META_MAPPING(sbi); > > 43 struct page *page; > > 44 repeat: > > 45 page = f2fs_grab_cache_page(mapping, index, false); > > > > -> grab_cache_page(mapping, index); > > > > 46 if (!page) { > > 47 cond_resched(); > > 48 goto repeat; > > 49 } > > 50 f2fs_wait_on_page_writeback(page, META, true, true); > > 51 if (!PageUptodate(page)) > > 52 SetPageUptodate(page); > > 53 return page; > > 54 } > > > > > > Suspecting something in folio wrt folio_mapping()? > > > > 81 bool set_page_dirty(struct page *page) > > 82 { > > 83 return folio_mark_dirty(page_folio(page)); > > 84 } > > ... huh? How could folio_mapping() be getting this wrong? Dunno. > page_folio() does the same thing as compound_head() -- as far as I know > you don't use compound pages for f2fs metadata, so this basically just > casts the page to a struct folio. > > folio_mapping() is just like the old page_mapping() (see commit > 2f52578f9c64). Unless you've done something like set the swapcache > bit on your metadata page, it's just going to return folio->mapping > (ie the same as page->mapping). Hmm, I've never seen this call stack before, so simply started to suspect folio. _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [f2fs-dev] [syzbot] BUG: unable to handle kernel NULL pointer dereference in folio_mark_dirty 2021-12-07 22:10 ` Jaegeuk Kim @ 2021-12-12 9:15 ` Chao Yu -1 siblings, 0 replies; 15+ messages in thread From: Chao Yu @ 2021-12-12 9:15 UTC (permalink / raw) To: Jaegeuk Kim, Matthew Wilcox Cc: syzbot, syzkaller-bugs, linux-kernel, linux-f2fs-devel, linux-mm, Andrew Morton On 2021/12/8 6:10, Jaegeuk Kim wrote: > On 12/07, Matthew Wilcox wrote: >> On Tue, Dec 07, 2021 at 01:39:06PM -0800, Jaegeuk Kim wrote: >>> On 12/07, Matthew Wilcox wrote: >>>>>> Call Trace: >>>>>> <TASK> >>>>>> folio_mark_dirty+0x136/0x270 mm/page-writeback.c:2639 >>>> >>>> if (likely(mapping)) { >>>> ... >>>> if (folio_test_reclaim(folio)) >>>> folio_clear_reclaim(folio); >>>> return mapping->a_ops->set_page_dirty(&folio->page); >>>> >>>> how do we get to a NULL ->set_page_dirty for a metadata page's >>>> mapping->a_ops? This is definitely an f2fs expert question. >>> >>> I can't find anything in f2fs, since that page was got by f2fs_grab_meta_page >>> along with grab_cache_page() that we never unlocked it. >>> >>> 40 struct page *f2fs_grab_meta_page(struct f2fs_sb_info *sbi, pgoff_t index) >>> 41 { >>> 42 struct address_space *mapping = META_MAPPING(sbi); >>> 43 struct page *page; >>> 44 repeat: >>> 45 page = f2fs_grab_cache_page(mapping, index, false); >>> >>> -> grab_cache_page(mapping, index); >>> >>> 46 if (!page) { >>> 47 cond_resched(); >>> 48 goto repeat; >>> 49 } >>> 50 f2fs_wait_on_page_writeback(page, META, true, true); >>> 51 if (!PageUptodate(page)) >>> 52 SetPageUptodate(page); >>> 53 return page; >>> 54 } >>> >>> >>> Suspecting something in folio wrt folio_mapping()? >>> >>> 81 bool set_page_dirty(struct page *page) >>> 82 { >>> 83 return folio_mark_dirty(page_folio(page)); >>> 84 } >> >> ... huh? How could folio_mapping() be getting this wrong? > > Dunno. > >> page_folio() does the same thing as compound_head() -- as far as I know >> you don't use compound pages for f2fs metadata, so this basically just >> casts the page to a struct folio. >> >> folio_mapping() is just like the old page_mapping() (see commit >> 2f52578f9c64). Unless you've done something like set the swapcache >> bit on your metadata page, it's just going to return folio->mapping >> (ie the same as page->mapping). > > Hmm, I've never seen this call stack before, so simply started to suspect > folio. I'm afraid this is a f2fs bug... :( folio wasn't merged at the first report time (5.14-rc2). https://syzkaller.appspot.com/bug?extid=07ff38c9c93ca170de07 I doubt the direct reason of panic may be the same as the one of bug reported in bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215231 However, I still can't figure out why meta_inode's a_ops will change to f2fs_meta_aops. Thanks, > > > _______________________________________________ > Linux-f2fs-devel mailing list > Linux-f2fs-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [f2fs-dev] [syzbot] BUG: unable to handle kernel NULL pointer dereference in folio_mark_dirty @ 2021-12-12 9:15 ` Chao Yu 0 siblings, 0 replies; 15+ messages in thread From: Chao Yu @ 2021-12-12 9:15 UTC (permalink / raw) To: Jaegeuk Kim, Matthew Wilcox Cc: syzbot, syzkaller-bugs, linux-kernel, linux-f2fs-devel, linux-mm, Andrew Morton On 2021/12/8 6:10, Jaegeuk Kim wrote: > On 12/07, Matthew Wilcox wrote: >> On Tue, Dec 07, 2021 at 01:39:06PM -0800, Jaegeuk Kim wrote: >>> On 12/07, Matthew Wilcox wrote: >>>>>> Call Trace: >>>>>> <TASK> >>>>>> folio_mark_dirty+0x136/0x270 mm/page-writeback.c:2639 >>>> >>>> if (likely(mapping)) { >>>> ... >>>> if (folio_test_reclaim(folio)) >>>> folio_clear_reclaim(folio); >>>> return mapping->a_ops->set_page_dirty(&folio->page); >>>> >>>> how do we get to a NULL ->set_page_dirty for a metadata page's >>>> mapping->a_ops? This is definitely an f2fs expert question. >>> >>> I can't find anything in f2fs, since that page was got by f2fs_grab_meta_page >>> along with grab_cache_page() that we never unlocked it. >>> >>> 40 struct page *f2fs_grab_meta_page(struct f2fs_sb_info *sbi, pgoff_t index) >>> 41 { >>> 42 struct address_space *mapping = META_MAPPING(sbi); >>> 43 struct page *page; >>> 44 repeat: >>> 45 page = f2fs_grab_cache_page(mapping, index, false); >>> >>> -> grab_cache_page(mapping, index); >>> >>> 46 if (!page) { >>> 47 cond_resched(); >>> 48 goto repeat; >>> 49 } >>> 50 f2fs_wait_on_page_writeback(page, META, true, true); >>> 51 if (!PageUptodate(page)) >>> 52 SetPageUptodate(page); >>> 53 return page; >>> 54 } >>> >>> >>> Suspecting something in folio wrt folio_mapping()? >>> >>> 81 bool set_page_dirty(struct page *page) >>> 82 { >>> 83 return folio_mark_dirty(page_folio(page)); >>> 84 } >> >> ... huh? How could folio_mapping() be getting this wrong? > > Dunno. > >> page_folio() does the same thing as compound_head() -- as far as I know >> you don't use compound pages for f2fs metadata, so this basically just >> casts the page to a struct folio. >> >> folio_mapping() is just like the old page_mapping() (see commit >> 2f52578f9c64). Unless you've done something like set the swapcache >> bit on your metadata page, it's just going to return folio->mapping >> (ie the same as page->mapping). > > Hmm, I've never seen this call stack before, so simply started to suspect > folio. I'm afraid this is a f2fs bug... :( folio wasn't merged at the first report time (5.14-rc2). https://syzkaller.appspot.com/bug?extid=07ff38c9c93ca170de07 I doubt the direct reason of panic may be the same as the one of bug reported in bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215231 However, I still can't figure out why meta_inode's a_ops will change to f2fs_meta_aops. Thanks, > > > _______________________________________________ > Linux-f2fs-devel mailing list > Linux-f2fs-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2021-12-12 9:15 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-12-04 9:55 [syzbot] BUG: unable to handle kernel NULL pointer dereference in folio_mark_dirty syzbot 2021-12-07 1:56 ` Andrew Morton 2021-12-07 1:56 ` [f2fs-dev] " Andrew Morton 2021-12-07 4:19 ` Matthew Wilcox 2021-12-07 4:19 ` [f2fs-dev] " Matthew Wilcox 2021-12-07 4:30 ` Matthew Wilcox 2021-12-07 4:30 ` [f2fs-dev] " Matthew Wilcox 2021-12-07 21:39 ` Jaegeuk Kim 2021-12-07 21:39 ` Jaegeuk Kim 2021-12-07 22:00 ` Matthew Wilcox 2021-12-07 22:00 ` Matthew Wilcox 2021-12-07 22:10 ` Jaegeuk Kim 2021-12-07 22:10 ` Jaegeuk Kim 2021-12-12 9:15 ` Chao Yu 2021-12-12 9:15 ` Chao Yu
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.