Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752955AbcCNQsl (ORCPT ); Mon, 14 Mar 2016 12:48:41 -0400 Received: from mail-vk0-f54.google.com ([209.85.213.54]:36644 "EHLO mail-vk0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752151AbcCNQsi (ORCPT ); Mon, 14 Mar 2016 12:48:38 -0400 MIME-Version: 1.0 In-Reply-To: References: <1457964773-29512-1-git-send-email-jwboyer@fedoraproject.org> <20160314161548.GA2585@kroah.com> Date: Mon, 14 Mar 2016 09:48:37 -0700 Message-ID: Subject: Re: [PATCH] USB: input: powermate: fix oops with malicious USB descriptors From: Dmitry Torokhov To: Josh Boyer Cc: Greg Kroah-Hartman , "linux-input@vger.kernel.org" , Linux USB Mailing List , "Linux-Kernel@Vger. Kernel. Org" , stable , Oliver Neukum Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1986 Lines: 46 On Mon, Mar 14, 2016 at 9:46 AM, 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? I'll take input bits, there is no need to keep kernel oopsing while we are working on a more general solution. Thanks. -- Dmitry