From patchwork Fri Apr 4 15:40:23 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bjorn Helgaas X-Patchwork-Id: 337032 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 1230E1400EB for ; Sat, 5 Apr 2014 02:40:37 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753836AbaDDPkc (ORCPT ); Fri, 4 Apr 2014 11:40:32 -0400 Received: from mail-pa0-f49.google.com ([209.85.220.49]:52440 "EHLO mail-pa0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753021AbaDDPk1 (ORCPT ); Fri, 4 Apr 2014 11:40:27 -0400 Received: by mail-pa0-f49.google.com with SMTP id lj1so3617650pab.36 for ; Fri, 04 Apr 2014 08:40:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=ahIVsOuZ5b4a55PCQLnhg6w7EpJtNlQZXE6Vy8fzj0w=; b=jlxhsAnTr8c7773JCFGjDoyQcGbjATHcSvaD3HciNvAUQTEWyPr6e2xojKIVd6YUPJ OYrmvGMR8SWXQfsgshcBkA/1vYAvqn/rLxuZ5nGMDECx4SZ7gKQQXd/fndoaKaoaUHI/ PYkTG18qtvRDrXjyj2J9c/ACqq72/eYMr9/fL/Z4510/nu7vzawRJL2kw1tCQFlzrJCg Y/yDAT8lrIWDSy4ZP3xTM3OjpFFCK8b/F9mUYUqbpnsqkB2WppkbO3ZYmK9m3OY0yum4 0uOZomgSWMJKSLGBzR2lQ6nVTs19fXlBXBDk9oPF5sD+SJHrPx51rOprqhOpkEK/Qz+3 BR1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=ahIVsOuZ5b4a55PCQLnhg6w7EpJtNlQZXE6Vy8fzj0w=; b=gZv2xXnwkQkjvVIA+VeIccGaT5ZPTRvGxxXT0y7cX5G8iPB6PH6b4lPZVsK1zaVERT ecofchwwS+A17Eupgy7j/j8HU/vbT6vGvGvJXNjIMDCymG2DYzGs4SzKJ+1jvGcXBSYm Gof56qBZ06WCLljcLTfGieD1oRtQPfHeyvypfcKOUuTdXOWsMxJjEXZ2k1rxeMtld9Un tyOS/4MyhnsvJCXi+sY/8WgDvWFI89UWsw8Nla94/OmRuKtb/FPUr/CfKTg1KmDKCyTE hTBy+cZEHVyPP7OE0yy2BEv+umyvb/jZApCYO7MOsue2VTwGOakFVh1tt4rh2dDNMgja XHdw== X-Gm-Message-State: ALoCoQloloRJ9jXjI52JcGg16UucXECf6GEhEiu9DlRUhCx8nJmv2fdugbAx5j8W6fyvQkhk9va+g+Tr3mYZWSKWiD+PUxZwECj/uuqzECqz61gwqsrMFgg+IbuzNk+vPtScGaeFYrkUMi9IQNyXGtkIXS1R68hFe8YUC4egIzbxGaypw/bFhqBhQSQsC+Xuzju1bUPoM3NdqYu1TmBXzyq7iPQAgg2Tpw== X-Received: by 10.68.170.131 with SMTP id am3mr6503393pbc.97.1396626026738; Fri, 04 Apr 2014 08:40:26 -0700 (PDT) Received: from google.com ([172.26.55.227]) by mx.google.com with ESMTPSA id q7sm18550362pbc.20.2014.04.04.08.40.25 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 04 Apr 2014 08:40:26 -0700 (PDT) Date: Fri, 4 Apr 2014 09:40:23 -0600 From: Bjorn Helgaas To: "Ira W. Snyder" Cc: Yinghai Lu , "linux-pci@vger.kernel.org" Subject: Re: Coverity CIDs 138749, 138750: cnb20le_res() unintended sign extension Message-ID: <20140404154023.GA5367@google.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org On Thu, Apr 03, 2014 at 02:56:26PM -0600, Bjorn Helgaas wrote: > Coverity complains about unintended sign extension in cnb20le_res() in > arch/x86/pci/broadcom_bus.c here: > > 60 word1 = read_pci_config_16(bus, slot, func, 0xc4); > 61 word2 = read_pci_config_16(bus, slot, func, 0xc6); > 62 if (word1 != word2) { > > CID 138749 (#1 of 2): Unintended sign extension (SIGN_EXTENSION) > sign_extension: Suspicious implicit sign extension: word1 with type > unsigned short (16 bits, unsigned) is promoted in (word1 << 16) | 0 to > type int (32 bits, signed), then sign-extended to type unsigned long > long (64 bits, unsigned). If (word1 << 16) | 0 is greater than > 0x7FFFFFFF, the upper bits of the result will all be 1. > 63 res.start = (word1 << 16) | 0x0000; > CID 138750: Unintended sign extension (SIGN_EXTENSION) [select issue] I propose the following patch for this. Unless there's objection, I'll queue this for v3.16. x86/PCI: Fix Broadcom CNB20LE unintended sign extension From: Bjorn Helgaas In the expression "word1 << 16", word1 starts as u16, but is promoted to a signed int, then sign-extended to resource_size_t, which is probably not what was intended. Cast to resource_size_t to avoid the sign extension. Found by Coverity (CID 138749, 138750). Signed-off-by: Bjorn Helgaas --- arch/x86/pci/broadcom_bus.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/arch/x86/pci/broadcom_bus.c b/arch/x86/pci/broadcom_bus.c index 614392ced7d6..bb461cfd01ab 100644 --- a/arch/x86/pci/broadcom_bus.c +++ b/arch/x86/pci/broadcom_bus.c @@ -60,8 +60,8 @@ static void __init cnb20le_res(u8 bus, u8 slot, u8 func) word1 = read_pci_config_16(bus, slot, func, 0xc4); word2 = read_pci_config_16(bus, slot, func, 0xc6); if (word1 != word2) { - res.start = (word1 << 16) | 0x0000; - res.end = (word2 << 16) | 0xffff; + res.start = ((resource_size_t) word1 << 16) | 0x0000; + res.end = ((resource_size_t) word2 << 16) | 0xffff; res.flags = IORESOURCE_MEM | IORESOURCE_PREFETCH; update_res(info, res.start, res.end, res.flags, 0); }