From: Jarkko Sakkinen <jarkko@kernel.org>
To: Eric Biggers <ebiggers@kernel.org>
Cc: linux-crypto@vger.kernel.org,
"Herbert Xu" <herbert@gondor.apana.org.au>,
"Stephan Müller" <smueller@chronox.de>
Subject: Re: [PATCH] crypto: stdrng - Mitigate FIPS RNG failures
Date: Mon, 26 Oct 2026 21:40:12 +0200 [thread overview]
Message-ID: <at-snHAJ69YzcMTc@kernel.org> (raw)
In-Reply-To: <20261026183332.11402-1-ebiggers@kernel.org>
On Mon, Oct 26, 2026 at 11:33:32AM -0700, Eric Biggers wrote:
> If the kernel is booted with fips=1 and jitterentropy fails its health
> check, crypto_stdrng_get_bytes() can return an error and leave its
> output buffer uninitialized.
>
> While the fallibility of the FIPS RNG is by design, leaving the output
> buffer uninitialized lacks practical defense-in-depth, as callers can
> forget to check the error code. For example, the TPM2 driver didn't
> check the error code from ECDH private key generation
> (https://lore.kernel.org/r/20261025211119.138277-1-ebiggers@kernel.org/).
> Thus, fips=1 mode (ironically) caused a vulnerability.
>
> Mitigate such bugs by filling the buffer with get_random_bytes_wait() in
> case of failure. This helps in practice. (For FIPS certifiability it
> makes no difference, as no "approved" entropy is claimed on failure.)
>
> Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Agree with the "practical DoD" part.
> ---
>
> This applies on top of
> https://lore.kernel.org/linux-crypto/20261018204618.104876-1-ebiggers@kernel.org/
>
> crypto/drbg.c | 12 +++++++++++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/crypto/drbg.c b/crypto/drbg.c
> index faa39045bdc6b..f3fed6ded5b5f 100644
> --- a/crypto/drbg.c
> +++ b/crypto/drbg.c
> @@ -561,10 +561,20 @@ int __crypto_stdrng_get_bytes(void *buf, size_t len)
>
> err = crypto_get_default_rng();
> if (err)
> - return err;
> + goto out;
>
> err = crypto_drbg_get_bytes(crypto_default_rng, buf, len, NULL, 0);
> crypto_put_default_rng();
> +
> +out:
> + /*
> + * On failure, fill the buffer using the normal Linux RNG rather than
> + * leave it uninitialized. This provides practical defense-in-depth for
> + * callers that forget to check the error code. (It makes no difference
> + * for FIPS certifications; no entropy is claimed on failure anyway.)
> + */
> + if (err)
> + get_random_bytes_wait(buf, len);
> return err;
> }
> EXPORT_SYMBOL_GPL(__crypto_stdrng_get_bytes);
>
> base-commit: 666d66df25253070cb297cb920b0bcfcfe5eb871
> prerequisite-patch-id: 4c318ab271fa6443e9fe0ac47537515cc2dc6999
> prerequisite-patch-id: 5992995f4dea89d9332b0e33ca1248e3dd672bd8
> prerequisite-patch-id: c38f29a49c34d0fdfdc8466fd64c3d69fb4f0626
> prerequisite-patch-id: 424590a4282a04c94a095d4f059ac0d3a8af44b1
> prerequisite-patch-id: b5e762e41f7f6a68e70f6540ab07ff2a23ae6880
> prerequisite-patch-id: bc08a9f0be6e4f1e25c0e6ab0881f39df60aa632
> prerequisite-patch-id: 487bd5a23a597d190e2794e178266fcb6fc92849
> prerequisite-patch-id: 3c6f92ab77fee4702702f8760514a1bb55a409cb
> prerequisite-patch-id: 1536028517d2aa0bcbc4ec601c18cd8cf5f7d0ad
> prerequisite-patch-id: cb214555f3c44cf2a2e610adfbf60311a3647aa5
> prerequisite-patch-id: cc0998aae8d75e7b09562f8623c132bc21e77a2b
> prerequisite-patch-id: 351a1bcfe1ac87d42c5aa46b867f291aba49caa0
> prerequisite-patch-id: f71bbeee6d6644ca1b464e22f4df891bab45680f
> prerequisite-patch-id: 2f726ebd0df8d5a420cf4a870e0b6973248bf6be
> --
> 2.56.0
>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Br, Jarkko
prev parent reply other threads:[~2026-10-26 19:40 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-26 18:33 [PATCH] crypto: stdrng - Mitigate FIPS RNG failures Eric Biggers
2026-10-26 19:40 ` Jarkko Sakkinen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=at-snHAJ69YzcMTc@kernel.org \
--to=jarkko@kernel.org \
--cc=ebiggers@kernel.org \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=smueller@chronox.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.