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>] [day] [month] [year] [list]
Message-ID: <20170212010754.GA6635@udknight>
Date:   Sun, 12 Feb 2017 09:07:54 +0800
From:   Wang YanQing <udknight@...il.com>
To:     gregkh@...uxfoundation.org
Cc:     jslaby@...e.com, peter@...leysoftware.com,
        linux-kernel@...r.kernel.org
Subject: [PATCH v2] tty: pty: Fix flush ldisc after userspace see the data
 already

When tty_buffer_flush calling had been enabled in pty_flush_buffer
(in commit 1d1d14da12e79a6c05fbe1a975401f0f56c93316
 "pty: Fix buffer flush deadlock"), this causes a issue had been
hidden before it.

Don't flush line discipline of another side, because user could see the data
in line discipline through poll, TIOCINQ or FIONREAD already. Current behavior
break the expection of userspace application in below situations.

Example1:
Thread A                                 Thread B
--------                                 --------
n_tty_poll return POLLIN
                                         CTRL-C trigger pty_flush_buffer
                                           tty_buffer_flush
                                             n_tty_flush_buffer
TIOCINQ or FIONREAD
  return zero number of bytes

Example2:
Thread A                                 Thread B
--------                                 --------
TIOCINQ or FIONREAD
  return valid number of bytes

                                         CTRL-C trigger pty_flush_buffer
                                           tty_buffer_flush
                                             n_tty_flush_buffer
n_tty_read still block due to no data

I meet this problem(Example1) in konsole, current behavior cause konsole to hangup
forever.

It has high possibility to trigger the trouble I meet to execute below commands a
few times in konsole, because konsole treat current kernel behavior as EOF:
1:cat BigFile
2:CTRL-C

Fixes: 1d1d14da12e7 ("pty: Fix buffer flush deadlock")
CC: stable@...r.kernel.org # v4.0+
Signed-off-by: Wang YanQing <udknight@...il.com>
---
 Changes:
 v1-v2:
 1: Rewrite the oneline description, subject.
 2: Reword changelog.

 drivers/tty/pty.c | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/tty/pty.c b/drivers/tty/pty.c
index a23fa5e..2b90738 100644
--- a/drivers/tty/pty.c
+++ b/drivers/tty/pty.c
@@ -216,16 +216,11 @@ static int pty_signal(struct tty_struct *tty, int sig)
 static void pty_flush_buffer(struct tty_struct *tty)
 {
 	struct tty_struct *to = tty->link;
-	struct tty_ldisc *ld;
 
 	if (!to)
 		return;
 
-	ld = tty_ldisc_ref(to);
-	tty_buffer_flush(to, ld);
-	if (ld)
-		tty_ldisc_deref(ld);
-
+	tty_buffer_flush(to, NULL);
 	if (to->packet) {
 		spin_lock_irq(&tty->ctrl_lock);
 		tty->ctrl_status |= TIOCPKT_FLUSHWRITE;
-- 
1.8.5.6.2.g3d8a54e.dirty

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ