There's no evidence that Intel's RDRAND instruction set has been backdoored, just speculation based on it being a high-profile target for such attacks, and the known nation-state capabilities of introducing subtle silicon-level backdoors into products at the supply chain level. While such a case would be incredibly unlikely to be used in a non-targeted way, and even more unlikely to affect your average user, it's still an interesting concept.
Linux's random number generator implementation (i.e. the one exposed by
/dev/urandom - forget about
/dev/random for now because it's irrelevant for almost every use-case) involves several key components, the most important of which for this discussion are the entropy pool, the mixing system, and the generator itself.
The entropy pool is a block of memory which has data fed into it which is expected to be highly unpredictable. The goal is to introduce enough uncertainty that it is highly infeasible for anyone to guess what the data inside the pool is. The pool does not need to be large; even a few hundred bytes is quite sufficient to be effective.
Each source of data, which might include CPU debug registers, performance counters from the chipset, timing measurements from the display driver and HID, and all sorts of other feeds, are not independently useful as random numbers for cryptography. It is only in combination that they are useful, as in total it becomes very difficult to predict the resultant state. In order to properly combine these sources of data you need a mixing function which allows a set of independently somewhat-predictable values to be coalesced into a single highly unpredictable value, without losing any of that unpredictability in the process, while also being resistant to cases where an attacker controls or knows the value of a small number of the inputs. Cryptographic hash functions are great at this - you can feed in a concatenated string and get a single fixed-length unpredictable result. This output can then be fed into the entropy pool by xor'ing it with the existing data inside it, which has the useful property that even if the attacker knows the output of a single mixing step, it tells them nothing about previous or subsequent steps and should not allow them to predict the pool contents.
/dev/urandom implementation takes contents from the entropy pool, generates a key from them, and uses it to key a pseudorandom function (PRF) constructed from AES in CTR mode. This allows it to generate a huge amount of cryptographically useful random data (many gigabytes) from only a few hundred bits of data in the entropy pool, and do so very quickly (hundreds of megabytes per second). This alleviates the need for continuous sources of random data - even under heavy pressure to product random bits, the PRF only needs re-keying every few seconds, which gives the system time to acquire more data from entropy sources like performance counters.
This is where the concern about RDRAND comes in. The implementation within the kernel does not use the mixing function like other sources do. Instead, its output is directly xor'ed into the entropy pool. This means that a backdoor in the silicon could potentially have knowledge of the pool contents and output complimentary values which produce a predictable or known state, allowing the output of future calls to the RNG to be predicted. If you assume that such a backdoor exists, then the Linux entropy pool construction is vulnerable to such an attack.
Now keep in mind that all of this is highly theoretical. Surreptitiously introducing a silicon-level backdoor to the Intel supply chain is a fairly tall order even for nation states, but that backdoor would also need to be able to discern when to trigger the backdoor in the specific case of an RDRAND instruction execution that is part of the Linux kernel RNG and not just some random other software or driver using it, and also avoid triggering the backdoor during any unit testing (whose code may be identical to that used in the real kernel source). On top of all of that, it would also need to be able to discern the location of the Linux entropy pool in memory and perform the necessary memory reads to implement the backdoor, which is actually a fairly tall order at that level of attack implementation. TL;DR - it'd be one hell of a feat for anyone, even the NSA or GCHQ, to pull off, and I cannot possibly imagine them risking the exposure of that kind of capability by leveraging it against a mass-market product rather than only in targeted cases.
The Linux RDRAND implementation caught Linus Torvalds some flack on the mailing lists, but he steadfastly defends the approach. His argument is that in the case of such a sophisticated hardware attack like that, there are so many other (and easier) ways that the processor could expose cryptographic keys or even provide remote access to the system, and the massive performance increase is worth bypassing the mixer for. With the recent revelations of the Intel AMT vulnerabilities, and the lack of openness and accountability for IME/SMM firmware, it seems quite reasonable to expect that much easier avenues of attack would be preferred.