linux-kernel - Re: USB Denial Of Service

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: <378bad75-dfc7-4462-8fbc-a462e129a0ea@suse.com>
Date: Wed, 12 Jun 2024 10:00:44 +0200
From: Oliver Neukum <oneukum@...e.com>
To: Alan Stern <stern@...land.harvard.edu>,
 Greg KH <gregkh@...uxfoundation.org>, Oliver Neukum <oneukum@...e.com>
Cc: USB mailing list <linux-usb@...r.kernel.org>,
 Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: USB Denial Of Service

On 11.06.24 16:35, Alan Stern wrote:
> Greg, Oliver, or anyone else:
> 
> Questions:
> 
> If a broken or malicious device causes a USB class driver to add a
> thousand (or more) error messages per second to the kernel log,
> indefinitely, would that be considered a form of DOS?

Yes.

> Should the driver be fixed?

If a broken device can do that, definitely.

> What is an acceptable rate for an unending stream of error messages?
> Once a second?  Once a minute?

Definitely not once a second. I'd be tempted to call a neverending stream
an issue by itself. The approach the SCSI layer takes by giving up on
a device if all else fails seems wise to me.

> At what point should the driver give up and stop trying to communicate
> with the device?

I would propose after five cycles of all error handling.

The exact number, as long as it is greater than 1 and a small integer
does not really matter, as long as it exists.

	Regards
		Oliver