From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-14.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 94751C433E0 for ; Thu, 4 Jun 2020 20:25:31 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 423762067B for ; Thu, 4 Jun 2020 20:25:31 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="eTUIYqIr" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 423762067B Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D38B680007; Thu, 4 Jun 2020 16:25:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CE8BC8E0006; Thu, 4 Jun 2020 16:25:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BD83780007; Thu, 4 Jun 2020 16:25:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0147.hostedemail.com [216.40.44.147]) by kanga.kvack.org (Postfix) with ESMTP id A6B018E0006 for ; Thu, 4 Jun 2020 16:25:30 -0400 (EDT) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 6460A181AC9B6 for ; Thu, 4 Jun 2020 20:25:30 +0000 (UTC) X-FDA: 76892659620.21.plant34_380fe7b26d9a Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin21.hostedemail.com (Postfix) with ESMTP id 20A5B180442C0 for ; Thu, 4 Jun 2020 20:25:30 +0000 (UTC) X-HE-Tag: plant34_380fe7b26d9a X-Filterd-Recvd-Size: 7740 Received: from mail-pl1-f196.google.com (mail-pl1-f196.google.com [209.85.214.196]) by imf41.hostedemail.com (Postfix) with ESMTP for ; Thu, 4 Jun 2020 20:25:29 +0000 (UTC) Received: by mail-pl1-f196.google.com with SMTP id y17so2660153plb.8 for ; Thu, 04 Jun 2020 13:25:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TblIMkzhKEVNZyPa1dQf8kFQ+MgYlpgsesY6pOK1xME=; b=eTUIYqIrq5sxbgWQO/3JauOnTYpVr1lxYINDt5nKOAMkJOKF9ufyGFqb5XSmsRi3m+ Uksx9+kJJ0xBVvvMTZtWdGvFYckH9URWghdJ/VSzZBwwBmizmaE949JntUM6qTfFIrip 3zzyVfVtH7B2Lzj4WQ8kAWj65+Txwm/2hs5XFlhCKdRU1uedTRsD04P49ZgSRY5QBLTc CQBCbVHZuVCB29pP2Co0mZAOf0TgkJUljtb0VB8CHI8VhuigYp30PE+r/D7MHanlVYxK BKS8ooZdHaU0PWi8nTHb08bOMRG7dMr/qLVaTlH87DKKqIpufZxi7ZRUHWNmW4PpK4km 2vlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TblIMkzhKEVNZyPa1dQf8kFQ+MgYlpgsesY6pOK1xME=; b=IbEW07xV8kISU5wW9aEtfciMEFpEQkVBG+1wxpvVVkzd5nFS7vmajBuiFeL54iDI3W ui6QGY0LKvdUvI6VeHAhQQxZE9U5bai84NsW0F76/eRc+szPvApLdM7QbtOjeBDt7tSF 6STXL51AzToGsqou/Q7xF5fyKFQVQ8kZ/nOv+Hn15UN/4ih49T+c39WBh7xtGo674iK/ fO/8VU/Z40vnvmR1hDnRSKz0vYu34uWAseyapSjh/ZjUj3PEaiuuULBfrobdqPhv5gv2 DOP9hI1yFsOVpSe39iG+O78iJpPdywHs4txFi53vKzBuGi2v+/SfmFdB3DgorA8K0h3/ 9LmA== X-Gm-Message-State: AOAM531BWGtXfnz+3AQAsZ2Wuk3Rcg3emrC8a8hympo7KsIuDxWnaH4R +jFrp1KbFrO4teQbo+Px8og78AopBVSBtyhHfHuADA== X-Google-Smtp-Source: ABdhPJzjhN/4pCp12TIV+9JXZmAnmqzfEHd9/r8jgURCikDTNzP/FuiRKg13zAi0ZiROLKM3I1SNYAlTdBzPgSsKmW0= X-Received: by 2002:a17:902:341:: with SMTP id 59mr6129425pld.119.1591302328252; Thu, 04 Jun 2020 13:25:28 -0700 (PDT) MIME-Version: 1.0 References: <20200603233203.1695403-1-keescook@chromium.org> <20200603233203.1695403-4-keescook@chromium.org> <202006041316.A15D952@keescook> In-Reply-To: <202006041316.A15D952@keescook> From: Nick Desaulniers Date: Thu, 4 Jun 2020 13:25:16 -0700 Message-ID: Subject: Re: [PATCH 03/10] b43: Remove uninitialized_var() usage To: Kees Cook Cc: LKML , Linus Torvalds , Miguel Ojeda , Alexander Potapenko , Joe Perches , Andy Whitcroft , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , drbd-dev@lists.linbit.com, linux-block@vger.kernel.org, b43-dev@lists.infradead.org, Network Development , linux-wireless , linux-ide@vger.kernel.org, linux-clk@vger.kernel.org, linux-spi@vger.kernel.org, Linux Memory Management List , clang-built-linux Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 20A5B180442C0 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam04 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Jun 4, 2020 at 1:18 PM Kees Cook wrote: > > On Thu, Jun 04, 2020 at 01:08:44PM -0700, Nick Desaulniers wrote: > > On Wed, Jun 3, 2020 at 4:32 PM Kees Cook wrote: > > > > > > Using uninitialized_var() is dangerous as it papers over real bugs[1] > > > (or can in the future), and suppresses unrelated compiler warnings (e.g. > > > "unused variable"). If the compiler thinks it is uninitialized, either > > > simply initialize the variable or make compiler changes. As a precursor > > > to removing[2] this[3] macro[4], just initialize this variable to NULL, > > > and make the (unreachable!) code do a conditional test. > > > > > > [1] https://lore.kernel.org/lkml/20200603174714.192027-1-glider@google.com/ > > > [2] https://lore.kernel.org/lkml/CA+55aFw+Vbj0i=1TGqCR5vQkCzWJ0QxK6CernOU6eedsudAixw@mail.gmail.com/ > > > [3] https://lore.kernel.org/lkml/CA+55aFwgbgqhbp1fkxvRKEpzyR5J8n1vKT1VZdz9knmPuXhOeg@mail.gmail.com/ > > > [4] https://lore.kernel.org/lkml/CA+55aFz2500WfbKXAx8s67wrm9=yVJu65TpLgN_ybYNv0VEOKA@mail.gmail.com/ > > > > > > Signed-off-by: Kees Cook > > > --- > > > drivers/net/wireless/broadcom/b43/phy_n.c | 10 +++++++--- > > > 1 file changed, 7 insertions(+), 3 deletions(-) > > > > > > diff --git a/drivers/net/wireless/broadcom/b43/phy_n.c b/drivers/net/wireless/broadcom/b43/phy_n.c > > > index d3c001fa8eb4..88cdcea10d61 100644 > > > --- a/drivers/net/wireless/broadcom/b43/phy_n.c > > > +++ b/drivers/net/wireless/broadcom/b43/phy_n.c > > > @@ -4222,7 +4222,7 @@ static void b43_nphy_tx_gain_table_upload(struct b43_wldev *dev) > > > > The TODOs and `#if 0` in this function are concerning. It looks like > > `rf_pwr_offset_table` is only used when `phy->rev` is >=7 && < 19. > > > > Further, the loop has a case for `phy->rev >= 19` but we would have > > returned earlier if that was the case. oh, and there's an early return for `phy->rev < 3` I just noticed. > > Yeah, that's why I put the "(unreachable!)" note in the commit log. ;) I don't think that note is correct. > > > > > > u32 rfpwr_offset; > > > u8 pga_gain, pad_gain; > > > int i; > > > - const s16 *uninitialized_var(rf_pwr_offset_table); > > > + const s16 *rf_pwr_offset_table = NULL; > > > > > > table = b43_nphy_get_tx_gain_table(dev); > > > if (!table) > > > @@ -4256,9 +4256,13 @@ static void b43_nphy_tx_gain_table_upload(struct b43_wldev *dev) > > > pga_gain = (table[i] >> 24) & 0xf; > > > pad_gain = (table[i] >> 19) & 0x1f; > > > if (b43_current_band(dev->wl) == NL80211_BAND_2GHZ) > > > - rfpwr_offset = rf_pwr_offset_table[pad_gain]; > > > + rfpwr_offset = rf_pwr_offset_table > > > + ? rf_pwr_offset_table[pad_gain] > > > + : 0; > > > else > > > - rfpwr_offset = rf_pwr_offset_table[pga_gain]; > > > + rfpwr_offset = rf_pwr_offset_table > > > + ? rf_pwr_offset_table[pga_gain] > > > + : 0; > > > > > > The code is trying to check `phy->rev >= 7 && phy->rev < 19` once > > before the loop, then set `rf_pwr_offset_table`, so having another > > conditional on `rf_pwr_offset_table` in the loop is unnecessary. I'm > > ok with initializing it to `NULL`, but I'm not sure the conditional > > check is necessary. Do you get a compiler warning otherwise? > > I mean, sort of the best thing to do is just remove nearly everything > here since it's actually unreachable. But it is commented as "when This code is reachable. Consider `phy->rev >= 7 && phy->rev < 19`. If `rf_pwr_offset_table` was NULL, it would have returned early on L4246, so the checks added in this patch are unnecessary. Forgive me if there's some other control flow I'm not considering. > supported ..." etc, so I figured I'd leave it. As part of that I didn't > want to leave any chance of a NULL deref, so I added the explicit tests > just for robustness. > > *shrug* -- Thanks, ~Nick Desaulniers