[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180106094209.GB11525@kroah.com>
Date: Sat, 6 Jan 2018 10:42:09 +0100
From: Greg KH <gregkh@...uxfoundation.org>
To: Dan Williams <dan.j.williams@...el.com>
Cc: linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
"James E.J. Bottomley" <jejb@...ux.vnet.ibm.com>,
"Martin K. Petersen" <martin.petersen@...cle.com>,
linux-scsi@...r.kernel.org, peterz@...radead.org,
netdev@...r.kernel.org, qla2xxx-upstream@...gic.com,
tglx@...utronix.de, torvalds@...ux-foundation.org,
Elena Reshetova <elena.reshetova@...el.com>,
alan@...ux.intel.com
Subject: Re: [PATCH 10/18] qla2xxx: prevent bounds-check bypass via
speculative execution
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
Powered by blists - more mailing lists