linux-hardening - Re: [PATCH] crypto: Prevent kernel-infoleak in rng

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMj1kXF4aRL02CKnO5T9kKnvSV=BcMDiD=mDW7CKQx5t_HmaHw@mail.gmail.com>
Date: Tue, 26 Aug 2025 15:51:04 +0200
From: Ard Biesheuvel <ardb@...nel.org>
To: Herbert Xu <herbert@...dor.apana.org.au>, linux-hardening@...r.kernel.org, 
	Kees Cook <kees@...nel.org>
Cc: Edward Adam Davis <eadavis@...com>, syzbot+e8bcd7ee3db6cb5cb875@...kaller.appspotmail.com, 
	davem@...emloft.net, linux-crypto@...r.kernel.org, 
	linux-kernel@...r.kernel.org, syzkaller-bugs@...glegroups.com
Subject: Re: [PATCH] crypto: Prevent kernel-infoleak in rng_recvmsg

(cc Kees)

On Sat, 16 Aug 2025 at 11:17, Herbert Xu <herbert@...dor.apana.org.au> wrote:
>
> On Sat, Aug 09, 2025 at 05:59:43PM +0800, Edward Adam Davis wrote:
> > Initialize the intermediary array member to 0 to prevent the kernel from
> > leaking uninitialized data to user space.
> >
> > Reported-by: syzbot+e8bcd7ee3db6cb5cb875@...kaller.appspotmail.com
> > Closes: https://syzkaller.appspot.com/bug?extid=e8bcd7ee3db6cb5cb875
> > Tested-by: syzbot+e8bcd7ee3db6cb5cb875@...kaller.appspotmail.com
> > Signed-off-by: Edward Adam Davis <eadavis@...com>
> > ---
> >  crypto/jitterentropy-kcapi.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > 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.

Is there still a point to doing this now that the compiler
zero-initializes automatic variables? Or does that not apply to u8
arrays? (asking Kees)