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]
Message-Id: <20201124004902.1398477-1-minyard@acm.org>
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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ