Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751909AbcCNQd2 (ORCPT ); Mon, 14 Mar 2016 12:33:28 -0400 Received: from mail-pf0-f181.google.com ([209.85.192.181]:36181 "EHLO mail-pf0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750835AbcCNQd0 (ORCPT ); Mon, 14 Mar 2016 12:33:26 -0400 Date: Mon, 14 Mar 2016 09:33:22 -0700 From: Dmitry Torokhov To: Greg Kroah-Hartman Cc: Josh Boyer , linux-input@vger.kernel.org, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, stable Subject: Re: [PATCH] USB: input: powermate: fix oops with malicious USB descriptors Message-ID: <20160314163322.GA15593@dtor-ws> 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: <20160314161548.GA2585@kroah.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1362 Lines: 34 On Mon, Mar 14, 2016 at 09:15:48AM -0700, 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 I do not see any reason in holding it until after rc1, applied. > 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 had a patch where driver could declare minimal amount of endpoints it expects to find, but you mentioned we need something more flexible... Thanks. -- Dmitry