Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 8 Sep 2022 17:42:54 +0800
From:   Herbert Xu <herbert@gondor.apana.org.au>
To:     Dan Carpenter <dan.carpenter@oracle.com>
Cc:     George Cherian <gcherian@marvell.com>,
        "David S. Miller" <davem@davemloft.net>,
        David Daney <david.daney@cavium.com>,
        linux-crypto@vger.kernel.org, kernel-janitors@vger.kernel.org
Subject: Re: [PATCH] crypto: cavium - prevent integer overflow loading
 firmware
Message-ID: <Yxm5HrtXBiz6gKtv@gondor.apana.org.au>
References: <YxDQpc9IINUuUhQr@kili>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <YxDQpc9IINUuUhQr@kili>
Precedence: bulk

On Thu, Sep 01, 2022 at 06:32:53PM +0300, Dan Carpenter wrote:
>
> @@ -263,7 +264,13 @@ static int cpt_ucode_load_fw(struct cpt_device *cpt, const u8 *fw, bool is_ae)
>  	ucode = (struct ucode_header *)fw_entry->data;
>  	mcode = &cpt->mcode[cpt->next_mc_idx];
>  	memcpy(mcode->version, (u8 *)fw_entry->data, CPT_UCODE_VERSION_SZ);
> -	mcode->code_size = ntohl(ucode->code_length) * 2;
> +
> +	code_length = ntohl(ucode->code_length);
> +	if (code_length >= INT_MAX / 2) {
> +		ret = -EINVAL;
> +		goto fw_release;
> +	}
> +	mcode->code_size = code_length;

Where did the "* 2" go?

BTW, what is the threat model here? If the firmware metadata can't
be trusted, shouldn't we be capping the firmware size at a level
a lot lower than INT_MAX?

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt