From: Tao Ma <tm@tao.ma>
To: Lukas Czerner <lczerner@redhat.com>
Cc: linux-ext4@vger.kernel.org, tytso@mit.edu
Subject: Re: [PATCH] ext4: fix possible overflow in ext4_trim_fs()
Date: Tue, 06 Sep 2011 12:15:45 +0800 [thread overview]
Message-ID: <4E659E71.7050008@tao.ma> (raw)
In-Reply-To: <1315233249-27167-1-git-send-email-lczerner@redhat.com>
Hi Lucas,
On 09/05/2011 10:34 PM, Lukas Czerner wrote:
> In ext4_trim_fs it is possible that start+len might overflow. Fix it by
> decrementing the len so that start+len equals to the file system size in
> the worst case.
Actually start + len can never overflow since they are changed by
start = range->start >> sb->s_blocksize_bits;
len = range->len >> sb->s_blocksize_bits;
range->start and range->len are u64, and after they are shifted with
blocksize_bits, start+len(ext4_fsblk_t is also 64bit) can't overflow.
Thanks
Tao
>
> Signed-off-by: Lukas Czerner <lczerner@redhat.com>
> ---
> fs/ext4/mballoc.c | 6 +++++-
> 1 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
> index 17a5a57..d86dc14 100644
> --- a/fs/ext4/mballoc.c
> +++ b/fs/ext4/mballoc.c
> @@ -4952,14 +4952,18 @@ int ext4_trim_fs(struct super_block *sb, struct fstrim_range *range)
> uint64_t start, len, minlen, trimmed = 0;
> ext4_fsblk_t first_data_blk =
> le32_to_cpu(EXT4_SB(sb)->s_es->s_first_data_block);
> + ext4_fsblk_t max_blks = ext4_blocks_count(EXT4_SB(sb)->s_es);
> int ret = 0;
>
> start = range->start >> sb->s_blocksize_bits;
> len = range->len >> sb->s_blocksize_bits;
> minlen = range->minlen >> sb->s_blocksize_bits;
>
> - if (unlikely(minlen > EXT4_BLOCKS_PER_GROUP(sb)))
> + if (unlikely(minlen > EXT4_BLOCKS_PER_GROUP(sb)) ||
> + unlikely(start > max_blks))
> return -EINVAL;
> + if (unlikely(len > max_blks))
> + len = max_blks - start;
> if (start + len <= first_data_blk)
> goto out;
> if (start < first_data_blk) {
next prev parent reply other threads:[~2011-09-06 4:15 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-05 14:34 [PATCH] ext4: fix possible overflow in ext4_trim_fs() Lukas Czerner
2011-09-06 4:15 ` Tao Ma [this message]
2011-09-06 6:26 ` Lukas Czerner
[not found] <alpine.LFD.2.00.1101101221570.3095@dhcp-lab-213.englab.brq.redhat.com>
2011-01-10 11:28 ` Lukas Czerner
-- strict thread matches above, loose matches on Subject: below --
2010-11-25 15:53 Lukas Czerner
2011-01-03 11:02 ` Lukas Czerner
2011-01-03 11:09 ` Lukas Czerner
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=4E659E71.7050008@tao.ma \
--to=tm@tao.ma \
--cc=lczerner@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/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;
as well as URLs for NNTP newsgroup(s).