Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752975AbeAFJmI (ORCPT + 1 other); Sat, 6 Jan 2018 04:42:08 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:46706 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752805AbeAFJmG (ORCPT ); Sat, 6 Jan 2018 04:42:06 -0500 Date: Sat, 6 Jan 2018 10:42:09 +0100 From: Greg KH To: Dan Williams Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, "James E.J. Bottomley" , "Martin K. Petersen" , linux-scsi@vger.kernel.org, peterz@infradead.org, netdev@vger.kernel.org, qla2xxx-upstream@qlogic.com, tglx@linutronix.de, torvalds@linux-foundation.org, Elena Reshetova , alan@linux.intel.com Subject: Re: [PATCH 10/18] qla2xxx: prevent bounds-check bypass via speculative execution Message-ID: <20180106094209.GB11525@kroah.com> References: <151520099201.32271.4677179499894422956.stgit@dwillia2-desk3.amr.corp.intel.com> <151520104838.32271.7038801336240727574.stgit@dwillia2-desk3.amr.corp.intel.com> <20180106090322.GF4380@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180106090322.GF4380@kroah.com> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Sat, Jan 06, 2018 at 10:03:22AM +0100, Greg KH wrote: > On Fri, Jan 05, 2018 at 05:10:48PM -0800, Dan Williams wrote: > > Static analysis reports that 'handle' may be a user controlled value > > that is used as a data dependency to read 'sp' from the > > 'req->outstanding_cmds' array. In order to avoid potential leaks of > > kernel memory values, block speculative execution of the instruction > > stream that could issue reads based on an invalid value of 'sp'. In this > > case 'sp' is directly dereferenced later in the function. > > I'm pretty sure that 'handle' comes from the hardware, not from > userspace, from what I can tell here. If we want to start auditing > __iomem data sources, great! But that's a bigger task, and one I don't > think we are ready to tackle... And as Peter Zijlstra has already mentioned, if we have to look at those codepaths, USB drivers are the first up for that mess, so having access to the coverity rules would be a great help in starting that effort. thanks, greg k-h