Linux kernel CTR_DRBG: generate can report success while leaving the output buffer uninitialized

CVSS 5.5CVE-2026-64306Kernel, userspace & hypervisorcurated

Impact

drbg_ctr_generate() can return success on a path where it actually failed, so the caller consumes an output buffer that was never filled. Any kernel consumer of the CTR_DRBG - including FIPS-mode configurations where the DRBG is the sanctioned RNG - can therefore receive data it believes is random but is not, with no error to key off. The record does not identify a specific caller or quantify predictability, so treat this as a correctness and assurance problem for kernel-generated key material rather than a demonstrated key-recovery path. It matters on a GPU fleet because the same host kernel image is usually rolled across every node, so a build with this defect is fleet-wide.

Who can reach it

No remote attack path is described in the record. The failure is triggered by the DRBG's own error handling inside the kernel; a local user can reach the CTR_DRBG through the kernel crypto API, but the record does not establish attacker control over the failure condition.

What to do

Take the stable kernel update carrying the fix and reboot each node; there is no runtime toggle for this. On a GPU fleet that means the usual rolling drain-and-reboot, one node at a time, and hosts in FIPS mode should be prioritised because the CTR_DRBG is the approved generator there. Distribution kernel-livepatch coverage for this commit is not stated in the record.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-64306 https://git.kernel.org/stable/c/074db6db03a0aaa78f05ca9d4838053713796665 https://git.kernel.org/stable/c/23b8b188cb32e5531d0f8d3af9506f8959cb369e https://git.kernel.org/stable/c/7b03312491f9fe6ba4d60c4023e7e61d2d1fed96

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.