Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp912860pxf; Wed, 7 Apr 2021 14:54:56 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzNat4hJyul6C1T4ROz1HDPyuoYtNwp0kczKqIIVHWL15G5rVHCt6f3IOuANkPBGjNp5yU9 X-Received: by 2002:a65:5584:: with SMTP id j4mr5223855pgs.356.1617832496823; Wed, 07 Apr 2021 14:54:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617832496; cv=none; d=google.com; s=arc-20160816; b=PcRDaBOvTQA6ncR93VzqpcXhMpi9XBqQEcqklacXAjnLH/aeyCOtHuXqxOZM39LMQU mDJCKOajnHAxUFhZGrPU1Bnbep4FWjdvJ1xY4EjDgEYj1to2Onk49PgSO4SXhnK7Nfmd pEVPKUd36SvWuAK3sZ6T2hCOvNZVVU3n+mq92OoFVQYJCfpNtqUa08vWL1xzAl5wR2v+ VhGBIsJGfzQcKFz+DCoT2kv05PB4OcUAIHlfsfmGKdX7gBmlSsUK5swe16MpT+N5vmEn cH3mv7nuoHJmpdPXbn/LC0r1p5FjZSgyEMS5rhj296Q3nbRuHDhKKptE5N6i1XNLeplp H/Zg== 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-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=bUFX8OZjFldaYb/6zcLiSui0pTc7lp3Q3DWh7esaF8g=; b=mCCcB4sP6HP/0jE+Cbit7IMBMIoELgB8wZh3GBW6brDhTFZazg71Xg6/DFqZ90Ss6I +AF/qncR4oDaO55dwCtnS5x4Fg/+Htxcm3Z4XIfdOuW2LxqBOPR7h3lpC3EtxvUh1h78 OXNonBdL8zDoJQ4vTlAeaDcIKQq6dvOz+PQh/ZygmA3DmFYjmE861PN0AiTNEsM3EuXl LSQGGWWUXiV5Yc6rCQ2Yv2p2tuOKe8FzOe3tVgrlcpHsF6I+qGhXvIGg8GHAUKkFcoo5 3Ba4iivADcKSQcl2HhIYmEr7P47xQfoy1gHLhDWZT4qXxZWudyKw5lngNotH/iQAhh3p g01g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=a1xRCOql; 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=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n4si3479218pgs.427.2021.04.07.14.54.45; Wed, 07 Apr 2021 14:54:56 -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; dkim=pass header.i=@chromium.org header.s=google header.b=a1xRCOql; 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=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1355475AbhDGS4T (ORCPT + 99 others); Wed, 7 Apr 2021 14:56:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50542 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1355469AbhDGS4S (ORCPT ); Wed, 7 Apr 2021 14:56:18 -0400 Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4B843C061760 for ; Wed, 7 Apr 2021 11:56:08 -0700 (PDT) Received: by mail-pl1-x635.google.com with SMTP id c5so254513plg.1 for ; Wed, 07 Apr 2021 11:56:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=bUFX8OZjFldaYb/6zcLiSui0pTc7lp3Q3DWh7esaF8g=; b=a1xRCOqlDFc7fMaWuNejJHG4Uwf7By9zy2OKAtPQ27xGklMzMvChcENop0/v+mOMEx MW6+86rti2fEGc6b+oX4cnfwPSqf7GbCQ41o+BKscycaOnSgArho8f9BO6FrTo4gYnow aM5rfU2N378Fjx1Amj6OkdpP5/Dtb0+r7QDOA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=bUFX8OZjFldaYb/6zcLiSui0pTc7lp3Q3DWh7esaF8g=; b=R3Z87ksw8E7SoayNjW4RZK81rn35j+d/mxnppUqb1m5Ca2dhHOzmPUNINkK19vQTOO feS+ra9GYKu5ZpWKU5wf78i3SHbHfEA/9ngaZJ9GTbS5JXKaADl+OFfWePn7UX1jMXpP LOdKTq6CDBHeQjsPQv8hT1Ha1OoPDj9EfocZrTziI2i92r0w1xM65Jz9nC+UwUIDLypX 9lf0GflPTsAQ9UNWc2Zyk75ezR8Yi3rqmwJB8ULH4BrouA+lozgx5OF5f0/6Ku96IhCx IkLp8dlr7r0NR1+JPOx6FHLN1hecVcAGuQqpy+E0zMi13sntygsxKnuV8JZ5uWH5WUWr FrRQ== X-Gm-Message-State: AOAM533LxZvhTeBlOhXeYgemtwFl7ndqOpRiAre9bRY4RXZXGxnL9S1E +BMYtkvjXiU/8fpzX6R4lmXvuA== X-Received: by 2002:a17:90a:a389:: with SMTP id x9mr3803993pjp.232.1617821767869; Wed, 07 Apr 2021 11:56:07 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id h19sm22438097pfc.172.2021.04.07.11.56.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Apr 2021 11:56:07 -0700 (PDT) Date: Wed, 7 Apr 2021 11:56:06 -0700 From: Kees Cook To: "Gustavo A. R. Silva" Cc: linux-kernel@vger.kernel.org, Kalle Valo , "David S. Miller" , Jakub Kicinski , linux-wireless@vger.kernel.org, netdev@vger.kernel.org, linux-hardening@vger.kernel.org Subject: Re: [PATCH v2 1/2][next] wl3501_cs: Fix out-of-bounds warning in wl3501_send_pkt Message-ID: <202104071154.49B15A3AB4@keescook> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 31, 2021 at 04:44:29PM -0500, Gustavo A. R. Silva wrote: > Fix the following out-of-bounds warning by enclosing > structure members daddr and saddr into new struct addr: > > arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [18, 23] from the object at 'sig' is out of the bounds of referenced subobject 'daddr' with type 'u8[6]' {aka 'unsigned char[6]'} at offset 11 [-Warray-bounds] > > Refactor the code, accordingly: > > $ pahole -C wl3501_md_req drivers/net/wireless/wl3501_cs.o > struct wl3501_md_req { > u16 next_blk; /* 0 2 */ > u8 sig_id; /* 2 1 */ > u8 routing; /* 3 1 */ > u16 data; /* 4 2 */ > u16 size; /* 6 2 */ > u8 pri; /* 8 1 */ > u8 service_class; /* 9 1 */ > struct { > u8 daddr[6]; /* 10 6 */ > u8 saddr[6]; /* 16 6 */ > } addr; /* 10 12 */ > > /* size: 22, cachelines: 1, members: 8 */ > /* last cacheline: 22 bytes */ > }; > > The problem is that the original code is trying to copy data into a > couple of arrays adjacent to each other in a single call to memcpy(). > Now that a new struct _addr_ enclosing those two adjacent arrays > is introduced, memcpy() doesn't overrun the length of &sig.daddr[0], > because the address of the new struct object _addr_ is used as > destination, instead. > > Also, this helps with the ongoing efforts to enable -Warray-bounds and > avoid confusing the compiler. > > Link: https://github.com/KSPP/linux/issues/109 > Reported-by: kernel test robot > Build-tested-by: kernel test robot > Link: https://lore.kernel.org/lkml/60641d9b.2eNLedOGSdcSoAV2%25lkp@intel.com/ > Signed-off-by: Gustavo A. R. Silva Thanks, this makes the code much easier for the compiler to validate at compile time. These cross-field memcpy()s are weird. I like the solution here. Reviewed-by: Kees Cook -- Kees Cook