It's interesting, looks like there's plenty of embarassment to go round.
This function does not just take arbitrary "uninitialized memory" and feed it into the entropy
pool. That would be stupid. It takes a parameter, which is supposed to be an array of entropy
bytes to put into the pool.
I haven't analysed the code enough to see whether the Valgrind reports are triggered by this
function going off the end of the provided buffer, or by the buffer providers (elsewhere in
OpenSSL code) not fully initialising their buffers, or even by a subtle false alarm (Valgrind
is good but it's not perfect, not yet).
In any case, with the patch removing this vital line of code, more or less none of the
intended entropy ends up being used. Entropy from /dev/random, from hardware RNG sources, and
so on, is discarded silently by Debian's patch AFAICT. Hence the list of millions of possible
"bogus" keys which can be generated from the little remaining entropy.
What's fascinating is that when Debian reported this terrible goof today some OpenSSL people
said if they'd come forward with this patch two years ago the OpenSSL developers would have
laughed at the obviously wrong fix... But it seems that Debian people did go to the OpenSSL
developers two years ago, and they got told more or less that if it shuts up Valgrind then
Now in parallel to proposing this goofy patch, someone proposed to Debian a fix which simply
writes zeroes to an uninitialised buffer elsewhere in OpenSSL. This patch seems to have been
rejected by Debian for unclear reasons, but an equivalent change has been included in newer
versions of OpenSSL and from there integrated back into Debian. It is probably one of several
such fixes which should have taken place instead of this silly one line patch that disables
the RNG more or less altogether.