linux-kernel - Re: [PATCH][next] fs/ntfs3: Fix integer overflow in multiplication

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210816185921.kky77ctvb3dx6lq4@kari-VirtualBox>
Date:   Mon, 16 Aug 2021 21:59:21 +0300
From:   Kari Argillander <kari.argillander@...il.com>
To:     Colin King <colin.king@...onical.com>
Cc:     Konstantin Komarov <almaz.alexandrovich@...agon-software.com>,
        ntfs3@...ts.linux.dev, kernel-janitors@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH][next] fs/ntfs3: Fix integer overflow in multiplication

On Mon, Aug 16, 2021 at 05:30:25PM +0100, Colin King wrote:
> From: Colin Ian King <colin.king@...onical.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@...onical.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;