linux-kernel - [PATCH 0/2] drivers:tty:pty: Fix a race causing data loss on close

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:   Mon, 23 Nov 2020 18:49:00 -0600
From:   minyard@....org
To:     Jiri Slaby <jirislaby@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Peter Hurley <peter@...leysoftware.com>,
        brian.bloniarz@...il.com
Subject: [PATCH 0/2] drivers:tty:pty: Fix a race causing data loss on close

I finally got some time to spend with this issue, and I think I have a
good fix.  Not really a v2, this is a completely different fix.
Basically, calling tty_vhangup() on the slave when closing a pty master
is just a bad idea.

>From what I can tell, the tty_vhangup() is there in case there was a
console redirect to the pty slave.  When you close the master, you need
to release the redirect.  I didn't see another reason for tty_vhangup().
So this has two parts, export the release of the tty redirect release
for the pty code to use, and call it from the pty code.

With this change, everything seems to work ok and no data is lost on the
slave side if the master closes with outstanding data.  I have updated
my test program to check that all written data is read, it's available
at https://sourceforge.net/projects/ser2net/files/tmp/testpty.c/download

But, this code is quite intricate and I certainly may have missed
something.

-corey