mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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.


      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®