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, 13 Oct 2022 17:44:44 +0300
From:   Dan Carpenter <dan.carpenter@oracle.com>
To:     Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Cc:     George Cherian <gcherian@marvell.com>,
        Herbert Xu <herbert@gondor.apana.org.au>,
        "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 v2] crypto: cavium - prevent integer overflow loading
 firmware
Message-ID: <Y0gkXAkIjeoAkQJ/@kadam>
References: <YygPj8aYTvApOQFB@kili>
 <cecca972-33c8-03a9-d632-c85ed06dff8b@wanadoo.fr>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <cecca972-33c8-03a9-d632-c85ed06dff8b@wanadoo.fr>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?K3RunRNj+GqY/NZAncwqryYSef8jZ/f/PZAWkIE/PtMzhcQFoWcImkF6amcY?=
 =?us-ascii?Q?ZwsXf4N21gliaV+p+Bl97Uu6hFF3sgSubjte0Xbwfkf/vUSRreDh40piN9jm?=
 =?us-ascii?Q?ZA4Has/+gy/uTyvf8BWKRfII8JQuXIG383ctJHd3nlTQFkOzK4C7mg9/3e4d?=
 =?us-ascii?Q?NSmJlfZS6DUD4mfkDeOJgM3YnGhKjSXi8yxtmu1AgMuvCm66DAT2buwwWhWL?=
 =?us-ascii?Q?w2vlUKZaKfoPYBurMXXqNWlB1TEADQQ5R2gTb+A9PMfNDc8Egt3mtq+yzMZn?=
 =?us-ascii?Q?YmSMzwYBzOLxIWl+f8Y8MlJGdFRiCaAiWZsw1wSDJLZaKJIKNyWVo/5VOaIZ?=
 =?us-ascii?Q?uL5N+sHTlJDrAy2GYz8SXhO+tl0NItiput25OIJ39w26bmICZLPzF8SFh/wn?=
 =?us-ascii?Q?iBNFs5rVe6XVDQclAn+kC0FWgVe7kEYQ9UWn05tZGw0ZItdLkSyTa81mWyUx?=
 =?us-ascii?Q?BRLc7PVbc4Z2lIxZfhwGYPkRibngz2uoAzxpsTRVOWsJtbSbnDvxtJ7zy1Bs?=
 =?us-ascii?Q?3n01lgQFDzRn83PTVG9Jr33mOut7O86mGAPtvIMIMJcpE00om6hxaOEET7kf?=
 =?us-ascii?Q?QOBkwdYC65A7aDq7k1Rwoeavq6ZjsXxjc06UarqjwD15us9S/kN0MCFSmszg?=
 =?us-ascii?Q?oPRJvpEX784veMuctWcLWEZ6OeUl3YaFUhBpJhREI+o6zWS5/b07n2J0eYSM?=
 =?us-ascii?Q?RPuzuOeHnWhmKtt0ypehkEGkz/YePEpwkihvl59iI+281TFKiy6IjlxhGEfU?=
 =?us-ascii?Q?bph+Rw+Tmx1KjI34u6O9Aajq7N+KXR9cY4BHF+fyw2V2pgJrt8hkblKWCWHr?=
 =?us-ascii?Q?qf7yCWmMVecXUygfikEK8oj295qm2/i/2Nn6oZXBdmhiEvQnQF1zt1Fa3clP?=
 =?us-ascii?Q?ymB1YDMhYBj5jBLZO8M+K0IBME9jYW4x47NWXAxJqvd5gUQycNlrPsCnkSo7?=
 =?us-ascii?Q?iQxFvGCkGvHBphMZfsLnJwdd8Zspx0AE7fkbfjchSfUY4b0B7PPFGeKV87vW?=
 =?us-ascii?Q?qb3Pn+LBBCxRZ0xOeIDS9qW/mZuA7PDOP+wwE9VhC4kzVKBzzKG78NGJ5xvM?=
 =?us-ascii?Q?ZNrw2vXctJj1xcQL4qgpodJg2ZEJmTIjWpKwFEQ1MHlJNJO7iQ05O3T+OHo8?=
 =?us-ascii?Q?Ganogm27O9WG8gzgcvr8tpmR8xT/+WF5lCydyYy6PJfNatL8SHgOJqfll8pE?=
 =?us-ascii?Q?JEPLxk8JKkPKdXfdJw+hezO0o7AIX+0rW8Tb87yHRrnXzQHPh80JVLCY20fa?=
 =?us-ascii?Q?Ueqyohr4egwBM/nP/OU/CCv8MVPUgMs1RzCIzsi8Xs6Ti+yWPIVOqb3tWka2?=
 =?us-ascii?Q?OpWsLjC8VQ+Y1SpeptEVlZBrO/+E/7jbPA2O0s09MQISAv9RM8I884y4NzDI?=
 =?us-ascii?Q?GFWjhBCNczrthcXzdyAjAhhzL8XLiDgGhkuFJOfSoHcCwsUvyOmZB/EpX7Iz?=
 =?us-ascii?Q?fT7BBgq8R5dAYMrCG9ge9AAezpuNM1S1SGlZX6kpIqQat1Iny2yqX8LSmV+X?=
 =?us-ascii?Q?Uz6X5eXd7w8wEHGHnVg/j1ZsTCKh9aE1F5HXewt/C2goIz3MYTzs0GBg0quJ?=
 =?us-ascii?Q?luQ4BwtLU9HfBC5wJ6CEzhftwbbyWY/BiuD/L0JYQ8C5Fr2WRngOVORfFQpC?=
 =?us-ascii?Q?Fw=3D=3D?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9b01259d-2ec6-458e-d7c4-08daad2986a4
X-MS-Exchange-CrossTenant-AuthSource: MWHPR1001MB2365.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Oct 2022 14:45:09.8529
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: eykLabLdLo7wGTO+eiP3jFkX3TpH6TBS2YQIEIAlDT1BgIg56Ymw/GeC1U01U11+gyrN4uJPC+kvdV+hlGOokKSoxDyMwy1ZUGcn1uv0uBc=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA0PR10MB6721
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.545,FMLib:17.11.122.1
 definitions=2022-10-13_08,2022-10-13_01,2022-06-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 suspectscore=0
 phishscore=0 mlxscore=0 malwarescore=0 spamscore=0 mlxlogscore=999
 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2209130000 definitions=main-2210130086
X-Proofpoint-GUID: nf2QE93IWYVoAZ-RGvquFYslnUl-8xxv
X-Proofpoint-ORIG-GUID: nf2QE93IWYVoAZ-RGvquFYslnUl-8xxv
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,
        RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-crypto.vger.kernel.org>
X-Mailing-List: linux-crypto@vger.kernel.org

On Fri, Sep 30, 2022 at 06:32:53PM +0200, Christophe JAILLET wrote:
> Le 19/09/2022 ? 08:43, Dan Carpenter a ?crit?:
> > The "code_length" value comes from the firmware file.  If your firmware
> > is untrusted realistically there is probably very little you can do to
> > protect yourself.  Still we try to limit the damage as much as possible.
> > Also Smatch marks any data read from the filesystem as untrusted and
> > prints warnings if it not capped correctly.
> > 
> > The "ntohl(ucode->code_length) * 2" multiplication can have an
> > integer overflow.
> > 
> > Fixes: 9e2c7d99941d ("crypto: cavium - Add Support for Octeon-tx CPT Engine")
> > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> > ---
> > v2: The first code removed the " * 2" so it would have caused immediate
> >      memory corruption and crashes.
> > 
> >      Also in version 2 I combine the "if (!mcode->code_size) {" check
> >      with the overflow check for better readability.
> > 
> >   drivers/crypto/cavium/cpt/cptpf_main.c | 6 ++++--
> >   1 file changed, 4 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/crypto/cavium/cpt/cptpf_main.c b/drivers/crypto/cavium/cpt/cptpf_main.c
> > index 8c32d0eb8fcf..6872ac344001 100644
> > --- a/drivers/crypto/cavium/cpt/cptpf_main.c
> > +++ b/drivers/crypto/cavium/cpt/cptpf_main.c
> > @@ -253,6 +253,7 @@ static int cpt_ucode_load_fw(struct cpt_device *cpt, const u8 *fw, bool is_ae)
> >   	const struct firmware *fw_entry;
> >   	struct device *dev = &cpt->pdev->dev;
> >   	struct ucode_header *ucode;
> > +	unsigned int code_length;
> >   	struct microcode *mcode;
> >   	int j, ret = 0;
> > @@ -263,11 +264,12 @@ 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;
> > -	if (!mcode->code_size) {
> > +	code_length = ntohl(ucode->code_length);
> > +	if (code_length == 0 || code_length >= INT_MAX / 2) {
> 
> Hi,
> 
> out of curiosity,
> 
> 'code_length' is 'unsigned int'
> 'mcode->code_size' is u32.
> 
> Why not UINT_MAX / 2?

Sorry for not responding earlier.  UINT_MAX / 2 would have worked here.

There was a similar issue in ucode_load() and in that code if you wanted
to use UINT_MAX then you would have had to write something like:

	if (code_length >= (UINT_MAX - 16) / 2)

That is sort of 9th grade algebra level of complicated.  But I've messed
it up basic algebra before and I've seen other people mess up their
integer overflow tests as well.

So I decided it was easier to just use INT_MAX / 2 consistently
everywhere.  The real values are not going to be anywhere near that
high so it doesn't affect runtime at all.

Also while I was writing this patch back in September, I saw someone
had changed one of INT_MAX checks to UINT_MAX.  For no reason at all.
It doesn't affect runtime.  They didn't tell me at all.  I was
unspeakably annoyed and I vowed to hold a grudge about this for all
time.  But unfortunately I forgotten the details so they're essentially
forgiven at this point...

regards,
dan carpenter