linux-kernel - [PATCH v2] tty: pty: Fix flush ldisc after userspace see the data already

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]

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