LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Kari Argillander <kari.argillander@gmail.com>
To: Colin King <colin.king@canonical.com>
Cc: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>,
	ntfs3@lists.linux.dev, kernel-janitors@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH][next] fs/ntfs3: Fix integer overflow in multiplication
Date: Mon, 16 Aug 2021 21:59:21 +0300	[thread overview]
Message-ID: <20210816185921.kky77ctvb3dx6lq4@kari-VirtualBox> (raw)
In-Reply-To: <20210816163025.81770-1-colin.king@canonical.com>

On Mon, Aug 16, 2021 at 05:30:25PM +0100, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
> 
> The multiplication of the u32 data_size with a int is being performed
> using 32 bit arithmetic however the results is being assigned to the
> variable nbits that is a size_t (64 bit) value. Fix a potential
> integer overflow by casting the u32 value to a size_t before the
> multiply to use a size_t sized bit multiply operation.
> 
> Addresses-Coverity: ("Unintentional integer overflow")
> Fixes: 82cae269cfa9 ("fs/ntfs3: Add initialization of super block")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
>  fs/ntfs3/index.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/ntfs3/index.c b/fs/ntfs3/index.c
> index 6aa9540ece47..9386c551e208 100644
> --- a/fs/ntfs3/index.c
> +++ b/fs/ntfs3/index.c
> @@ -2012,7 +2012,7 @@ static int indx_shrink(struct ntfs_index *indx, struct ntfs_inode *ni,
>  		unsigned long pos;
>  		const unsigned long *bm = resident_data(b);
>  
> -		nbits = le32_to_cpu(b->res.data_size) * 8;
> +		nbits = (size_t)le32_to_cpu(b->res.data_size) * 8;

nbits is size_t because we might use b->nres.data_size in this function.
Usually nbits is only u32 in other places and also in those is *8. Those
will also overflow as much as this one. So this does not save our asses
if that kind of situation happend. So basically this does not fix
anything just some static analyzer can find it more easily than other
cases.

I'm still not nacking about it. If some static tool is happy by this
change then that might be good thing so that this will not be addressed
again. I also do not ack this. I did not fully review this so of course
there might be some fundemental problem with these *8 multiplications
but I doubt it.

>  
>  		if (bit >= nbits)
>  			return 0;


  reply	other threads:[~2021-08-16 18:59 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-16 16:30 Colin King
2021-08-16 18:59 ` Kari Argillander [this message]
2021-08-27 16:11 ` Konstantin Komarov

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=20210816185921.kky77ctvb3dx6lq4@kari-VirtualBox \
    --to=kari.argillander@gmail.com \
    --cc=almaz.alexandrovich@paragon-software.com \
    --cc=colin.king@canonical.com \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ntfs3@lists.linux.dev \
    --subject='Re: [PATCH][next] fs/ntfs3: Fix integer overflow in multiplication' \
    /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

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).