Message ID | tencent_C8EA75F1764366383C3F373A972436904A09@qq.com (mailing list archive) |
---|---|
State | New |
Headers | show |
Series | [V3] ocfs2: add a sanity check for i_size | expand |
Hello,
syzbot has tested the proposed patch and the reproducer did not trigger any issue:
Reported-by: syzbot+797d4829dafe3f11dce7@syzkaller.appspotmail.com
Tested-by: syzbot+797d4829dafe3f11dce7@syzkaller.appspotmail.com
Tested on:
commit: 6485cf5e Merge tag 'hid-for-linus-2024101301' of git:/..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=17186887980000
kernel config: https://syzkaller.appspot.com/x/.config?x=164d2822debd8b0d
dashboard link: https://syzkaller.appspot.com/bug?extid=797d4829dafe3f11dce7
compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
patch: https://syzkaller.appspot.com/x/patch.diff?x=14cb0030580000
Note: testing is done by a robot and is best-effort only.
On 10/14/24 7:47 PM, Edward Adam Davis wrote: > Syzbot reported a BUG in ocfs2_read_virt_blocks. > ------------[ cut here ]------------ > kernel BUG at fs/ocfs2/extent_map.c:971! > Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI > CPU: 1 UID: 0 PID: 5221 Comm: syz-executor117 Not tainted 6.12.0-rc2-syzkaller-00006-g87d6aab2389e #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 > RIP: 0010:ocfs2_read_virt_blocks+0xaa3/0xb20 fs/ocfs2/extent_map.c:971 > Code: 8b 54 24 30 8b 4c 24 1c 4c 8b 44 24 38 45 89 e1 ff 74 24 48 e8 7e 0a 0c 00 48 83 c4 08 eb 25 e8 43 d2 34 08 e8 ee d1 0c fe 90 <0f> 0b e8 e6 d1 0c fe 4c 89 e8 45 89 e5 49 89 c4 e9 01 f7 ff ff e8 > RSP: 0018:ffffc90002e2e820 EFLAGS: 00010293 > RAX: ffffffff83881432 RBX: 0000000000000000 RCX: ffff88802d3e9e00 > RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 > RBP: ffffc90002e2e9f0 R08: ffffffff83880eae R09: 1ffffffff203781d > R10: dffffc0000000000 R11: fffffbfff203781e R12: ffff8880764d8878 > R13: 0000000000000000 R14: 0000000000000000 R15: 1ffff920005c5d18 > FS: 000055557cd55380(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 00005628fd41e058 CR3: 000000002d2e6000 CR4: 00000000003526f0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > Call Trace: > <TASK> > ocfs2_read_dir_block+0x106/0x5c0 fs/ocfs2/dir.c:508 > ocfs2_find_dir_space_el fs/ocfs2/dir.c:3427 [inline] // status = ocfs2_read_dir_block(dir, 0, &bh, 0); As I replied before, the comment behind seems unneeded. > ocfs2_prepare_dir_for_insert+0x3f2/0x5c60 fs/ocfs2/dir.c:4274 > ocfs2_mknod+0xcaf/0x2b40 fs/ocfs2/namei.c:292 > ocfs2_create+0x1ab/0x480 fs/ocfs2/namei.c:672 > lookup_open fs/namei.c:3595 [inline] > open_last_lookups fs/namei.c:3694 [inline] > path_openat+0x1c03/0x3590 fs/namei.c:3930 > do_filp_open+0x235/0x490 fs/namei.c:3960 > do_sys_openat2+0x13e/0x1d0 fs/open.c:1415 > do_sys_open fs/open.c:1430 [inline] > __do_sys_openat fs/open.c:1446 [inline] > __se_sys_openat fs/open.c:1441 [inline] > __x64_sys_openat+0x247/0x2a0 fs/open.c:1441 > do_syscall_x64 arch/x86/entry/common.c:52 [inline] > do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 > entry_SYSCALL_64_after_hwframe+0x77/0x7f > > In this path, v_block(0), flags(0), and nr(1) are fixed values that are > hard coded, so if i_size is 0, the bug will be triggered. > This is not a proper commit log. You have to convert to the user scenario, but not simply list the parameters value that cause the issue. > Reported-and-tested-by: syzbot+797d4829dafe3f11dce7@syzkaller.appspotmail.com > Closes: https://syzkaller.appspot.com/bug?extid=797d4829dafe3f11dce7 > Signed-off-by: Edward Adam Davis <eadavis@qq.com> > --- > V1 -> V2: keep rc to 0 when falgs contains READHEAD > V2 -> V3: check i_size only and alert subject and comments > > fs/ocfs2/extent_map.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > #syz test > > diff --git a/fs/ocfs2/extent_map.c b/fs/ocfs2/extent_map.c > index f7672472fa82..29d27a70dbdd 100644 > --- a/fs/ocfs2/extent_map.c > +++ b/fs/ocfs2/extent_map.c > @@ -961,13 +961,17 @@ int ocfs2_read_virt_blocks(struct inode *inode, u64 v_block, int nr, > int rc = 0; > u64 p_block, p_count; > int i, count, done = 0; > + loff_t i_size = i_size_read(inode); > > trace_ocfs2_read_virt_blocks( > inode, (unsigned long long)v_block, nr, bhs, flags, > validate); > > + if (!i_size) > + return -EINVAL; > + Take a more consideration, inode size 0 doesn't mean it has no blocks, since we have a case that fallocate with KEEP_SIZE. Could you please check inode->i_blocks in above coredump? Thanks, Joseph > if (((v_block + nr - 1) << inode->i_sb->s_blocksize_bits) >= > - i_size_read(inode)) { > + i_size) { > BUG_ON(!(flags & OCFS2_BH_READAHEAD)); > goto out; > }
On 10/16/24 10:06 AM, Joseph Qi wrote: > > > On 10/14/24 7:47 PM, Edward Adam Davis wrote: >> Syzbot reported a BUG in ocfs2_read_virt_blocks. >> ------------[ cut here ]------------ >> kernel BUG at fs/ocfs2/extent_map.c:971! >> Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI >> CPU: 1 UID: 0 PID: 5221 Comm: syz-executor117 Not tainted 6.12.0-rc2-syzkaller-00006-g87d6aab2389e #0 >> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 >> RIP: 0010:ocfs2_read_virt_blocks+0xaa3/0xb20 fs/ocfs2/extent_map.c:971 >> Code: 8b 54 24 30 8b 4c 24 1c 4c 8b 44 24 38 45 89 e1 ff 74 24 48 e8 7e 0a 0c 00 48 83 c4 08 eb 25 e8 43 d2 34 08 e8 ee d1 0c fe 90 <0f> 0b e8 e6 d1 0c fe 4c 89 e8 45 89 e5 49 89 c4 e9 01 f7 ff ff e8 >> RSP: 0018:ffffc90002e2e820 EFLAGS: 00010293 >> RAX: ffffffff83881432 RBX: 0000000000000000 RCX: ffff88802d3e9e00 >> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 >> RBP: ffffc90002e2e9f0 R08: ffffffff83880eae R09: 1ffffffff203781d >> R10: dffffc0000000000 R11: fffffbfff203781e R12: ffff8880764d8878 >> R13: 0000000000000000 R14: 0000000000000000 R15: 1ffff920005c5d18 >> FS: 000055557cd55380(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 >> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >> CR2: 00005628fd41e058 CR3: 000000002d2e6000 CR4: 00000000003526f0 >> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 >> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 >> Call Trace: >> <TASK> >> ocfs2_read_dir_block+0x106/0x5c0 fs/ocfs2/dir.c:508 >> ocfs2_find_dir_space_el fs/ocfs2/dir.c:3427 [inline] // status = ocfs2_read_dir_block(dir, 0, &bh, 0); > > As I replied before, the comment behind seems unneeded. > >> ocfs2_prepare_dir_for_insert+0x3f2/0x5c60 fs/ocfs2/dir.c:4274 >> ocfs2_mknod+0xcaf/0x2b40 fs/ocfs2/namei.c:292 >> ocfs2_create+0x1ab/0x480 fs/ocfs2/namei.c:672 >> lookup_open fs/namei.c:3595 [inline] >> open_last_lookups fs/namei.c:3694 [inline] >> path_openat+0x1c03/0x3590 fs/namei.c:3930 >> do_filp_open+0x235/0x490 fs/namei.c:3960 >> do_sys_openat2+0x13e/0x1d0 fs/open.c:1415 >> do_sys_open fs/open.c:1430 [inline] >> __do_sys_openat fs/open.c:1446 [inline] >> __se_sys_openat fs/open.c:1441 [inline] >> __x64_sys_openat+0x247/0x2a0 fs/open.c:1441 >> do_syscall_x64 arch/x86/entry/common.c:52 [inline] >> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 >> entry_SYSCALL_64_after_hwframe+0x77/0x7f >> >> In this path, v_block(0), flags(0), and nr(1) are fixed values that are >> hard coded, so if i_size is 0, the bug will be triggered. >> > > This is not a proper commit log. > You have to convert to the user scenario, but not simply list the > parameters value that cause the issue. > >> Reported-and-tested-by: syzbot+797d4829dafe3f11dce7@syzkaller.appspotmail.com >> Closes: https://syzkaller.appspot.com/bug?extid=797d4829dafe3f11dce7 >> Signed-off-by: Edward Adam Davis <eadavis@qq.com> >> --- >> V1 -> V2: keep rc to 0 when falgs contains READHEAD >> V2 -> V3: check i_size only and alert subject and comments >> >> fs/ocfs2/extent_map.c | 6 +++++- >> 1 file changed, 5 insertions(+), 1 deletion(-) >> >> #syz test >> BTW, please don't mix syzbot test command into the formal patch. >> diff --git a/fs/ocfs2/extent_map.c b/fs/ocfs2/extent_map.c >> index f7672472fa82..29d27a70dbdd 100644 >> --- a/fs/ocfs2/extent_map.c >> +++ b/fs/ocfs2/extent_map.c >> @@ -961,13 +961,17 @@ int ocfs2_read_virt_blocks(struct inode *inode, u64 v_block, int nr, >> int rc = 0; >> u64 p_block, p_count; >> int i, count, done = 0; >> + loff_t i_size = i_size_read(inode); >> >> trace_ocfs2_read_virt_blocks( >> inode, (unsigned long long)v_block, nr, bhs, flags, >> validate); >> >> + if (!i_size) >> + return -EINVAL; >> + > > Take a more consideration, inode size 0 doesn't mean it has no blocks, > since we have a case that fallocate with KEEP_SIZE. > Could you please check inode->i_blocks in above coredump? > > Thanks, > Joseph > >> if (((v_block + nr - 1) << inode->i_sb->s_blocksize_bits) >= >> - i_size_read(inode)) { >> + i_size) { >> BUG_ON(!(flags & OCFS2_BH_READAHEAD)); >> goto out; >> } >
On Wed, 16 Oct 2024 10:06:27 +0800, Joseph Qi wrote: > > Reported-and-tested-by: syzbot+797d4829dafe3f11dce7@syzkaller.appspotmail.com > > Closes: https://syzkaller.appspot.com/bug?extid=797d4829dafe3f11dce7 > > Signed-off-by: Edward Adam Davis <eadavis@qq.com> > > --- > > V1 -> V2: keep rc to 0 when falgs contains READHEAD > > V2 -> V3: check i_size only and alert subject and comments > > > > fs/ocfs2/extent_map.c | 6 +++++- > > 1 file changed, 5 insertions(+), 1 deletion(-) > > > > #syz test > > > > diff --git a/fs/ocfs2/extent_map.c b/fs/ocfs2/extent_map.c > > index f7672472fa82..29d27a70dbdd 100644 > > --- a/fs/ocfs2/extent_map.c > > +++ b/fs/ocfs2/extent_map.c > > @@ -961,13 +961,17 @@ int ocfs2_read_virt_blocks(struct inode *inode, u64 v_block, int nr, > > int rc = 0; > > u64 p_block, p_count; > > int i, count, done = 0; > > + loff_t i_size = i_size_read(inode); > > > > trace_ocfs2_read_virt_blocks( > > inode, (unsigned long long)v_block, nr, bhs, flags, > > validate); > > > > + if (!i_size) > > + return -EINVAL; > > + > > Take a more consideration, inode size 0 doesn't mean it has no blocks, > since we have a case that fallocate with KEEP_SIZE. > Could you please check inode->i_blocks in above coredump? I have previously verified the value of inode->i_blocks in my testing environment, which is 0. BR, Edward
On 10/16/24 11:52 AM, Edward Adam Davis wrote: > On Wed, 16 Oct 2024 10:06:27 +0800, Joseph Qi wrote: >>> Reported-and-tested-by: syzbot+797d4829dafe3f11dce7@syzkaller.appspotmail.com >>> Closes: https://syzkaller.appspot.com/bug?extid=797d4829dafe3f11dce7 >>> Signed-off-by: Edward Adam Davis <eadavis@qq.com> >>> --- >>> V1 -> V2: keep rc to 0 when falgs contains READHEAD >>> V2 -> V3: check i_size only and alert subject and comments >>> >>> fs/ocfs2/extent_map.c | 6 +++++- >>> 1 file changed, 5 insertions(+), 1 deletion(-) >>> >>> #syz test >>> >>> diff --git a/fs/ocfs2/extent_map.c b/fs/ocfs2/extent_map.c >>> index f7672472fa82..29d27a70dbdd 100644 >>> --- a/fs/ocfs2/extent_map.c >>> +++ b/fs/ocfs2/extent_map.c >>> @@ -961,13 +961,17 @@ int ocfs2_read_virt_blocks(struct inode *inode, u64 v_block, int nr, >>> int rc = 0; >>> u64 p_block, p_count; >>> int i, count, done = 0; >>> + loff_t i_size = i_size_read(inode); >>> >>> trace_ocfs2_read_virt_blocks( >>> inode, (unsigned long long)v_block, nr, bhs, flags, >>> validate); >>> >>> + if (!i_size) >>> + return -EINVAL; >>> + >> >> Take a more consideration, inode size 0 doesn't mean it has no blocks, >> since we have a case that fallocate with KEEP_SIZE. >> Could you please check inode->i_blocks in above coredump? > I have previously verified the value of inode->i_blocks in my testing environment, which is 0. > So it seems the check condition should be: (v_block + nr) > (inode->i_blocks >> (inode->i_sb->s_blocksize_bits - 9))
On Wed, 16 Oct 2024 19:08:26 +0800, Joseph Qi wrote: > On 10/16/24 11:52 AM, Edward Adam Davis wrote: > > On Wed, 16 Oct 2024 10:06:27 +0800, Joseph Qi wrote: > >>> Reported-and-tested-by: syzbot+797d4829dafe3f11dce7@syzkaller.appspotmail.com > >>> Closes: https://syzkaller.appspot.com/bug?extid=797d4829dafe3f11dce7 > >>> Signed-off-by: Edward Adam Davis <eadavis@qq.com> > >>> --- > >>> V1 -> V2: keep rc to 0 when falgs contains READHEAD > >>> V2 -> V3: check i_size only and alert subject and comments > >>> > >>> fs/ocfs2/extent_map.c | 6 +++++- > >>> 1 file changed, 5 insertions(+), 1 deletion(-) > >>> > >>> #syz test > >>> > >>> diff --git a/fs/ocfs2/extent_map.c b/fs/ocfs2/extent_map.c > >>> index f7672472fa82..29d27a70dbdd 100644 > >>> --- a/fs/ocfs2/extent_map.c > >>> +++ b/fs/ocfs2/extent_map.c > >>> @@ -961,13 +961,17 @@ int ocfs2_read_virt_blocks(struct inode *inode, u64 v_block, int nr, > >>> int rc = 0; > >>> u64 p_block, p_count; > >>> int i, count, done = 0; > >>> + loff_t i_size = i_size_read(inode); > >>> > >>> trace_ocfs2_read_virt_blocks( > >>> inode, (unsigned long long)v_block, nr, bhs, flags, > >>> validate); > >>> > >>> + if (!i_size) > >>> + return -EINVAL; > >>> + > >> > >> Take a more consideration, inode size 0 doesn't mean it has no blocks, > >> since we have a case that fallocate with KEEP_SIZE. > >> Could you please check inode->i_blocks in above coredump? > > I have previously verified the value of inode->i_blocks in my testing environment, which is 0. > > > So it seems the check condition should be: > > (v_block + nr) > (inode->i_blocks >> (inode->i_sb->s_blocksize_bits - 9)) Do you mean like this? diff --git a/fs/ocfs2/extent_map.c b/fs/ocfs2/extent_map.c index f7672472fa82..9613cd356ac5 100644 --- a/fs/ocfs2/extent_map.c +++ b/fs/ocfs2/extent_map.c @@ -966,6 +966,9 @@ int ocfs2_read_virt_blocks(struct inode *inode, u64 v_block, int nr, inode, (unsigned long long)v_block, nr, bhs, flags, validate); + if ((v_block + nr) > (inode->i_blocks >> (inode->i_sb->s_blocksize_bits - 9))) + return -EINVAL; + if (((v_block + nr - 1) << inode->i_sb->s_blocksize_bits) >= i_size_read(inode)) { BUG_ON(!(flags & OCFS2_BH_READAHEAD)); BR, Edward
On 10/16/24 7:57 PM, Edward Adam Davis wrote: > On Wed, 16 Oct 2024 19:08:26 +0800, Joseph Qi wrote: >> On 10/16/24 11:52 AM, Edward Adam Davis wrote: >>> On Wed, 16 Oct 2024 10:06:27 +0800, Joseph Qi wrote: >>>>> Reported-and-tested-by: syzbot+797d4829dafe3f11dce7@syzkaller.appspotmail.com >>>>> Closes: https://syzkaller.appspot.com/bug?extid=797d4829dafe3f11dce7 >>>>> Signed-off-by: Edward Adam Davis <eadavis@qq.com> >>>>> --- >>>>> V1 -> V2: keep rc to 0 when falgs contains READHEAD >>>>> V2 -> V3: check i_size only and alert subject and comments >>>>> >>>>> fs/ocfs2/extent_map.c | 6 +++++- >>>>> 1 file changed, 5 insertions(+), 1 deletion(-) >>>>> >>>>> #syz test >>>>> >>>>> diff --git a/fs/ocfs2/extent_map.c b/fs/ocfs2/extent_map.c >>>>> index f7672472fa82..29d27a70dbdd 100644 >>>>> --- a/fs/ocfs2/extent_map.c >>>>> +++ b/fs/ocfs2/extent_map.c >>>>> @@ -961,13 +961,17 @@ int ocfs2_read_virt_blocks(struct inode *inode, u64 v_block, int nr, >>>>> int rc = 0; >>>>> u64 p_block, p_count; >>>>> int i, count, done = 0; >>>>> + loff_t i_size = i_size_read(inode); >>>>> >>>>> trace_ocfs2_read_virt_blocks( >>>>> inode, (unsigned long long)v_block, nr, bhs, flags, >>>>> validate); >>>>> >>>>> + if (!i_size) >>>>> + return -EINVAL; >>>>> + >>>> >>>> Take a more consideration, inode size 0 doesn't mean it has no blocks, >>>> since we have a case that fallocate with KEEP_SIZE. >>>> Could you please check inode->i_blocks in above coredump? >>> I have previously verified the value of inode->i_blocks in my testing environment, which is 0. >>> >> So it seems the check condition should be: >> >> (v_block + nr) > (inode->i_blocks >> (inode->i_sb->s_blocksize_bits - 9)) > Do you mean like this? > > diff --git a/fs/ocfs2/extent_map.c b/fs/ocfs2/extent_map.c > index f7672472fa82..9613cd356ac5 100644 > --- a/fs/ocfs2/extent_map.c > +++ b/fs/ocfs2/extent_map.c > @@ -966,6 +966,9 @@ int ocfs2_read_virt_blocks(struct inode *inode, u64 v_block, int nr, > inode, (unsigned long long)v_block, nr, bhs, flags, > validate); > > + if ((v_block + nr) > (inode->i_blocks >> (inode->i_sb->s_blocksize_bits - 9))) > + return -EINVAL; > + > if (((v_block + nr - 1) << inode->i_sb->s_blocksize_bits) >= > i_size_read(inode)) { > BUG_ON(!(flags & OCFS2_BH_READAHEAD)); > Right, which mean the block read request is invalid.
diff --git a/fs/ocfs2/extent_map.c b/fs/ocfs2/extent_map.c index f7672472fa82..29d27a70dbdd 100644 --- a/fs/ocfs2/extent_map.c +++ b/fs/ocfs2/extent_map.c @@ -961,13 +961,17 @@ int ocfs2_read_virt_blocks(struct inode *inode, u64 v_block, int nr, int rc = 0; u64 p_block, p_count; int i, count, done = 0; + loff_t i_size = i_size_read(inode); trace_ocfs2_read_virt_blocks( inode, (unsigned long long)v_block, nr, bhs, flags, validate); + if (!i_size) + return -EINVAL; + if (((v_block + nr - 1) << inode->i_sb->s_blocksize_bits) >= - i_size_read(inode)) { + i_size) { BUG_ON(!(flags & OCFS2_BH_READAHEAD)); goto out; }
Syzbot reported a BUG in ocfs2_read_virt_blocks. ------------[ cut here ]------------ kernel BUG at fs/ocfs2/extent_map.c:971! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 UID: 0 PID: 5221 Comm: syz-executor117 Not tainted 6.12.0-rc2-syzkaller-00006-g87d6aab2389e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:ocfs2_read_virt_blocks+0xaa3/0xb20 fs/ocfs2/extent_map.c:971 Code: 8b 54 24 30 8b 4c 24 1c 4c 8b 44 24 38 45 89 e1 ff 74 24 48 e8 7e 0a 0c 00 48 83 c4 08 eb 25 e8 43 d2 34 08 e8 ee d1 0c fe 90 <0f> 0b e8 e6 d1 0c fe 4c 89 e8 45 89 e5 49 89 c4 e9 01 f7 ff ff e8 RSP: 0018:ffffc90002e2e820 EFLAGS: 00010293 RAX: ffffffff83881432 RBX: 0000000000000000 RCX: ffff88802d3e9e00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc90002e2e9f0 R08: ffffffff83880eae R09: 1ffffffff203781d R10: dffffc0000000000 R11: fffffbfff203781e R12: ffff8880764d8878 R13: 0000000000000000 R14: 0000000000000000 R15: 1ffff920005c5d18 FS: 000055557cd55380(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005628fd41e058 CR3: 000000002d2e6000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ocfs2_read_dir_block+0x106/0x5c0 fs/ocfs2/dir.c:508 ocfs2_find_dir_space_el fs/ocfs2/dir.c:3427 [inline] // status = ocfs2_read_dir_block(dir, 0, &bh, 0); ocfs2_prepare_dir_for_insert+0x3f2/0x5c60 fs/ocfs2/dir.c:4274 ocfs2_mknod+0xcaf/0x2b40 fs/ocfs2/namei.c:292 ocfs2_create+0x1ab/0x480 fs/ocfs2/namei.c:672 lookup_open fs/namei.c:3595 [inline] open_last_lookups fs/namei.c:3694 [inline] path_openat+0x1c03/0x3590 fs/namei.c:3930 do_filp_open+0x235/0x490 fs/namei.c:3960 do_sys_openat2+0x13e/0x1d0 fs/open.c:1415 do_sys_open fs/open.c:1430 [inline] __do_sys_openat fs/open.c:1446 [inline] __se_sys_openat fs/open.c:1441 [inline] __x64_sys_openat+0x247/0x2a0 fs/open.c:1441 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f In this path, v_block(0), flags(0), and nr(1) are fixed values that are hard coded, so if i_size is 0, the bug will be triggered. Reported-and-tested-by: syzbot+797d4829dafe3f11dce7@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=797d4829dafe3f11dce7 Signed-off-by: Edward Adam Davis <eadavis@qq.com> --- V1 -> V2: keep rc to 0 when falgs contains READHEAD V2 -> V3: check i_size only and alert subject and comments fs/ocfs2/extent_map.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) #syz test