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

Message-ID: <CAGWcZkK=9tvcXLXpuh4R1AkM4n3RxT6-aE63bp9WtVN-tFiM=Q@mail.gmail.com>
Date:	Mon, 20 Feb 2012 22:29:36 +0100
From:	Egmont Koblinger <egmont@...il.com>
To:	Pavel Machek <pavel@....cz>
Cc:	Bruno Prémont <bonbons@...ux-vserver.org>,
	Greg KH <gregkh@...uxfoundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: PROBLEM: Data corruption when pasting large data to terminal

> What does make a difference though, is the read size (rsz).  The bug
> is reproducible if and only if the read size is a divisor of the
> length of the line excluding the terminating newline (i.e. the length
> of the full line minus one); that is, a divisor of 62 in this example.

Errr, forget this paragraph, this was a bug in my code.  When trying
to emulate readline, rsz should really be 1.  I was not scanning
through the whole buffer looking for a newline, and was looking at an
incorrect offset.  Sorry for the pebkac.

Fixed version attached.  Anyway, the point is still the same, the data
corruption or deadlock are still triggered the same way.

thx,
egmont

View attachment "ptmx3.c" of type "text/x-csrc" (6152 bytes)