Received-SPF: pass (google.com: domain of linux-kernel+bounces-211119-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Message-ID: <378bad75-dfc7-4462-8fbc-a462e129a0ea@suse.com>
Date: Wed, 12 Jun 2024 10:00:44 +0200
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: USB Denial Of Service
To: Alan Stern <stern@rowland.harvard.edu>,
 Greg KH <gregkh@linuxfoundation.org>, Oliver Neukum <oneukum@suse.com>
Cc: USB mailing list <linux-usb@vger.kernel.org>,
 Kernel development list <linux-kernel@vger.kernel.org>
References: <40dfa45b-5f21-4eef-a8c1-51a2f320e267@rowland.harvard.edu>
Content-Language: en-US
From: Oliver Neukum <oneukum@suse.com>
In-Reply-To: <40dfa45b-5f21-4eef-a8c1-51a2f320e267@rowland.harvard.edu>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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