Received: by 2002:a05:6358:11c7:b0:104:8066:f915 with SMTP id i7csp1720499rwl; Thu, 30 Mar 2023 00:06:30 -0700 (PDT) X-Google-Smtp-Source: AKy350b6UobIoqEHfoR+KvTq7Eri+K6/OkyfeNqCBPNZLAuSrg1fJJYLiuFQkAgqIa/TjLJPULtL X-Received: by 2002:a17:902:7c0d:b0:1a0:7663:731b with SMTP id x13-20020a1709027c0d00b001a07663731bmr18960370pll.5.1680159990000; Thu, 30 Mar 2023 00:06:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680159989; cv=none; d=google.com; s=arc-20160816; b=w761UbORUZJ5wJ3f8uB/RM+iluxIpch4tnARPYuOg8u4gqygHTpItMUrHuQpIzsDKj JDWM4o2YBxFYc3H4AKE64Lq3g4KNi6KYZ7s4lY9GXWaNK+rUS9FDh72psSwYl0eyXXwq 4AjiFKaVObQ90aCeD88t87lYrHOpAYuhb46LHztkvu4IrGAfW7MY4iX0y4GzlINZNJLK EPyyKrUgIXRR2LV2uqCmPq1B0dI4XuryiFbPIdwZ6yK0UTpufXhUgFzB9DOlFNNjzHzK T9pj/qdUEaV+MhCaXsoe/VYMEnuDwV8cJnyqAq5hQ7X2av/2VU1uVqIqITXCkWc36vW+ 9x/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=RyIYnJuq5yMJf3v3Oig5isTATpTBNSb4ESQWGpuX73s=; b=bJl4FSuFajbOUevRCw/dmDPoUw8XpjQfQCWJT89BOfrXEe36g2OePtV1vBaBD8Q3UK uRALX2sT2nFGBCLnalbxGx8YcukMePtBI7BVhPgrNW/q3dsacUWXZ55o0am2BQ00jDY2 QtG1fqAee2XcijjqOgMMV8wDinK4dWoFO9ArWkC3Yq5PcEBbKHPLufhXviA3SkB+QlkS JJ1fRChnnWS0u437F8gT8Mys23FNSzD5wL3XRXwFGLDJhUpYHgS0lVlZCQC/DpXbxJIq 6AxrDGbGRCINBe+FMSn2ClwiYiqYSxF0eN1FENT1lxEkwYqFHZ9JJvgsv1Hb4EJML2VC GOBA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=RbIfwNUY; 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=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id n13-20020a170903110d00b001a27afc07efsi110437plh.367.2023.03.30.00.06.17; Thu, 30 Mar 2023 00:06:29 -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=@kernel.org header.s=k20201202 header.b=RbIfwNUY; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229690AbjC3HB3 (ORCPT + 99 others); Thu, 30 Mar 2023 03:01:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52600 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229486AbjC3HB2 (ORCPT ); Thu, 30 Mar 2023 03:01:28 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7C0721FE2; Thu, 30 Mar 2023 00:01:27 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 1BBEF61F0E; Thu, 30 Mar 2023 07:01:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 78482C433EF; Thu, 30 Mar 2023 07:01:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1680159686; bh=H3toqFQVNcpuGUTVQatxSq9QUFu7uhOw9AGmIacnjMA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=RbIfwNUYo6lNqcJnUmsRHqjAeehV12pNlEYbDi4Cu1UYYibz0ZSoqLAXT3AA8fpJI hbSxynNc2t0S8Fmqbdg951w0p8NeQX8DjcZRiBWMbV66HyCLOL9BWUquWB07w9cDS3 8bK9seUy7ecfj152HB8nBW5OVSrOZ9s6QqHFiiKqNT+7OFs2VnpoBeUGGrbJeX3pRO MSJJiwnRP+KJMzpAqD6vdrivZuv5kUIcyvzoLhGw0q2h6raXKXsQOE1fvO208rNHkA b7k0hf4Yxf9+U9YBPhDQtEceMFPlYXw1Bofp+9IdQSTVmI7JxW6D931MM7jQ4O/QPW xK+mibakT364A== Date: Thu, 30 Mar 2023 15:01:23 +0800 From: Tzung-Bi Shih To: "Gustavo A. R. Silva" Cc: Benson Leung , Guenter Roeck , chrome-platform@lists.linux.dev, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org Subject: Re: [PATCH][next] platform/chrome: Fix -Warray-bounds warnings Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-5.2 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI,SPF_HELO_NONE, SPF_PASS autolearn=unavailable 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 Wed, Mar 29, 2023 at 07:54:02PM -0600, Gustavo A. R. Silva wrote: > In this case, as only enough space for the op field is allocated, > we can use an object of type uint32_t instead of a whole > struct ec_params_vbnvcontext (for which not enough memory is > allocated). It doesn't make sense to me. See comments below. > Fix the following warning seen under GCC 13: > drivers/platform/chrome/cros_ec_vbc.c: In function ‘vboot_context_read’: > drivers/platform/chrome/cros_ec_vbc.c:36:15: warning: array subscript ‘struct ec_params_vbnvcontext[1]’ is partly outside array bounds of ‘unsigned char[36]’ [-Warray-bounds=] > 36 | params->op = EC_VBNV_CONTEXT_OP_READ; > | ^~ > In file included from drivers/platform/chrome/cros_ec_vbc.c:12: > In function ‘kmalloc’, > inlined from ‘vboot_context_read’ at drivers/platform/chrome/cros_ec_vbc.c:30:8: > ./include/linux/slab.h:580:24: note: at offset 20 into object of size 36 allocated by ‘kmalloc_trace’ > 580 | return kmalloc_trace( > | ^~~~~~~~~~~~~~ > 581 | kmalloc_caches[kmalloc_type(flags)][index], > | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 582 | flags, size); > | ~~~~~~~~~~~~ Please trim the commit message a bit and try to wrap at 75 columns as [1] suggested. [1]: https://www.kernel.org/doc/html/latest/process/submitting-patches.html#the-canonical-patch-format > @@ -20,10 +20,14 @@ static ssize_t vboot_context_read(struct file *filp, struct kobject *kobj, > struct device *dev = kobj_to_dev(kobj); > struct cros_ec_dev *ec = to_cros_ec_dev(dev); > struct cros_ec_device *ecdev = ec->ec_dev; > - struct ec_params_vbnvcontext *params; > struct cros_ec_command *msg; > + /* > + * This should be a pointer to the same type as op field in > + * struct ec_params_vbnvcontext. > + */ > + uint32_t *params_op; > int err; > - const size_t para_sz = sizeof(params->op); > + const size_t para_sz = sizeof(*params_op); > const size_t resp_sz = sizeof(struct ec_response_vbnvcontext); > const size_t payload = max(para_sz, resp_sz); > > @@ -32,8 +36,8 @@ static ssize_t vboot_context_read(struct file *filp, struct kobject *kobj, > return -ENOMEM; > > /* NB: we only kmalloc()ated enough space for the op field */ > - params = (struct ec_params_vbnvcontext *)msg->data; > - params->op = EC_VBNV_CONTEXT_OP_READ; > + params_op = (uint32_t *)msg->data; > + *params_op = EC_VBNV_CONTEXT_OP_READ; I don't see a good reason to partially allocate memory here. Perhaps, just let `para_sz = sizeof(struct ec_params_vbnvcontext)`? If it also makes sense to you, please remove the comment "NB: we only..." as well.