dd does not handle input from pipes correctly (coreutils-5.93)

[Paul Mielke]

Dear Coreutils Maintainers,

We just discovered a bug in dd running on Tao Linux release 1.  I
downloaded the source from GNU for coreutils-5.93 and believe that
I have confirmed the bug by looking at the code.

The problem is this:  if input is from stdin and stdin is a pipe, the
routine dd_copy assumes that a short read returned from "iread"
means that it has read a partial record.  But pipes (and for that
matter fifos or sockets) do not behave as disk files do:  the POSIX
spec specifically says that you may get short reads from pipes
even when not at EOF.

Sorry to be lazy and not submit a fix with the bug, but I believe the
fix would be to make the routine "iread" keep trying to fill the requested
buffer size until it gets a real EOF or SIGPIPE.

The easiest way to see the bug is to do something like:

dd if=/dev/urandom of=foo count=3
dd if=/dev/urandom of=pad bs=16k count=1

cat foo pad | dd of=foo.padded bs=16k count=1

When the failure occurs, foo.padded ends up being shorter than 16k.

It doesn't fail on all systems, but we have one system on which
this fails repeatably.  We looked at it with "strace" and you can
see that the dd getting input from the pipe does a read of 16k,
gets 8k back and then proceeds to close the input pipe.

If you count a short read as a partial record, the code at line 1414
causes the main copy loop to terminate in this case, since
max_records == 1.

Regards,
Paul


Paul Mielke                         address@hidden
BroadOn Communications    (650) 739-5377