From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Peter Hurley <peter@hurleysoftware.com>
Cc: Stas Sergeev <stsp@list.ru>,
Margarita Manterola <margamanterola@gmail.com>,
linux-kernel@vger.kernel.org,
One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>,
Caylan Van Larson <i@caylan.net>,
Maximiliano Curia <maxy@gnuservers.com.ar>,
Pavel Machek <pavel@ucw.cz>,
Arkadiusz Miskiewicz <a.miskiewicz@gmail.com>
Subject: Re: [PATCH v4] n_tty: Fix buffer overruns with larger-than-4k pastes
Date: Mon, 16 Dec 2013 16:57:19 -0800 [thread overview]
Message-ID: <20131217005719.GA26381@kroah.com> (raw)
In-Reply-To: <1386713522-6959-1-git-send-email-peter@hurleysoftware.com>
On Tue, Dec 10, 2013 at 05:12:02PM -0500, Peter Hurley wrote:
> readline() inadvertently triggers an error recovery path when
> pastes larger than 4k overrun the line discipline buffer. The
> error recovery path discards input when the line discipline buffer
> is full and operating in canonical mode and no newline has been
> received. Because readline() changes the termios to non-canonical
> mode to read the line char-by-char, the line discipline buffer
> can become full, and then when readline() restores termios back
> to canonical mode for the caller, the now-full line discipline
> buffer triggers the error recovery.
>
> When changing termios from non-canon to canon mode and the read
> buffer contains data, simulate an EOF push _without_ the
> DISABLED_CHAR in the read buffer.
>
> Importantly for the readline() problem, the termios can be
> changed back to non-canonical mode without changes to the read
> buffer occurring; ie., as if the previous termios change had not
> happened (as long as no intervening read took place).
>
> Preserve existing userspace behavior which allows '\0's already
> received in non-canon mode to be read as '\0's in canon mode
> (rather than trigger add'l EOF pushes or an actual EOF).
>
> Patch based on original proposal and discussion here
> https://bugzilla.kernel.org/show_bug.cgi?id=55991
> by Stas Sergeev <stsp@users.sourceforge.net>
>
> Reported-by: Margarita Manterola <margamanterola@gmail.com>
> Cc: Maximiliano Curia <maxy@gnuservers.com.ar>
> Cc: Pavel Machek <pavel@ucw.cz>
> Cc: Arkadiusz Miskiewicz <a.miskiewicz@gmail.com>
> Acked-by: Stas Sergeev <stsp@users.sourceforge.net>
> Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
> ---
Is this a 3.13-final thing, or can it wait for 3.14-rc1?
thanks,
greg k-h
next prev parent reply other threads:[~2013-12-17 0:57 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-25 11:29 Large pastes into readline enabled programs causes breakage from v2.6.31 onwards Margarita Manterola
2013-07-25 23:09 ` Peter Hurley
2013-07-30 12:41 ` Maximiliano Curia
[not found] ` <20130730124117.41DC55E4006@freak.gnuservers.com.ar>
2013-07-30 16:08 ` Peter Hurley
2013-08-08 17:58 ` Maximiliano Curia
2013-08-17 15:28 ` Pavel Machek
2013-08-17 22:57 ` Margarita Manterola
2013-08-18 8:08 ` Geert Uytterhoeven
2013-09-03 5:17 ` Arkadiusz Miskiewicz
2013-10-24 16:00 ` Arkadiusz Miskiewicz
2013-10-29 13:50 ` Maximiliano Curia
2013-10-30 11:21 ` Peter Hurley
2013-11-17 18:29 ` Pavel Machek
2013-11-17 21:38 ` Margarita Manterola
2013-11-21 5:04 ` Peter Hurley
2013-11-22 12:57 ` Peter Hurley
2013-11-24 0:29 ` One Thousand Gnomes
2013-11-24 11:55 ` Peter Hurley
2013-11-26 1:16 ` Peter Hurley
2013-12-03 0:18 ` Peter Hurley
2013-12-03 9:01 ` Stas Sergeev
2013-12-03 17:00 ` Peter Hurley
2013-12-03 19:18 ` Stas Sergeev
2013-12-03 23:53 ` Peter Hurley
2013-12-04 18:57 ` Stas Sergeev
2013-12-09 14:50 ` [PATCH v3] n_tty: Fix buffer overruns with larger-than-4k pastes Peter Hurley
[not found] ` <52A5EF3F.2070805@list.ru>
2013-12-09 17:10 ` Peter Hurley
2013-12-10 6:15 ` Stas Sergeev
2013-12-10 22:05 ` Peter Hurley
2013-12-10 22:12 ` [PATCH v4] " Peter Hurley
2013-12-17 0:57 ` Greg Kroah-Hartman [this message]
2013-12-17 1:24 ` Peter Hurley
2013-12-18 11:48 ` Henrique de Moraes Holschuh
2013-12-18 13:41 ` Peter Hurley
2014-01-28 12:03 ` Large pastes into readline enabled programs causes breakage from v2.6.31 onwards Pavel Machek
2014-01-28 12:17 ` Stas Sergeev
2014-01-28 13:31 ` Peter Hurley
2013-08-19 12:25 ` Peter Hurley
2013-09-03 21:12 ` Maximiliano Curia
2013-09-12 1:36 ` Peter Hurley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131217005719.GA26381@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=a.miskiewicz@gmail.com \
--cc=gnomes@lxorguk.ukuu.org.uk \
--cc=i@caylan.net \
--cc=linux-kernel@vger.kernel.org \
--cc=margamanterola@gmail.com \
--cc=maxy@gnuservers.com.ar \
--cc=pavel@ucw.cz \
--cc=peter@hurleysoftware.com \
--cc=stsp@list.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome