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: <20180108152858.GH11344@localhost>
Date:   Mon, 8 Jan 2018 16:28:58 +0100
From:   Johan Hovold <johan@...nel.org>
To:     Oliver Neukum <oneukum@...e.com>
Cc:     Mikhail Zaytsev <flashed@...l.ru>, Johan Hovold <johan@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org
Subject: Re: [PATCH v2 1/2] USB: serial: ark3116: Remove unused TIOCSSERIAL
 ioctl case.

On Mon, Jan 08, 2018 at 11:33:32AM +0100, Oliver Neukum wrote:
> Am Samstag, den 06.01.2018, 20:14 +0300 schrieb Mikhail Zaytsev:
> > The patch removes unused TIOCSSERIAL ioctl case and adds the default block
> > to the switch. This will make the ioctl return -ENOTTY to user space (e.g.
> > setserial), because TIOCSSERIAL really isn't supported for these devices
> > currently.
> 
> Hi,
> 
> this will break software that is now running on these devices,
> won't it? Do you know why those devices basically ignore the
> ioctl?

Yeah, that was my initial reactions as well, but then again, any sane
user space cannot rely on these ioctl being implemented for all tty
devices.

I did some digging now and these (dummy) ioctl implementations where
added by commit 2f430b4bbae7 ("USB: ark3116: Add TIOCGSERIAL and
TIOCSSERIAL ioctl calls.") back in 2006.  This in turn appears to have
been triggered by a change in a user space tool, wvdial, which started
erroring out if either was missing.

I found a couple of bug reports about that through google, and looking
at the wvstreams (library) code now, it looks like the issue has indeed
been resolved by handling errors more gracefully (e.g. just logging
them).

So I'm willing to give this a try, and if anyone complains later we add
back (or implement) TIOCSSERIAL.

Sounds reasonable?

Thanks,
Johan

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ