linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Bjørn Mork" <bjorn@mork.no>
To: Young Xiao <92siuyang@gmail.com>
Cc: kbuild-all@01.org, linux-usb@vger.kernel.org,
	linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
	greg@kroah.com, mchehab@kernel.org, keescook@chromium.org,
	hans.verkuil@cisco.com, Young Xiao <YangX92@hotmail.com>
Subject: Re: [PATCH] USB: s2255 & stkwebcam: fix oops with malicious USB descriptors
Date: Fri, 12 Apr 2019 10:04:09 +0200	[thread overview]
Message-ID: <878swf645i.fsf@miraculix.mork.no> (raw)
In-Reply-To: <1555036767-31170-1-git-send-email-92siuyang@gmail.com> (Young Xiao's message of "Fri, 12 Apr 2019 10:39:27 +0800")

Please mark updated patches with a version number or some other
indication that it replaces a previous patch.  Including a summary of
changes is also normal.

And speaking of normal:  We do build test our patches, don't we?


Young Xiao <92siuyang@gmail.com> writes:

> From: Young Xiao <YangX92@hotmail.com>
>
> The driver expects at least one valid endpoint. If given
> malicious descriptors that specify 0 for the number of endpoints,
> it will crash in the probe function.

No, it won't.  Did you test this?  Can you provide the oops?

This is perfectly fine as it is:

	dev = kzalloc(sizeof(struct s2255_dev), GFP_KERNEL);
..
	for (i = 0; i < iface_desc->desc.bNumEndpoints; ++i) {
		endpoint = &iface_desc->endpoint[i].desc;
		if (!dev->read_endpoint && usb_endpoint_is_bulk_in(endpoint)) {
			/* we found the bulk in endpoint */
			dev->read_endpoint = endpoint->bEndpointAddress;
		}
	}

	if (!dev->read_endpoint) {
		dev_err(&interface->dev, "Could not find bulk-in endpoint\n");
		goto errorEP;
	}

>  drivers/media/usb/stkwebcam/stk-webcam.c | 6 ++++++

I didn't bother looking at this driver to see if your patch there makes
more sense.  That is your home work now.  Please explain why you believe
it is.  An actual oops would be good.

<rant>
Yes, and I do have some objections to this whole "protect against
malicious devices".  How do you intend to protect against a USB device
disguising itself as a keyboard or ethernet adapater or whatever?
Allowing potentionally malicious devices is crazy enough for USB, and it
gets completely wacko when people start talking about it in the context
of firewire or PCIe

Fixing bugs in drivers is fine. But it won't make any difference wrt
security if you connect malicious devices to your system.  Don't do that
if you want a secure system.

Allocating CVE numbers to arbitrary driver bugs is just adding
noise. This noise makes it harder for sysadmins and others to to notice
the really important problems.  No one will care anymore if every kernel
release fixes thousands of CVEs.  Which is pretty close to the truth if
you start allocating CVE numbers to any bug with a security impact.
</rant>




Bjørn

  reply	other threads:[~2019-04-12  8:04 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-12  2:39 [PATCH] USB: s2255 & stkwebcam: fix oops with malicious USB descriptors Young Xiao
2019-04-12  8:04 ` Bjørn Mork [this message]
2019-04-12  8:58   ` Yang Xiao
     [not found]   ` <CAKgHYH05R2CQ1XmS-KCTtL0J49D2kpnkBgyYxdPc47SNpaf8vA@mail.gmail.com>
2019-04-12  9:07     ` Bjørn Mork
2019-04-12  9:36       ` Yang Xiao
  -- strict thread matches above, loose matches on Subject: below --
2019-04-11  4:54 Young Xiao
2019-04-11 14:36 ` kbuild test robot
     [not found]   ` <CAKgHYH27TtpbUKJin+WyTRUvqgpTSBRWBTp6YhsUCpVTnKfNPA@mail.gmail.com>
2019-04-16 10:06     ` Greg KH
2019-04-16 11:26 ` Johan Hovold
2019-04-16 11:33   ` 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=878swf645i.fsf@miraculix.mork.no \
    --to=bjorn@mork.no \
    --cc=92siuyang@gmail.com \
    --cc=YangX92@hotmail.com \
    --cc=greg@kroah.com \
    --cc=hans.verkuil@cisco.com \
    --cc=kbuild-all@01.org \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mchehab@kernel.org \
    /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).