linux-kernel - commit 83d817f410 broke my ability to use Linux with a braille display

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-next>] [day] [month] [year] [list]

Date:   Fri, 11 Jan 2019 13:33:09 -0500 (EST)
From:   Nicolas Pitre <nico@...xnic.net>
To:     Dmitry Safonov <dima@...sta.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jslaby@...e.cz>
cc:     Mark Rutland <mark.rutland@....com>,
        Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        Tycho Andersen <tycho@...ho.ws>, Dave Mielke <dave@...lke.cc>,
        linux-kernel@...r.kernel.org
Subject: commit 83d817f410 broke my ability to use Linux with a braille
 display

I use Linux with the help of a braille display and the brltty daemon. It 
turns out that the latest mainline kernel I can work with comes from 
commit 231f8fd0cc. Anything past that and I lose the ability to read the 
console barely a few seconds after the system has booted as brltty is 
thrown a wrench and the braille display becomes completely inoperable.

Things get somewhat better with commit c96cf923a9 as brltty is not 
longer incapacitated, but some programs would randomly crash. Even the 
very first login attempt won't work as I soon as I hit enter after my 
user name the password prompt is skipped over, just like if the enter 
key had been hit twice. Then lynx (the text web browser) would crash as 
soon as I switch the virtual console with LeftAlt+FN. Mind you, this 
isn't easy to perform bisection in those conditions.

And the worst commit i.e. 83d817f410 is marked for stable!  :-(

Some interaction with brltty must be at play here otherwise such 
breakage would never have survived up to the mainline kernel.

As far as latest mainline is concerned, I managed to reproduce at least 
one of the unwelcome behavior change (hoping that's all there is to this 
issue) with a very simple test case so you won't have to learn braille 
to debug this:

# from any vt, make sure tty40 is allocated and empty
openvt -c 40 -f -- true

# open it and wait on read()
cat /dev/tty40

# from a second vt, simply open tty40 again
true < /dev/tty40

# come back to the first vt and watch cat bailing out with EAGAIN.

Please fix.

Nicolas