linux-kernel - Re: [PATCH 3/3] USB: cdc-acm: fix TIOCGSERIAL implementation

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]

Message-ID: <YG7RiLoscS6VXG7n@hovoldconsulting.com>
Date:   Thu, 8 Apr 2021 11:48:56 +0200
From:   Johan Hovold <johan@...nel.org>
To:     Oliver Neukum <oneukum@...e.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/3] USB: cdc-acm: fix TIOCGSERIAL implementation

On Thu, Apr 08, 2021 at 10:36:46AM +0200, Oliver Neukum wrote:
> Am Mittwoch, den 07.04.2021, 12:28 +0200 schrieb Johan Hovold:
> > TIOCSSERIAL is a horrid, underspecified, legacy interface which for most
> > serial devices is only useful for setting the close_delay and
> > closing_wait parameters.
> > 
> > The xmit_fifo_size parameter could be used to set the hardware transmit
> > fifo size of a legacy UART when it could not be detected, but the
> > interface is limited to eight bits and should be left unset when it is
> > not used.
> 
> OK.
> 
> > Similarly, baud_base could be used to set the uart base clock when it
> > could not be detected, but might as well be left unset when it is not
> > known.
> 
> Well, the devices report it. It is part of the standard.

No, the standard doesn't include anything about a baud-base clock
AFAICT.

> > Fix the cdc-acm TIOCGSERIAL implementation by dropping its custom
> > interpretation of the unused xmit_fifo_size and baud_base fields, which
> > overflowed the former with the URB buffer size and set the latter to the
> > current line speed. Also return the port line number, which is the only
> > other value used besides the close parameters.
> > 
> > Fixes: 18c75720e667 ("USB: allow users to run setserial with cdc-acm")
> > Signed-off-by: Johan Hovold <johan@...nel.org>
> > ---
> >  drivers/usb/class/cdc-acm.c | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> > 
> > diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
> > index 43e31dad4831..b74713518b3a 100644
> > --- a/drivers/usb/class/cdc-acm.c
> > +++ b/drivers/usb/class/cdc-acm.c
> > @@ -929,8 +929,7 @@ static int get_serial_info(struct tty_struct *tty, struct serial_struct *ss)
> >  {
> >  	struct acm *acm = tty->driver_data;
> >  
> > -	ss->xmit_fifo_size = acm->writesize;
> > -	ss->baud_base = le32_to_cpu(acm->line.dwDTERate);
> 
> If we do this, we have a value that can be set, but is not reported.
> That looks a bit strange to me.

Again, no, the baud_base cannot be set and it is unknown and unused.

The only reason to report back baud_base is to support the deprecated
ASYNC_SPD_CUST interface used to set a custom divisor. cdc-acm has never
supported that for obvious reasons.

Johan