On Mon, Mar 14, 2016 at 9:46 AM, Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote: > On Mon, Mar 14, 2016 at 12:15 PM, Greg Kroah-Hartman > <gregkh@xxxxxxxxxxxxxxxxxxx> 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 <ralf@xxxxxxxxxxxxxx> >>> Cc: stable <stable@xxxxxxxxxxxxxxx> >>> Signed-off-by: Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> >>> --- >>> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
