]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/blame - releases/3.10.40/n_tty-fix-n_tty_write-crash-when-echoing-in-raw-mode.patch
4.14-stable patches
[thirdparty/kernel/stable-queue.git] / releases / 3.10.40 / n_tty-fix-n_tty_write-crash-when-echoing-in-raw-mode.patch
CommitLineData
312e9589
GKH
1From 4291086b1f081b869c6d79e5b7441633dc3ace00 Mon Sep 17 00:00:00 2001
2From: Peter Hurley <peter@hurleysoftware.com>
3Date: Sat, 3 May 2014 14:04:59 +0200
4Subject: n_tty: Fix n_tty_write crash when echoing in raw mode
5
6From: Peter Hurley <peter@hurleysoftware.com>
7
8commit 4291086b1f081b869c6d79e5b7441633dc3ace00 upstream.
9
10The tty atomic_write_lock does not provide an exclusion guarantee for
11the tty driver if the termios settings are LECHO & !OPOST. And since
12it is unexpected and not allowed to call TTY buffer helpers like
13tty_insert_flip_string concurrently, this may lead to crashes when
14concurrect writers call pty_write. In that case the following two
15writers:
16* the ECHOing from a workqueue and
17* pty_write from the process
18race and can overflow the corresponding TTY buffer like follows.
19
20If we look into tty_insert_flip_string_fixed_flag, there is:
21 int space = __tty_buffer_request_room(port, goal, flags);
22 struct tty_buffer *tb = port->buf.tail;
23 ...
24 memcpy(char_buf_ptr(tb, tb->used), chars, space);
25 ...
26 tb->used += space;
27
28so the race of the two can result in something like this:
29 A B
30__tty_buffer_request_room
31 __tty_buffer_request_room
32memcpy(buf(tb->used), ...)
33tb->used += space;
34 memcpy(buf(tb->used), ...) ->BOOM
35
36B's memcpy is past the tty_buffer due to the previous A's tb->used
37increment.
38
39Since the N_TTY line discipline input processing can output
40concurrently with a tty write, obtain the N_TTY ldisc output_lock to
41serialize echo output with normal tty writes. This ensures the tty
42buffer helper tty_insert_flip_string is not called concurrently and
43everything is fine.
44
45Note that this is nicely reproducible by an ordinary user using
46forkpty and some setup around that (raw termios + ECHO). And it is
47present in kernels at least after commit
48d945cb9cce20ac7143c2de8d88b187f62db99bdc (pty: Rework the pty layer to
49use the normal buffering logic) in 2.6.31-rc3.
50
51js: add more info to the commit log
52js: switch to bool
53js: lock unconditionally
54js: lock only the tty->ops->write call
55
56References: CVE-2014-0196
57Reported-and-tested-by: Jiri Slaby <jslaby@suse.cz>
58Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
59Signed-off-by: Jiri Slaby <jslaby@suse.cz>
60Cc: Linus Torvalds <torvalds@linux-foundation.org>
61Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
62Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
63
64---
65 drivers/tty/n_tty.c | 4 ++++
66 1 file changed, 4 insertions(+)
67
68--- a/drivers/tty/n_tty.c
69+++ b/drivers/tty/n_tty.c
70@@ -2066,8 +2066,12 @@ static ssize_t n_tty_write(struct tty_st
71 if (tty->ops->flush_chars)
72 tty->ops->flush_chars(tty);
73 } else {
74+ struct n_tty_data *ldata = tty->disc_data;
75+
76 while (nr > 0) {
77+ mutex_lock(&ldata->output_lock);
78 c = tty->ops->write(tty, b, nr);
79+ mutex_unlock(&ldata->output_lock);
80 if (c < 0) {
81 retval = c;
82 goto break_out;