Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp13052333rwd; Fri, 23 Jun 2023 15:03:07 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4YI2fby+FcZ+qf1pno8ej46XmNFv68psvhvFNH0RGjax8HEGj1NFzdFnxvkeXSk6pk2Rf9 X-Received: by 2002:a05:6808:4c2:b0:39c:717c:f4fb with SMTP id a2-20020a05680804c200b0039c717cf4fbmr16953422oie.11.1687557787581; Fri, 23 Jun 2023 15:03:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1687557787; cv=none; d=google.com; s=arc-20160816; b=yovqjMxyVx8/2ROh2cYqW6acX33uA20i4Ju+BpdIbLk6o+HxSUnPCai81oeb0ZqaTh DVlOnwyZPHiOEUEOLO8O7OIEHvo217INevAqMZ/4JFBLYS0oIrbyQ3od5RiCFXfsIfRl 42rPA1xxDYZQUM914Qbve/DGr1DJ7NipZGUG6mO11bgIPM/2xOh3nH5ulkW6QZrwD+Sa m4IFSkG7fyVDKTDkqomLkPDlr2aucwutHvlfY1kw8SscD2LBvXvUZLyPJvFSD43WN5LA 7vhc2W7XfLtnt2fcQ/+Zvz9kPsgJOKlNbeggHeAOaktoK2hCRch6GOtZvwvCRX0ZnzAD YJiA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:message-id :in-reply-to:subject:cc:to:from:date:dkim-signature; bh=CbwxMU596UN3SHXGFCDkR8oQ2050lXlWn2EuGniSkS4=; fh=RHihc7nlRLNybnKD9mTp9CNCsrkPCyDc3WEHppNro44=; b=gyGIQCjhYpF96ghx3vjZ5+7W5ST56lru19csDtI6ULALljCnuA2drYn7hr0vmeI1Ss mC5+7JLy3SisPFGzGMjOGM6B04DRqkDcv1FbEJKhCt7mtkgIDhN47Wbv3axwVXz9QjGW m0JRt/L+c3JnQd7HgA0eAlfv8X2Bd7cChkCfBJ5gMVzlpiFmpNWYOhVxJqwT7AsNwqZ3 D0z5YEpn7A10uCcbZnlk7E1ZoDiqvLn2P16mzMCV88hERWyFaFGFzuC4Fa3WAPSyRk60 tK048KGfswTw1x5r8YArHxw2FHAncICeXDQAtXz9hULFsL3tB+FzDRBlbeiNoSF/K7li jtGw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@inria.fr header.s=dc header.b=EnKI3Oer; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=inria.fr Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id h69-20020a638348000000b00553d074198fsi315631pge.137.2023.06.23.15.02.43; Fri, 23 Jun 2023 15:03:07 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@inria.fr header.s=dc header.b=EnKI3Oer; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=inria.fr Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232362AbjFWVpy (ORCPT + 99 others); Fri, 23 Jun 2023 17:45:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38754 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232267AbjFWVpw (ORCPT ); Fri, 23 Jun 2023 17:45:52 -0400 Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1645A2139; Fri, 23 Jun 2023 14:45:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inria.fr; s=dc; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=CbwxMU596UN3SHXGFCDkR8oQ2050lXlWn2EuGniSkS4=; b=EnKI3OerFqRJX9FzejlToSjLEGBQaFe4p1OYUsELEL5mz49EsMp7ZTrL 0rRfmNl38pAAant36AUp5WyAldBAMH9gGcou0pN731+QmBCeBJ/fMisKG BNkUQ/FAz38XkMpHuBvR/jzmTPPzMuBlAOAw+Tqm5JEM5IyQ7cUIrX8cT I=; Authentication-Results: mail3-relais-sop.national.inria.fr; dkim=none (message not signed) header.i=none; spf=SoftFail smtp.mailfrom=julia.lawall@inria.fr; dmarc=fail (p=none dis=none) d=inria.fr X-IronPort-AV: E=Sophos;i="6.01,153,1684792800"; d="scan'208";a="59686842" Received: from 231.85.89.92.rev.sfr.net (HELO hadrien) ([92.89.85.231]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Jun 2023 23:45:49 +0200 Date: Fri, 23 Jun 2023 23:45:48 +0200 (CEST) From: Julia Lawall X-X-Sender: jll@hadrien To: Jeffrey Hugo cc: Manivannan Sadhasivam , keescook@chromium.org, kernel-janitors@vger.kernel.org, mhi@lists.linux.dev, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 10/26] bus: mhi: host: use array_size In-Reply-To: <3b4ff79b-93b4-cf56-1488-113905b3981d@quicinc.com> Message-ID: References: <20230623211457.102544-1-Julia.Lawall@inria.fr> <20230623211457.102544-11-Julia.Lawall@inria.fr> <3b4ff79b-93b4-cf56-1488-113905b3981d@quicinc.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE, URIBL_BLOCKED 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: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 23 Jun 2023, Jeffrey Hugo wrote: > On 6/23/2023 3:14 PM, Julia Lawall wrote: > > Use array_size to protect against multiplication overflows. > > > > The changes were done using the following Coccinelle semantic patch: > > > > // > > @@ > > expression E1, E2; > > constant C1, C2; > > identifier alloc = {vmalloc,vzalloc}; > > @@ > > ( > > alloc(C1 * C2,...) > > | > > alloc( > > - (E1) * (E2) > > + array_size(E1, E2) > > ,...) > > ) > > // > > > > Signed-off-by: Julia Lawall > > > > --- > > drivers/bus/mhi/host/init.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/bus/mhi/host/init.c b/drivers/bus/mhi/host/init.c > > index f72fcb66f408..34a543a67068 100644 > > --- a/drivers/bus/mhi/host/init.c > > +++ b/drivers/bus/mhi/host/init.c > > @@ -759,8 +759,8 @@ static int parse_ch_cfg(struct mhi_controller > > *mhi_cntrl, > > * so to avoid any memory possible allocation failures, vzalloc is > > * used here > > */ > > - mhi_cntrl->mhi_chan = vzalloc(mhi_cntrl->max_chan * > > - sizeof(*mhi_cntrl->mhi_chan)); > > + mhi_cntrl->mhi_chan = vzalloc(array_size(mhi_cntrl->max_chan, > > + sizeof(*mhi_cntrl->mhi_chan))); > > if (!mhi_cntrl->mhi_chan) > > return -ENOMEM; > > > > > > This doesn't seem like a good fix. > > If we've overflowed the multiplication, I don't think we should continue, and > the function should return an error. array_size() is going to return > SIZE_MAX, and it looks like it is possible that vzalloc() may be able to > allocate that successfully in some scenarios. However, that is going to be > less memory than parse_ch_cfg() expected to allocate, so later on I expect the > function will still corrupt memory - basically the same result as what the > unchecked overflow would do. > > I'm not convinced the semantic patch is bringing value as I suspect most of > the code being patched is in the same situation. OK, this just brings the code in line with all the calls updated by Kees's original patch, cited in the cover letter, which were all the calls containing a multiplication that existed at the time. 42bc47b35320 ("treewide: Use array_size() in vmalloc()") fad953ce0b22 ("treewide: Use array_size() in vzalloc()") julia > > -Jeff >