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] [day] [month] [year] [list]
Date:	Sat, 28 Sep 2013 19:36:44 +0200
From:	Mikael Pettersson <mikpelinux@...il.com>
To:	Peter Hurley <peter@...leysoftware.com>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Mikael Pettersson <mikpelinux@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] tty: Fix pty master read() after slave closes

Peter Hurley writes:
 > On 09/27/2013 01:27 PM, Peter Hurley wrote:
 > > Commit f95499c3030fe1bfad57745f2db1959c5b43dca8,
 > >    n_tty: Don't wait for buffer work in read() loop
 > > creates a race window which can cause a pty master read()
 > > to miss the last pty slave write(s) and return -EIO instead,
 > > thus signalling the pty slave is closed. This can happen when
 > > the pty slave is written and immediately closed but before the
 > > tty buffer i/o loop receives the new input; the pty master
 > > read() is scheduled, sees its read buffer is empty and the
 > > pty slave has been closed, and exits.
 > >
 > > Because tty_flush_to_ldisc() has significant performance impact
 > > for parallel i/o, rather than revert the commit, special case this
 > > condition (ie., when the read buffer is empty and the 'other' pty
 > > has been closed) and, only then, wait for buffer work to complete
 > > before re-testing if the read buffer is still empty.
 > >
 > > As before, subsequent pty master reads return any available data
 > > until no more data is available, and then returns -EIO to
 > > indicate the pty slave has closed.
 > >
 > > Reported-by: Mikael Pettersson <mikpelinux@...il.com>
 > > Signed-off-by: Peter Hurley <peter@...leysoftware.com>
 > 
 > I tested this patch with the gcc ada ACATS testsuite and got this
 > summary so all seems ok with this patch.
 > 
 > 		=== acats Summary ===
 > # of expected passes		805
 > # of unexpected failures	0
 > 
 > ...
 > 
 > 		=== acats Summary ===
 > # of expected passes		772
 > # of unexpected failures	0
 > 
 > ...
 > 
 > 		=== acats Summary ===
 > # of expected passes		743
 > # of unexpected failures	0
 > 
 > Mikael,
 > 
 > I'd appreciate if you could re-test with this patch and
 > confirm the issue is fixed.

I did a big pile of gcc bootstrap + regression test runs today with
this patch, and everything looks good.  Thus:

Tested-by: Mikael Pettersson <mikpelinux@...il.com>

Thanks,

/Mikael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ