netdev - Re: [RFC] net: usbnet: prevent buggy devices from killing us

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2556579.vjYlY1iKn5@linux-5eaq.site>
Date:	Thu, 24 Jan 2013 14:12 +0100
From:	Oliver Neukum <oneukum@...e.de>
To:	Bjørn Mork <bjorn@...k.no>
Cc:	linux-usb@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [RFC] net: usbnet: prevent buggy devices from killing us

On Thursday 24 January 2013 13:47:40 Bjørn Mork wrote:
> Oliver Neukum <oneukum@...e.de> writes:
> > On Thursday 24 January 2013 12:22:54 Bjørn Mork wrote:
> >
> >> Sorry for being daft, but how do I code the "20 among the last 30" part
> >> there?
> >
> > Just by agreeing that you can live with false negatives but not false positives
> >
> > if (++counter > 30) {
> > 	counter = bogus = 0;
> > } else {
> > 	if (is_bogus(packet)
> > 		bogus++;
> > 	if (bogus > counter/2)

Should probably be something like bogus > counter/2 + 10

> > 		throttle();
> > }
> 
> So, add two new counters to struct usbnet for this?  That seems a little
> overkill to me, but I don't see how else to implement anything like that.

Memory is cheap.
 
> It is still not completely clear to me how the throttling/unthrottling
> should be done.  It tested with static counters (to avoid having to
> rebuild everything for this test) and a new EVENT_RX_THROTTLE flag.
> Still on top of my previous patch just for safety while testing, as I am
> fed up of having to reboot all the time :-)
> 
> Doing the flag test in rx_submit seems simpler than trying to track all
> the places this is called.  Still checking the dev->done.qlen to be able
> to unthrottle.

Ideally we would do some error handling. Does the device keep spewing
zero packets for all eternity?

	Regards
		Oliver

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html