Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753371AbcCNRHQ (ORCPT ); Mon, 14 Mar 2016 13:07:16 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:41943 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753298AbcCNRHM (ORCPT ); Mon, 14 Mar 2016 13:07:12 -0400 Date: Mon, 14 Mar 2016 10:07:10 -0700 From: Greg Kroah-Hartman To: Josh Boyer Cc: Dmitry Torokhov , linux-input@vger.kernel.org, Linux USB Mailing List , "Linux-Kernel@Vger. Kernel. Org" , stable , Oliver Neukum Subject: Re: [PATCH] USB: input: powermate: fix oops with malicious USB descriptors Message-ID: <20160314170710.GA619@kroah.com> References: <1457964773-29512-1-git-send-email-jwboyer@fedoraproject.org> <20160314161548.GA2585@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1998 Lines: 45 On Mon, Mar 14, 2016 at 12:46:26PM -0400, Josh Boyer wrote: > On Mon, Mar 14, 2016 at 12:15 PM, Greg Kroah-Hartman > wrote: > > On Mon, Mar 14, 2016 at 10:12:53AM -0400, Josh Boyer wrote: > >> The powermate driver expects at least one valid USB endpoint in its > >> probe function. If given malicious descriptors that specify 0 for > >> the number of endpoints, it will crash. Validate the number of > >> endpoints on the interface before using them. > >> > >> The full report for this issue can be found here: > >> http://seclists.org/bugtraq/2016/Mar/85 > >> > >> Reported-by: Ralf Spenneberg > >> Cc: stable > >> Signed-off-by: Josh Boyer > >> --- > >> drivers/input/misc/powermate.c | 3 +++ > >> 1 file changed, 3 insertions(+) > > > > I'll queue these up after 4.6-rc1 is out as the merge window is closed > > right now, but we might want to think about a better way to handle this > > type of thing in the USB core. A way to keep from having to add checks > > like this for every single driver, when the driver shouldn't even really > > have their probe function called unless their expected endpoints are > > going to be there. > > I thought this discussion came up a while ago, when something very > similar was fixed in the whiteheat driver (commit cbb4be652d374). I > can't find the thread at the moment, but I thought someone said this > had to be per-driver for some reason. I'm more than happy to have a > core subsystem fix if it's possible. > > > I'll think about that over the next few weeks... > > I have something around 8 drivers with issues like this. I think > Oliver (now CC'd) is working from the same set of bugs. Should we > hold off on submitting individual fixes until later, or should we go > ahead and submit them? Please submit them, that will give us a framework to be able to figure out the specifics of what needs to be changed. thanks, greg k-h