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: <fa20ab91-5ebf-427d-b938-31ea6fb945cf@suse.com>
Date: Wed, 16 Jul 2025 10:29:27 +0200
From: Oliver Neukum <oneukum@...e.com>
To: "H. Peter Anvin" <hpa@...or.com>, 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 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