From: Johan Hovold <johan@kernel.org>
To: Oliver Neukum <oneukum@suse.com>
Cc: Johan Hovold <johan@kernel.org>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-usb@vger.kernel.org
Subject: Re: [PATCH 0/7] Input: fix NULL-derefs at probe
Date: Mon, 13 Mar 2017 16:45:52 +0100 [thread overview]
Message-ID: <20170313154552.GT4211@localhost> (raw)
In-Reply-To: <1489418118.30110.26.camel@suse.com>
On Mon, Mar 13, 2017 at 04:15:18PM +0100, Oliver Neukum wrote:
> Am Montag, den 13.03.2017, 13:35 +0100 schrieb Johan Hovold:
> > This series fixes a number of NULL-pointer dereferences due to
> > missing
> > endpoint sanity checks that can be triggered by a malicious USB
> > device.
>
> At the risk of repeating myself, doesn't the sheer number of fixes
> demonstrate the need for a more centralized check?
No, I don't think that follows. These are plain bugs that needs to be
fixed (cf. not checking for allocation failures or whatever) and
backported to the stable trees.
I think I may have surveyed just about every USB driver this last week,
and there is no single pattern for how endpoints are verified and
retrieved that could easily be refactored into USB core.
Now there are certain patterns that could benefit from a few helpers,
and some obvious bugs could then be caught by declaring those helpers as
__must_check. But specifically, you'd still be checking the return
value from the helpers.
Then verifying the endpoint counts before calling driver probe,
typically only saves a bit of time while probing *malicious* devices
(and the occasional odd interface which cannot be matched on other
attributes).
That being said, we could still add a centralised sanity check for a
large class of drivers (e.g. that do not use altsettings and only need
minimum constraints) but it's not going to obviate the need for careful
driver implementations.
I'll be posting some more patches related to this shortly.
Thanks,
Johan
next prev parent reply other threads:[~2017-03-13 15:46 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-13 12:35 [PATCH 0/7] Input: fix NULL-derefs at probe Johan Hovold
2017-03-13 12:35 ` [PATCH 1/7] Input: iforce - fix NULL-deref " Johan Hovold
[not found] ` <20170313123539.28103-1-johan-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
2017-03-13 12:35 ` [PATCH 2/7] Input: cm109 " Johan Hovold
2017-03-13 15:15 ` [PATCH 0/7] Input: fix NULL-derefs " Oliver Neukum
2017-03-13 15:45 ` Johan Hovold [this message]
2017-03-16 22:37 ` Dmitry Torokhov
2017-03-17 10:53 ` Johan Hovold
2017-03-17 21:03 ` Dmitry Torokhov
2017-03-18 9:13 ` Johan Hovold
2017-03-13 12:35 ` [PATCH 3/7] Input: ims-pcu - fix NULL-deref " Johan Hovold
2017-03-13 12:35 ` [PATCH 4/7] Input: yealink " Johan Hovold
2017-03-13 12:35 ` [PATCH 5/7] Input: hanwang " Johan Hovold
2017-03-13 12:35 ` [PATCH 6/7] Input: kbtab " Johan Hovold
2017-03-13 12:35 ` [PATCH 7/7] Input: sur40 " Johan Hovold
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170313154552.GT4211@localhost \
--to=johan@kernel.org \
--cc=dmitry.torokhov@gmail.com \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=oneukum@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).