From: Joseph Qi <joseph.qi@linux.alibaba.com>
To: Edward Adam Davis <eadavis@qq.com>
Cc: jlbec@evilplan.org, linux-kernel@vger.kernel.org,
mark@fasheh.com, ocfs2-devel@lists.linux.dev,
syzbot+797d4829dafe3f11dce7@syzkaller.appspotmail.com,
syzkaller-bugs@googlegroups.com
Subject: Re: [PATCH V3] ocfs2: add a sanity check for i_size
Date: Wed, 16 Oct 2024 20:13:25 +0800 [thread overview]
Message-ID: <d2315d44-8c45-4e1a-adcf-a818a5e31fef@linux.alibaba.com> (raw)
In-Reply-To: <tencent_A6B4645A17675769C6D6F37A8362C9660305@qq.com>
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.
prev parent reply other threads:[~2024-10-16 12:13 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-12 9:51 [syzbot] [ocfs2?] kernel BUG in ocfs2_read_virt_blocks syzbot
2024-10-13 6:19 ` Edward Adam Davis
2024-10-13 7:29 ` [syzbot] " syzbot
2024-10-13 13:25 ` [PATCH] ocfs2: BUG is meaningless when the flags is 0 Edward Adam Davis
2024-10-13 23:31 ` [PATCH V2] " Edward Adam Davis
2024-10-14 6:28 ` heming.zhao
2024-10-14 7:00 ` [syzbot] [ocfs2?] kernel BUG in ocfs2_read_virt_blocks syzbot
2024-10-14 6:33 ` [PATCH V2] ocfs2: BUG is meaningless when the flags is 0 Joseph Qi
2024-10-14 11:47 ` [PATCH V3] ocfs2: add a sanity check for i_size Edward Adam Davis
2024-10-14 12:24 ` [syzbot] [ocfs2?] kernel BUG in ocfs2_read_virt_blocks syzbot
2024-10-16 2:06 ` [PATCH V3] ocfs2: add a sanity check for i_size Joseph Qi
2024-10-16 2:10 ` Joseph Qi
2024-10-16 3:52 ` Edward Adam Davis
2024-10-16 11:08 ` Joseph Qi
2024-10-16 11:57 ` Edward Adam Davis
2024-10-16 12:13 ` Joseph Qi [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d2315d44-8c45-4e1a-adcf-a818a5e31fef@linux.alibaba.com \
--to=joseph.qi@linux.alibaba.com \
--cc=eadavis@qq.com \
--cc=jlbec@evilplan.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark@fasheh.com \
--cc=ocfs2-devel@lists.linux.dev \
--cc=syzbot+797d4829dafe3f11dce7@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®