What issues are there while using Linux's /dev/urandom for generating cryptographic keys?
Using /dev/urandom to generate cryptographic keys or secrets can be an issue when the state of the OS is not unique. This is the typically case when a VM was just booted from a template: the state of the CSPRNG could be shared among multiple VMs. In cases similar to this one, it is important to use /dev/random or getrandom() instead of /dev/urandom, so that the output of the CSPRNG blocks until it has collected enough entropy.
Of course, VM clones need to be rebooted or booted up from a shutdown state in order for the entropy count to be reset to zero.
The output of /dev/urandom and /dev/random comes from ChaCha20. To consider it insecure to create cryptographic keys once the inner state of ChaCha20 is initialized with enough entropy, one has to either:

know the inner state of ChaCha20,
or break the ChaCha20 cipher, which is today considered one of the most secure ones.

The remaining issue is how to count entropy. The Linux kernel is extremely conservative on this point, and the inner state of the CSPRNG most likely have far more entropy than counted (around two orders of magnitude more). However, to count it exactly is mathematically impossible.
Disclaimer: This answer is valid for the Linux kernel from version 4.8 to  version 5.9, which is the latest version at the time of writing of this answer. The Linux CSPRNG was heavily refactored in versions 4.8 (introduction of the ChaCha20 cipher) and in version 5.6 (simplification of the architecture), with minor changes introduced in version 4.17 and along the way.