The argument is that RDRAND may have access to the previously generated OTP. If that is true, a malicious RDRAND can cancel out any randomness from that OTP. In that case the "incredibly powerful encryption algorithm" XOR can be tricked to generate a stream of zeros, shakespeares complete works, or whatever you like.
Agreed. However any form of "tricking" would be ultimately pointless because a small adjustment could be made to random.c. Existing CPUs can't be "changed" (barring microcode, but avoiding that is simple - don't install new microcode) so they would no longer work against the system.
In addition the amount of transistors required to actively circumvent random.c is prohibitive: CPUs would need to be significantly larger to pull off attacks like this.
Who the christ is feeding the output of /dev/random for its use as a cryptographic function without checking that what they read is in fact NOT just a stream of zeroes? Because that's an outcome which can happen from any truly random number generator just by chance - its unlikely, but not unreasonable.
