Re: [PATCH] crypto: Prevent kernel-infoleak in rng_recvmsg

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Aug 16, 2025 at 05:17:01PM +0800, Herbert Xu wrote:
> On Sat, Aug 09, 2025 at 05:59:43PM +0800, Edward Adam Davis wrote:
>
> > diff --git a/crypto/jitterentropy-kcapi.c b/crypto/jitterentropy-kcapi.c
> > index c24d4ff2b4a8..9e9e069f55af 100644
> > --- a/crypto/jitterentropy-kcapi.c
> > +++ b/crypto/jitterentropy-kcapi.c
> > @@ -107,7 +107,7 @@ int jent_hash_time(void *hash_state, __u64 time, u8 *addtl,
> >  {
> >  	struct shash_desc *hash_state_desc = (struct shash_desc *)hash_state;
> >  	SHASH_DESC_ON_STACK(desc, hash_state_desc->tfm);
> > -	u8 intermediary[SHA3_256_DIGEST_SIZE];
> > +	u8 intermediary[SHA3_256_DIGEST_SIZE] = { 0 };
> 
> This is not a leak! The stack memroy is hashed and fed into the
> entropy pool.  If you can recover the original kernel memory from
> the result, then we have much bigger problems :)
> 
> Please find a way to mark this as a false positive.

I think kmsan_unpoison_memory is the function that you should call.

Cheers,
-- 
Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt




[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]
  Powered by Linux