linux-kernel - Re: Large pastes into readline enabled programs causes breakage from v2.6.31 onwards

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 03 Dec 2013 13:01:01 +0400
From:	Stas Sergeev <stsp@...t.ru>
To:	Peter Hurley <peter@...leysoftware.com>
CC:	Margarita Manterola <margamanterola@...il.com>,
	Maximiliano Curia <maxy@...servers.com.ar>,
	Stas Sergeev <stsp@...rs.sourceforge.net>,
	Pavel Machek <pavel@....cz>,
	Arkadiusz Miskiewicz <a.miskiewicz@...il.com>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	linux-kernel@...r.kernel.org,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Jiri Slaby <jslaby@...e.cz>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Caylan Van Larson <i@...lan.net>
Subject: Re: Large pastes into readline enabled programs causes breakage from
 v2.6.31 onwards

03.12.2013 04:18, Peter Hurley пишет:
> Unfortunately, this patch breaks EOF push handling.
>
> Normally, when an EOF is found not at the line start, the output
> is made available to a canonical reader (without the EOF) -- this is
> commonly referred to as EOF push. An EOF at the beginning of a line
> forces the read to return 0 bytes read, which the caller interprets
> as an end-of-file and discontinues reading.
>
> Since this patch simulates an EOF push, an actual EOF push that
> follows will appear to be an EOF at the beginning of a line and
> cause read to return 0, thus indicating premature end-of-file.
>
> I've attached a simulation testcase that shows the unexpected EOF.
>
> I think this general approach is still the way forward with this bug
> but I need to ponder how the simulated EOF push state can properly be
> distinguished from the other eol conditions in canon_copy_from_read_buf()
> so line_start is not reset to the read_tail.
Hi Peter, why do you think this is even a problem?
If you enable icanon and the first thing you did was
to send VEOF, then you need an EOF.
If you want to be backward-compatible, you'll likely need
to go that route, because currently it works exactly that
way, except that the read buffer is lost. Other than preserving
the read buffer, my patch was not supposed to change anything.
I already have a program (written, tested, went to customer,
used in production, oops sorry:) that switches to icanon and
sends VEOF to simulate EOF. If you change this, then the behaviour
will depend on whether the reader happened to read the data
while still in RAW mode or already in icanon mode, which will
create an unfixable race.

I think the only reliable and consistent fix would be to add ioctls
for EOF and EOL pushes. Then people will not even need to switch
back-n-forth like crazy. But as things are now, I think my patch
is conservative and safe. Do you think it can break something real,
other than the test-case? I think your test-case was made with the
particular patch in mind, but it is not compatible with the current
kernel, so it can't be "broken".
--
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/