Received: by 2002:a05:6a10:c604:0:0:0:0 with SMTP id y4csp3716850pxt; Tue, 10 Aug 2021 09:42:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzlZxpI3CsQs+TEudxku292n/dHviwHQ8yP2/voCaXbsGnr8dpZaIJvVeiDLwRy7rspn0vo X-Received: by 2002:a02:350a:: with SMTP id k10mr28459479jaa.55.1628613723523; Tue, 10 Aug 2021 09:42:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1628613723; cv=none; d=google.com; s=arc-20160816; b=JvRtYQ8BkQAsMC3tc0RWEVzVdsv2xF8Y/nuzXkBmLxjJWNZCdv3/s++ZYmIzwElaxz ZRtJ02khm4bYcB+TtiLSooerFimXaokVAsBxv5n/YKsb+O7U2wiSfVN+bWlA05h+QXFA QPSqsfmBPr8mk2s9MV14OgIOe8jc8C2TLQNpymxeyMKakJ3iBOL8KCzJYjrbiWDpuzuo BBprTbxN5wZfhUV9La8vk2R2I4RH07IFUj2DoVR40W/GhkjGVGdRHnMNRuZwVE7OvJqn M0qPyaP+b82jytKlt9nqrV9v9wAlIFdKw0h8oVySELGx+/qSeDznW8larkwihRPvxb4D C9Kg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=eQOMynadAsmJIjF1yZdFbzSXfDpwipkwsRUxCfa6mGM=; b=p1AYztzKyyo6s7ftakwW65vphlOLmF6yDImLOnPQsIYWmsYBFHhHokQDCBHnboW9h8 bO6wrSKE6224klxjnheDjkE3iDVOd4JZ/OHLPHTiH4BX8+IOrix28ZGKt3uYCCCx9ua1 5cYhij/z1IDF8h8rZeMwg8yJs1j+9vQSvlnfDHskuoypx6vx8yQWRIPItaG2Vf/xMq6o VhkxxPWV6sHRVhch3kY0GTdeS+TxjSnAqM5tDH9Q7JM+vYTAMqG4uLwPEpea71z+KSFD gSK3fKHzK2DHHmS5u6jgOP5qhiljQmV8ovfLi7lhRfnhfKOoXRPYPDtGSh9cY31VBrXg ZKkg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b16si19600585ior.73.2021.08.10.09.41.52; Tue, 10 Aug 2021 09:42:03 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242154AbhHJPTa (ORCPT + 99 others); Tue, 10 Aug 2021 11:19:30 -0400 Received: from mga01.intel.com ([192.55.52.88]:17625 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242914AbhHJPTU (ORCPT ); Tue, 10 Aug 2021 11:19:20 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10072"; a="236937112" X-IronPort-AV: E=Sophos;i="5.84,310,1620716400"; d="scan'208";a="236937112" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Aug 2021 08:18:58 -0700 X-IronPort-AV: E=Sophos;i="5.84,310,1620716400"; d="scan'208";a="671802800" Received: from paasikivi.fi.intel.com ([10.237.72.42]) by fmsmga006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Aug 2021 08:18:55 -0700 Received: from paasikivi.fi.intel.com (localhost [127.0.0.1]) by paasikivi.fi.intel.com (Postfix) with SMTP id 14C6B20345; Tue, 10 Aug 2021 18:18:53 +0300 (EEST) Date: Tue, 10 Aug 2021 18:18:53 +0300 From: Sakari Ailus To: "Gustavo A. R. Silva" Cc: "Gustavo A. R. Silva" , linux-kernel@vger.kernel.org, Yong Zhi , Bingbu Cao , Tianshu Qiu , Mauro Carvalho Chehab , Greg Kroah-Hartman , linux-media@vger.kernel.org, linux-staging@lists.linux.dev, linux-hardening@vger.kernel.org, Dan Carpenter Subject: Re: [PATCH v2 1/2] media: staging/intel-ipu3: css: Fix wrong size comparison Message-ID: <20210810151852.GI3@paasikivi.fi.intel.com> References: <184d96f95d6261b1a91704eb68adbd0a2e1c2cc2.1627646101.git.gustavoars@kernel.org> <20210802060546.GL3@paasikivi.fi.intel.com> <3c9ac43d-09ca-e5d5-83a8-7b6d23928763@embeddedor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3c9ac43d-09ca-e5d5-83a8-7b6d23928763@embeddedor.com> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Gustavo, Apologies for the delay. On Mon, Aug 02, 2021 at 08:46:20AM -0500, Gustavo A. R. Silva wrote: > Hi Sakari, > > On 8/2/21 01:05, Sakari Ailus wrote: > > Hi Gustavo, > > > > I missed you already had sent v2... > > > > On Fri, Jul 30, 2021 at 07:08:13AM -0500, Gustavo A. R. Silva wrote: > >> There is a wrong comparison of the total size of the loaded firmware > >> css->fw->size with the size of a pointer to struct imgu_fw_header. > >> > >> Fix this by using the right operand 'struct imgu_fw_header' for > >> sizeof, instead of 'struct imgu_fw_header *' and turn binary_header > >> into a flexible-array member. Also, adjust the relational operator > >> to be '<=' instead of '<', as it seems that the intention of the > >> comparison is to determine if the loaded firmware contains any > >> 'struct imgu_fw_info' items in the binary_header[] array than merely > >> the file_header (struct imgu_fw_bi_file_h). > >> > >> The replacement of the one-element array with a flexible-array member > >> also help with the ongoing efforts to globally enable -Warray-bounds > >> and get us closer to being able to tighten the FORTIFY_SOURCE routines > >> on memcpy(). > >> > >> Link: https://github.com/KSPP/linux/issues/79 > >> Link: https://github.com/KSPP/linux/issues/109 > >> Fixes: 09d290f0ba21 ("media: staging/intel-ipu3: css: Add support for firmware management") > >> Cc: stable@vger.kernel.org > >> Signed-off-by: Gustavo A. R. Silva > >> --- > >> > >> It'd be just great if someone that knows this code better can confirm > >> these changes are correct. In particular the adjustment of the > >> relational operator. Thanks! > >> > >> Changes in v2: > >> - Use flexible array and adjust relational operator, accordingly. > > > > The operator was just correct. The check is just there to see the firmware > > is at least as large as the struct as which it is being accessed. > > I'm a bit confused, so based on your reply to v1 of this series, this patch > is now correct, right? > > The operator in v1 _was_ correct as long as the one-element array wasn't > transformed into a flexible array, right? > > Notice that generally speaking flexible-array members don't occupy space in the > containing structure: > > $ pahole -C imgu_fw_header drivers/staging/media/ipu3/ipu3-css-fw.o > struct imgu_fw_header { > struct imgu_fw_bi_file_h file_header; /* 0 72 */ > /* --- cacheline 1 boundary (64 bytes) was 8 bytes ago --- */ > struct imgu_fw_info binary_header[] __attribute__((__aligned__(8))); /* 72 0 */ > > /* size: 72, cachelines: 2, members: 2 */ > /* forced alignments: 1 */ > /* last cacheline: 8 bytes */ > } __attribute__((__aligned__(8))); > > $ pahole -C imgu_fw_header drivers/staging/media/ipu3/ipu3-css-fw.o > struct imgu_fw_header { > struct imgu_fw_bi_file_h file_header; /* 0 72 */ > /* --- cacheline 1 boundary (64 bytes) was 8 bytes ago --- */ > struct imgu_fw_info binary_header[1] __attribute__((__aligned__(8))); /* 72 1200 */ > > /* size: 1272, cachelines: 20, members: 2 */ > /* forced alignments: 1 */ > /* last cacheline: 56 bytes */ > } __attribute__((__aligned__(8))); > > So, now that the flexible array transformation is included in the same patch as the > bugfix, the operator is changed from '<' to '<=' '<' is correct since you only need as much data as the struct you're about to access is large, not a byte more than that. As Dan noted. I think you could add a check for binary_nr is at least one. -- Kind regards, Sakari Ailus