Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp183543imm; Thu, 21 Jun 2018 16:22:19 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIjtR8S4CGC3RiiatH4EtwX6I0uAq3lRtOYnAazYV+UTYfq1AQej/58Oo81oWzcb/XpDdA2 X-Received: by 2002:a17:902:7009:: with SMTP id y9-v6mr30391019plk.217.1529623339564; Thu, 21 Jun 2018 16:22:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529623339; cv=none; d=google.com; s=arc-20160816; b=G6av2FM3T2PpUWVzJR10b7E30ZAyQ0dOW+Md++PEdkLiMV8Q9PcO/0dqw2JyNi4y89 9QlsMWXnyF6rDUGRndnVgzKEb+iR4T+Wi0g2VEj3Rn0siMWKpAC8M0ipZtfWvomZnpIZ nUbIXrb7kp5lapMRhMVJJ6Jvfl0BoeSnJASaR46Yp/n/HmWbPFlQXqbhSccvE/rJ85ZT hxdlyCQWDML95ARnww3yzmvv4hR6R+rioWMRXVzB7AZZ7EH9hPXFvQo0YYqMA+fHuXSX XKUe69UBlBw1r44W5JQKsw0kuKyrH3+uEwADqoBFaV6vOaaxP6ZkXrK0z/IROXkScwj3 yVcQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature:arc-authentication-results; bh=KzHhBFRNexS9vHEkpQXOL5Nfy7fbIr6pAQnkT/S9/gU=; b=V0Q18y0zFY3aMlKuiqOFecArngqa6aPxK9mUA+LDrbSbzsXnlNS+EhAwHH3ot46PCg kQmq0aCUlYR9m8xZYgfKq/LuUceZW1paXHo3/Ep1E4DTyM7cWkAbwYKsXPxpX1yXbP+H laLLoMK5iZ+/8Y4+SyqM87IVx/NrAdzdSSu9u4Y5uozdBP2FwK8iz9PpKIimJNiC6Hgj w+9DbiPz9zi/aucRhbI+bg49kEsKKNzV309MQTP797VMKXQ5jII8khXySB0yfgcYidsz BqxlG4p+CmwaALSkw7pllVKT6pmSBv0ZbbEwXEzo5GNxGLOKqLEJHpX6aEvUh/iSlba/ ocyw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@networkplumber-org.20150623.gappssmtp.com header.s=20150623 header.b=aK76BrRT; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h91-v6si5731015pld.132.2018.06.21.16.22.04; Thu, 21 Jun 2018 16:22:19 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@networkplumber-org.20150623.gappssmtp.com header.s=20150623 header.b=aK76BrRT; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932938AbeFUXVV (ORCPT + 99 others); Thu, 21 Jun 2018 19:21:21 -0400 Received: from mail-pg0-f66.google.com ([74.125.83.66]:32934 "EHLO mail-pg0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932170AbeFUXVU (ORCPT ); Thu, 21 Jun 2018 19:21:20 -0400 Received: by mail-pg0-f66.google.com with SMTP id e11-v6so2097658pgq.0 for ; Thu, 21 Jun 2018 16:21:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=KzHhBFRNexS9vHEkpQXOL5Nfy7fbIr6pAQnkT/S9/gU=; b=aK76BrRTUi8WX6THnrrhwI0rlClRuIpkew1/Ffju1Hj001Y+4t4NOLOPfYbreesJ6Q D9WwXqp/elZaVGoQCeSuwADpVkf5SLZypehesDj8jlVNSwVPLhaUbfQndN/a5HDrQKzg yW3rHSi/WezckBbhjiAP+jVlEPeQz9G7QdPqPyN4XSV6CFLIKnIaFL3qlDB3VR0XxXie L3Sgp5d5SFDPepW3bM8QLwAg/wUIDMEmNRCwkr+mr7QUfs5v1fzoznUGKXYrUtexKrHD 9StzodvYTgJekg+0yNz5EE6UFAnbaKrHMJ5FEWwyRpB3JMaV0Ydp1DrSUXB9zuK1SIBO sFbg== 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:in-reply-to :references:mime-version:content-transfer-encoding; bh=KzHhBFRNexS9vHEkpQXOL5Nfy7fbIr6pAQnkT/S9/gU=; b=bs20Lf4zsjH803ZniZfH9gMAaza5y/wmfOUkG/YQkTQ+8BBY9TECxXvvcI8h0k4zdn /tM6U1zRJJ8whmw12npWEQK5kYAORBAA5baVSPf+VqWAaKniV322ttR/85j0W2sB2g6p Ny945iXUnoLzKwBAabTlT//xA0eU7j8fyQt51ZOYrYs/z6lMaaUHjo9KqAN46rK6hRjJ j9cS6bWbFzfZL2oZ4r9rLXRQwQbiLNP3enkbXSsPHynXsjv7YP9J3fw4MdKktc/VzC2N Zgl0bRZ7NkAVPRCwZsW9wuATZDbd049FGg3oeFPydbyvR2+JwCvDVqjLIJhybhmbVCr9 CrEQ== X-Gm-Message-State: APt69E2PxcRBykHArdM8SdDylgZ4HjT+6b6CDnxKcWoI59eWnSkV7Ydj ylfcYlSLiR3AvFHIL0OpGSO6rQ== X-Received: by 2002:a63:bf0b:: with SMTP id v11-v6mr23392143pgf.29.1529623279614; Thu, 21 Jun 2018 16:21:19 -0700 (PDT) Received: from xeon-e3 (204-195-35-107.wavecable.com. [204.195.35.107]) by smtp.gmail.com with ESMTPSA id m5-v6sm20632884pfa.93.2018.06.21.16.21.19 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 21 Jun 2018 16:21:19 -0700 (PDT) Date: Thu, 21 Jun 2018 16:21:16 -0700 From: Stephen Hemminger To: David Miller Cc: garrmcnu@gmail.com, netdev@vger.kernel.org, jiri@resnulli.us, nikolay@cumulusnetworks.com, bridge@lists.linux-foundation.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] net: bridge: fix potential null pointer dereference on return from br_port_get_rtnl() Message-ID: <20180621162116.7f424648@xeon-e3> In-Reply-To: <20180622.072056.1223319763674661318.davem@davemloft.net> References: <20180621201427.4961-1-garrmcnu@gmail.com> <20180622.072056.1223319763674661318.davem@davemloft.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 22 Jun 2018 07:20:56 +0900 (KST) David Miller wrote: > From: Garry McNulty > Date: Thu, 21 Jun 2018 21:14:27 +0100 > > > br_port_get_rtnl() can return NULL if the network device is not a bridge > > port (IFF_BRIDGE_PORT flag not set). br_port_slave_changelink() and > > br_port_fill_slave_info() callbacks dereference this pointer without > > checking. Currently this is not a problem because slave devices always > > set this flag. Add null check in case these conditions ever change. > > > > Detected by CoverityScan, CID 1339613 ("Dereference null return value") > > > > Signed-off-by: Garry McNulty > > I don't think this is reasonable. > > The bridge code will never, ever, install a slave that doesn't have > that bit set. It's the most fundamental aspect of how these objects > are managed. Agree with dave. Workarounds for static tools are ok if they don't introduce other paths. But if your fix introduces another error path which can never be reached, it is hurting not helping.