linux-kernel - Re: [PATCH] USB: cdc-acm: expose serial close_delay and closing

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 for Android: free password hash cracker in your pocket

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

Date:   Fri, 25 Aug 2023 01:46:15 +0200
From:   Oliver Neukum <oneukum@...e.com>
To:     Simon Arlott <simon@...iron.net>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Oliver Neukum <oneukum@...e.com>,
        Jiri Slaby <jirislaby@...nel.org>,
        linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org,
        linux-serial@...r.kernel.org
Subject: Re: [PATCH] USB: cdc-acm: expose serial close_delay and closing_wait
 in sysfs



On 24.08.23 20:02, Simon Arlott wrote:
  
> It's not practical to use TIOCGSERIAL from a udev rule. Instead of a
> sysfs attribute (that udev has built-in support for writing) it would
> require a separate compiled process or other non-trivial dependencies
> (e.g. Python) to modify the closing_wait value. There's no shell script
> support for read-modify-write of a complex ioctl struct.

That, however, is a deficiency of udev.

> The ioctl can't be used without opening and closing the tty, which has
> side effects. On open() it'll raise DTR/RTS and activate it. For cdc-acm
> that will indicate to the device that the serial port has been opened
> which will be visible to the software running on the USB device. On
> close() it'll be delayed by the close_delay if any process is currently
> doing a blocking open() and there's no carrier, then the closing_wait
> time if there's been any incomplete transmitted data (by any process).

And that is an issue of the generic serial layer.
  
> Those two values require CAP_SYS_ADMIN to modify (which is separately
> enforced by many of the tty drivers) so user applications can't change
> them even if they're aware of them.

That is even more damning. Either something is protected by a capability
or it is not. Such a protection must not be circumvented.

	Regards
		Oliver