linux-kernel - ptrace and pseudoterminals

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

Message-ID: <CAJt8pk_DJbjHFvGiyeg1w62trZjgeGm=2Nrx7iHORCRtXHAyow@mail.gmail.com>
Date:	Tue, 3 Nov 2015 15:16:59 -0800
From:	Pavel Labath <labath@...gle.com>
To:	Oleg Nesterov <oleg@...hat.com>, linux-kernel@...r.kernel.org
Subject: ptrace and pseudoterminals

Hello Oleg, everyone,

I have noticed something, which may be considered a race in the
interaction of ptrace and pseudoterminal interfaces. Basically, what
happens is this:
- we have two processes: A and B. B has the slave end of the pty open,
A has the master. A is tracing B.
- B writes some data through the slave end and then stops.
- A waits for B to stop.
- A does a select on the master pty endpoint. select returns there is
no data available
- later, A tries the select again, and this time the data appears.

We are encountering this (very rare) issue in our debugger test suite,
where we check the stdout of the tracee to make sure it is behaving as
expected. I have attached a small program reproducing this behavior
(it fails after about 1000 iterations on a 3.13.0 kernel, I can retry
it on a newer kernel next week if you believe it might work there).
Interestingly, when I replace the pty with a regular pipe, it works as
expected (the data is available as soon as the program stops).

My question is: Is this behavior something that you would consider a
bug? If yes, do you have any pointers, as to where I should look to
fix it?

kind regards,
pavel

View attachment "pty.c" of type "text/x-csrc" (1628 bytes)