All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ritesh Harjani <riteshh@linux.ibm.com>
To: Jan Kara <jack@suse.cz>
Cc: tytso@mit.edu, linux-ext4@vger.kernel.org, adilger@dilger.ca,
	darrick.wong@oracle.com, hch@infradead.org,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-xfs@vger.kernel.org, willy@infradead.org,
	linux-unionfs@vger.kernel.org,
	syzbot+77fa5bdb65cc39711820@syzkaller.appspotmail.com
Subject: Re: [RFC 1/1] ext4: Fix overflow case for map.m_len in ext4_iomap_begin_*
Date: Thu, 16 Apr 2020 13:08:55 +0530	[thread overview]
Message-ID: <20200416073901.8A1E3A405F@b06wcsmtp001.portsmouth.uk.ibm.com> (raw)
In-Reply-To: <20200414155013.GF28226@quack2.suse.cz>


Sorry Jan and others. Please ignore this patch.
I will resend a proper one after making sure it is tested via syzbot.

On 4/14/20 9:20 PM, Jan Kara wrote:
> On Sun 12-04-20 14:54:35, Ritesh Harjani wrote:
>> EXT4_MAX_LOGICAL_BLOCK - map.m_lblk + 1 in case when
>> map.m_lblk (offset) is 0 could overflow an unsigned int
>> and become 0.
>>
>> Fix this.
>>
>> Signed-off-by: Ritesh Harjani <riteshh@linux.ibm.com>
>> Reported-by: syzbot+77fa5bdb65cc39711820@syzkaller.appspotmail.com
>> Fixes: d3b6f23f7167 ("ext4: move ext4_fiemap to use iomap framework")
> 
> The patch looks good to me. You can add:
> 
> Reviewed-by: Jan Kara <jack@suse.cz>
> 
> 								Honza
> 
>> ---
>>   fs/ext4/inode.c | 12 ++++++++++--
>>   1 file changed, 10 insertions(+), 2 deletions(-)
>>
>> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
>> index e416096fc081..d630ec7a9c8e 100644
>> --- a/fs/ext4/inode.c
>> +++ b/fs/ext4/inode.c
>> @@ -3424,6 +3424,7 @@ static int ext4_iomap_begin(struct inode *inode, loff_t offset, loff_t length,
>>   	int ret;
>>   	struct ext4_map_blocks map;
>>   	u8 blkbits = inode->i_blkbits;
>> +	loff_t len;
>>   
>>   	if ((offset >> blkbits) > EXT4_MAX_LOGICAL_BLOCK)
>>   		return -EINVAL;
>> @@ -3435,8 +3436,11 @@ static int ext4_iomap_begin(struct inode *inode, loff_t offset, loff_t length,
>>   	 * Calculate the first and last logical blocks respectively.
>>   	 */
>>   	map.m_lblk = offset >> blkbits;
>> -	map.m_len = min_t(loff_t, (offset + length - 1) >> blkbits,
>> +	len = min_t(loff_t, (offset + length - 1) >> blkbits,
>>   			  EXT4_MAX_LOGICAL_BLOCK) - map.m_lblk + 1;
>> +	if (len > EXT4_MAX_LOGICAL_BLOCK)
>> +		len = EXT4_MAX_LOGICAL_BLOCK;
>> +	map.m_len = len;
>>   
>>   	if (flags & IOMAP_WRITE)
>>   		ret = ext4_iomap_alloc(inode, &map, flags);
>> @@ -3524,6 +3528,7 @@ static int ext4_iomap_begin_report(struct inode *inode, loff_t offset,
>>   	bool delalloc = false;
>>   	struct ext4_map_blocks map;
>>   	u8 blkbits = inode->i_blkbits;
>> +	loff_t len
>>   
>>   	if ((offset >> blkbits) > EXT4_MAX_LOGICAL_BLOCK)
>>   		return -EINVAL;
>> @@ -3541,8 +3546,11 @@ static int ext4_iomap_begin_report(struct inode *inode, loff_t offset,
>>   	 * Calculate the first and last logical block respectively.
>>   	 */
>>   	map.m_lblk = offset >> blkbits;
>> -	map.m_len = min_t(loff_t, (offset + length - 1) >> blkbits,
>> +	len = min_t(loff_t, (offset + length - 1) >> blkbits,
>>   			  EXT4_MAX_LOGICAL_BLOCK) - map.m_lblk + 1;
>> +	if (len > EXT4_MAX_LOGICAL_BLOCK)
>> +		len = EXT4_MAX_LOGICAL_BLOCK;
>> +	map.m_len = len;
>>   
>>   	/*
>>   	 * Fiemap callers may call for offset beyond s_bitmap_maxbytes.
>> -- 
>> 2.21.0
>>


  reply	other threads:[~2020-04-16  7:39 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-11  7:39 WARNING in iomap_apply syzbot
2020-04-11 16:14 ` Matthew Wilcox
2020-04-12  9:17   ` Ritesh Harjani
2020-04-12  9:40     ` Amir Goldstein
2020-04-12  9:24 ` [RFC 1/1] ext4: Fix overflow case for map.m_len in ext4_iomap_begin_* Ritesh Harjani
2020-04-14 15:50   ` Jan Kara
2020-04-16  7:38     ` Ritesh Harjani [this message]
     [not found] ` <20200411092558.20856-1-hdanton@sina.com>
2020-04-12 16:12   ` WARNING in iomap_apply Darrick J. Wong

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=20200416073901.8A1E3A405F@b06wcsmtp001.portsmouth.uk.ibm.com \
    --to=riteshh@linux.ibm.com \
    --cc=adilger@dilger.ca \
    --cc=darrick.wong@oracle.com \
    --cc=hch@infradead.org \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=syzbot+77fa5bdb65cc39711820@syzkaller.appspotmail.com \
    --cc=tytso@mit.edu \
    --cc=willy@infradead.org \
    /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 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.