kernel: random: add robust get_random_u32, remove weak get_random_int

The get_random_int function in drivers/char/random.c in the Linux kernel before 2.6.30 produces insufficiently random numbers, which allows attackers to predict the return value, and possibly defeat protection mechanisms based on randomization, via vectors that leverage the function's tendency to "return the same value over and over again for long stretches of time."

The QNAP TS-239 Pro and TS-639 Pro with firmware 2.1.7 0613, 3.1.0 0627, and 3.1.1 0815 use the rand library function to generate a certain recovery key, which makes it easier for local users to determine this key via a brute-force attack.

cgi-bin/makecgi-pro in Iomega StorCenter Pro generates predictable session IDs, which allows remote attackers to hijack active sessions and gain privileges via brute force guessing attacks on the session_id parameter.

Plack::Middleware::Session::Simple versions before 0.05 for Perl generates session ids insecurely

Plack::Middleware::Session::Simple versions before 0.05 for Perl generates session ids insecurely. The default session id generator returns a SHA-1 hash seeded with the built-in rand function, the epoch time, and the PID. The PID will come from a small set of numbers, and the epoch time may be guessed, if it is not leaked from the HTTP Date header. The built-in rand function is unsuitable for cryptographic usage. Predictable session ids could allow an attacker to gain access to systems. Plack::Middleware::Session::Simple is intended to be compatible with Plack::Middleware::Session, which had a similar security issue CVE-2025-40923.

Apache::Session::Generate::MD5 versions through 1.94 for Perl create insecure session id

Apache::Session::Generate::MD5 versions through 1.94 for Perl create insecure session id. Apache::Session::Generate::MD5 generates session ids insecurely. The default session id generator returns a MD5 hash seeded with the built-in rand() function, the epoch time, and the PID. The PID will come from a small set of numbers, and the epoch time may be guessed, if it is not leaked from the HTTP Date header. The built-in rand function is unsuitable for cryptographic usage. Predicable session ids could allow an attacker to gain access to systems. Note that the libapache-session-perl package in some Debian-based Linux distributions may be patched to use Crypt::URandom.

Concierge::Sessions versions from 0.8.1 before 0.8.5 for Perl generate insecure session ids

Concierge::Sessions versions from 0.8.1 before 0.8.5 for Perl generate insecure session ids. The generate_session_id function in Concierge::Sessions::Base defaults to using the uuidgen command to generate a UUID, with a fallback to using Perl's built-in rand function. Neither of these methods are secure, and attackers are able to guess session_ids that can grant them access to systems. Specifically, * There is no warning when uuidgen fails. The software can be quietly using the fallback rand() function with no warnings if the command fails for any reason. * The uuidgen command will generate a time-based UUID if the system does not have a high-quality random number source, because the call does not explicitly specify the --random option. Note that the system time is shared in HTTP responses. * UUIDs are identifiers whose mere possession grants access, as per RFC 9562. * The output of the built-in rand() function is predictable and unsuitable for security applications.

HTTP::Session2 versions before 1.12 for Perl may generate weak session ids using the rand() function

HTTP::Session2 versions before 1.12 for Perl for Perl may generate weak session ids using the rand() function. The HTTP::Session2 session id generator returns a SHA-1 hash seeded with the built-in rand function, the epoch time, and the PID. The PID will come from a small set of numbers, and the epoch time may be guessed, if it is not leaked from the HTTP Date header. The built-in rand() function is unsuitable for cryptographic usage. HTTP::Session2 after version 1.02 will attempt to use the /dev/urandom device to generate a session id, but if the device is unavailable (for example, under Windows), then it will revert to the insecure method described above.

Generation of weak and predictable Initialization Vector (IV) in PMFW (Power Management Firmware) may allow an attacker with privileges to reuse IV values to reverse-engineer debug data, potentially resulting in information disclosure.

COMMGR - Insufficient Randomization Authentication Bypass

Delta Electronics COMMGR v1 and v2 uses insufficiently randomized values to generate session IDs (CWE-338). An attacker could easily brute force a session ID and load and execute arbitrary code.

Crypt::Salt for Perl uses insecure rand() function when generating salts for cryptographic purposes

Crypt::Salt for Perl version 0.01 uses insecure rand() function when generating salts for cryptographic purposes.

The Crypt::Random::Source package before 0.13 for Perl has a fallback to the built-in rand() function, which is not a secure source of random bits.

Data::Entropy for Perl uses insecure rand() function for cryptographic functions

Data::Entropy for Perl 0.007 and earlier use the rand() function as the default source of entropy, which is not cryptographically secure, for cryptographic functions.

Crypt::CBC versions between 1.21 and 3.05 for Perl may use insecure rand() function for cryptographic functions

Crypt::CBC versions between 1.21 and 3.05 for Perl may use the rand() function as the default source of entropy, which is not cryptographically secure, for cryptographic functions. This issue affects operating systems where "/dev/urandom'" is unavailable.  In that case, Crypt::CBC will fallback to use the insecure rand() function.

DBIx::Class::EncodedColumn until 0.00032 for Perl uses insecure rand() function for salting password hashes in Crypt/Eksblowfish/Bcrypt.pm

DBIx::Class::EncodedColumn use the rand() function, which is not cryptographically secure to salt password hashes. This vulnerability is associated with program files Crypt/Eksblowfish/Bcrypt.pm. This issue affects DBIx::Class::EncodedColumn until 0.00032.

DBIx::Class::EncodedColumn until 0.00032 for Perl uses insecure rand() function for salting password hashes in Digest.pm

DBIx::Class::EncodedColumn use the rand() function, which is not cryptographically secure to salt password hashes. This vulnerability is associated with program files lib/DBIx/Class/EncodedColumn/Digest.pm. This issue affects DBIx::Class::EncodedColumn until 0.00032.

Johnson Controls IQ Panels2, 2+, IQHub, IQPanel 4, PowerG use of Cryptographically Weak Pseudo-Random Number Generator

Use of a weak pseudo-random number generator, which may allow an attacker to read or inject encrypted PowerG packets.

perl-Net-OAuth: Default nonce for Net::OAuth package for perl is not cryptographically strong

In Net::OAuth::Client in the Net::OAuth package before 0.29 for Perl, the default nonce is a 32-bit integer generated from the built-in rand() function, which is not cryptographically strong.

Guzzle OAuth Subscriber has insufficient nonce entropy

Guzzle OAuth Subscriber signs Guzzle requests using OAuth 1.0. Prior to 0.8.1, Nonce generation does not use sufficient entropy nor a cryptographically secure pseudorandom source. This can leave servers vulnerable to replay attacks when TLS is not used. This vulnerability is fixed in 0.8.1.

Coturn has unsafe nonce and relay port randomization due to weak random number generation.

coturn is a free open source implementation of TURN and STUN Server. Versions 4.6.2r5 through 4.7.0-r4 have a bad random number generator for nonces and port randomization after refactoring. Additionally, random numbers aren't generated with openssl's RAND_bytes but libc's random() (if it's not running on Windows). When fetching about 50 sequential nonces (i.e., through sending 50 unauthenticated allocations requests) it is possible to completely reconstruct the current state of the random number generator, thereby predicting the next nonce. This allows authentication while spoofing IPs. An attacker can send authenticated messages without ever receiving the responses, including the nonce (requires knowledge of the credentials, which is e.g., often the case in IoT settings). Since the port randomization is deterministic given the pseudorandom seed, an attacker can exactly reconstruct the ports and, hence predict the randomization of the ports. If an attacker allocates a relay port, they know the current port, and they are able to predict the next relay port (at least if it is not used before). Commit 11fc465f4bba70bb0ad8aae17d6c4a63a29917d9 contains a fix.

tgt (aka Linux target framework) before 1.0.93 attempts to achieve entropy by calling rand without srand. The PRNG seed is always 1, and thus the sequence of challenges is always identical.