Linux random poll panics when kernel returns POLLIN|POLLRDNORM

[SebTardif]

Bug

In library/std/src/sys/random/linux.rs:143, the code uses:

assert_eq!(fd.revents, libc::POLLIN);

The Linux kernel's random_poll() function returns EPOLLIN | EPOLLRDNORM. When the kernel sets both flags in revents, the strict equality assertion panics even though the poll succeeded normally.

This affects any Linux system where the RNG is not yet initialized during early boot (the poll-for-readiness path).

Fix

Use a bitwise check: assert!(fd.revents & libc::POLLIN != 0) to verify POLLIN is set without requiring it to be the only flag.

[SebTardif]

Upstream context and cross-reference

This bug was introduced in rust-lang/rust PR #129201 by @joboet (Sep 2024) as part of the std::random Linux implementation.

The same class of bug (strict assert_eq! on poll() revents instead of bitwise check) was previously found and fixed in connect_timeout via rust-lang/rust PR #45269. The getrandom crate avoids this entirely by not checking revents at all, only the return value of poll().

Why the fix is correct: Linux poll(2) can return additional bits in revents beyond what was requested in events. The man page states that POLLERR, POLLHUP, and POLLNVAL can appear even if not requested. POLLRDNORM (value 0x40) is commonly OR'd with POLLIN (0x01) on some kernels/devices. The correct check is fd.revents & libc::POLLIN != 0, not assert_eq!(fd.revents, libc::POLLIN).

No upstream issue exists for this specific bug. Related upstream issues:

• Tracking Issue for secure random data generation in std rust-lang/rust#130703 (tracking issue for std::random)
• TcpStream::connect_timeout doesn't fail to connect to a nonexistent server on Linux rust-lang/rust#45265 (same class of bug, fixed in connect_timeout)
• panic on linux at rust/library/std/src/sys/random/linux.rs:107: out of range for slice of length 16 rust-lang/rust#156446 (different panic in same file)

Fix with regression test: PR #382

[joboet]

@SebTardif

I don't normally appreciate being pinged in random issues. Still, your repo contains a number of interesting issues. Do you have plans for reporting them upstream? I can help with verifying the issues if you need it (just copy-pasting the LLM finds into upstream issues won't be accepted).

As for this issue, I don't think it is accurate: poll is documented to only return the bits in revents that were requested in events (aside from error bits). I've filed rust-lang#158125 to add a test (the LLM hallucinated a completely nonsensical "regression test" in its fix).