Open d33tah opened 8 years ago
Ah, that's very possible...
I'm swamped with a big deadline on Friday, but I'll take a look after that!
Wow, that's a quick reply! Thanks, I'd love to have this bug fixed.
So after that amazing quick reply, I finally had a chance to look into this two months later :-)
I pushed a partial fix that at least stops the stdin synchronization on stdin EOF, but stdout is trickier. There's no EOF; we just sit waiting for the fake-fd to have an event on it. Not exactly sure how to fix it yet... Let me know if you have any ideas!
On Tue, Nov 10, 2015 at 3:54 AM, Jacek Wielemborek <notifications@github.com
wrote:
Wow, that's a quick reply! Thanks, I'd love to have this bug fixed.
— Reply to this email directly or view it on GitHub https://github.com/zardus/preeny/issues/15#issuecomment-155400716.
I realize this issue is quite old, but is there a reason not to call shutdown()
on STDIN EOF? I needed this for fuzzing an event-driven program to indicate that there will be no more input.
Consider the following
sock.py
Python file:Now run
ncat -l --sh-exec 'echo 1' -k
and then the file above and observe the behavior. Then try:You will see that while without
dsesock.so
the program would exit, turning it on causes an infinite loop. I believe thatrecvrom
should fail if we hit an EOF. Perhaps somehow exiting the loop or closing the pipe in such case could cause that, letting the fuzzed processes avoid an infinite loop?