linux-kernel - Re: USB cdc-acm driver: break and command

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: <83B89F79-D28B-4F2C-87EA-F5078BD7ED17@zytor.com>
Date: Wed, 16 Jul 2025 08:06:11 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Oliver Neukum <oneukum@...e.com>
CC: linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
        gregkh@...uxfoundation.org, Jiri Slaby <jirislaby@...nel.org>,
        linux-serial@...r.kernel.org
Subject: Re: USB cdc-acm driver: break and command

On July 16, 2025 1:29:27 AM PDT, Oliver Neukum <oneukum@...e.com> wrote:
>On 15.07.25 23:00, H. Peter Anvin wrote:
>> Hi,
>> 
>> I noticed looking at the CDC-ACM driver that it uses the assert/local delay/deassert method of sending BREAK.  Given that the CDC model has a delay specifier in the command packet, is there any reason not to set TTY_DRIVER_HARDWARE_BREAK and sending only one packet?
>
>1. The existing code is tested and usually works.
>2. The locking goes away. I have no idea what happens if you are
>sending a second break while a break is still going on.
>
>> I'm also wondering if it would make sense to support the SEND_ENCAPSULATED_COMMAND and GET_ENCAPSULATED_RESPONSE commands, presumably via an ioctl().  I'm not 100% sure because I'm not sure there aren't potential security issues.
>
>Well, one of the purposes of the CDC-ACM driver is to hide that
>you are talking to a USB device.
>In theory we could do that. I don't quite see the value.
>Sending arbitrary data from user space to a control endpoint
>does not make me happy.
>
>	HTH
>		Oliver
> 
However, the flipside is that ACM devices are very often used because it is one of the few ways you can avoid requiring device drivers on Windows.

This is why some devices do absolutely insane crap like Arduino which trigger a board reset if you set the speed to 1200 baud.

SEND_ENCAPSULATED_COMMAND at least takes a command string – it was intended, I believe, to be able to send AT commands to a modem while online without using the +++ escape code and all the potential race conditions (and security issues, since it is trivial for a user to generate) associated with that.

I am not suggesting that we ought to allow sending *arbitrary USB commands*; if that is what's needed then use the USB device interface, which of course has its own permission flags. The main problem with that is exactly that it is all-or-nothing (it is also a bit of a pain to find the underlying USB device corresponding to an ACM or USB tty, but that's another matter entirely; it is at least doable.)

As far as BREAK is concerned, there is also the option of locking out a second BREAK for the delay time; however, this probably should belong in the tty core.  What do other drivers supporting TTY_DRIVER_HARDWARE_BREAK do?