linux-kernel - Re: PROBLEM: Data corruption when pasting large data to terminal

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGWcZkK=DYW8bxP1iLoy35zuakUNE_7WHJ+-3n1BSobrFRQ61w@mail.gmail.com>
Date:	Thu, 16 Feb 2012 02:12:33 +0100
From:	Egmont Koblinger <egmont@...il.com>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: PROBLEM: Data corruption when pasting large data to terminal

On Thu, Feb 16, 2012 at 01:54, Greg KH <gregkh@...uxfoundation.org> wrote:

>> - so: the data gets lost after writing to /dev/ptmx, but before
>> reading it out from /dev/pts/N.
>
> Which it will, if the reader doesn't read fast enough, right?  Is the
> data somewhere guaranteed to never "overrun" the buffer?  If so, how do
> we handle not just running out of memory?

If the buffer is full, the write() into /dev/ptmx should signal it by
returning a smaller-than-requested number (short write), or 0 or it
should block (perhaps depending on whether the fd is in blocking mode)
-- am I correct?  If the write() returns 68 whereas actually it stored
15 bytes and threw out the rest, then there's no way applications
could handle this.  As I said, stracing the terminal tells me that the
terminal wrote 68 bytes 100 times, and all hundred times the write()
call returned 68, not less.

> I bet you can write a simple userspace program that also does this
> correctly, have you tried that?  That might be best to provide a "tiny"
> reproducer.
>
> Odds are bash and python don't do things properly, as they aren't
> accustomed to such large buffers coming in at this rate of speed.  They
> are designed for this type of thing, while vim is used to it.

Again: stracing bash reveals that it reads from its stdin byte by
byte, and at one point it read()s a '3' character followed by a '\n'
with the next read() - something that never occurs in the input.

I wish I had a simpler test case, but I don't have yet.

Anyway, I'm not looking at the internals of the terminal or the
application, I'm observing the interface where they talk to the pty,
and what I see is that the terminal writes the correct stuff, and the
application receives a garbled one.  Whatever bash does with that data
later on is irrelevant, isn't it?


> If you can trace something down in the kernel to point to where we are
> doing something wrong, I would be glad to look at it.  But without that,
> there's not much I can do here, sorry.

I still can't understand why the two strace outputs are not convincing
enough.  I'm also uncertain what the desired behavior would be if one
tries to write to ptmx while the kernel's buffer is full.


thanks,
e.
--
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/