drivers/crypto/allwinner/sun4i-ss/sun4i-ss-prng.c | 2 ++ 1 file changed, 2 insertions(+)
From: Tianchu Chen <flynnnchen@tencent.com>
sun4i_ss_prng_seed() copies the user-supplied seed into ss->seed
using the user-provided length with no bounds check. The crypto core
does not enforce slen <= seedsize before calling into the driver, so a
userspace caller via AF_ALG setsockopt(ALG_SET_KEY) can pass up to
sysctl_optmem_max bytes, overflowing the fixed-size buffer and
corrupting adjacent heap memory.
Add a length check rejecting seeds larger than the buffer.
Discovered by Atuin - Automated Vulnerability Discovery Engine.
Fixes: 6298e948215f ("crypto: sunxi-ss - Add Allwinner Security System crypto accelerator")
Cc: stable@vger.kernel.org
Signed-off-by: Tianchu Chen <flynnnchen@tencent.com>
---
drivers/crypto/allwinner/sun4i-ss/sun4i-ss-prng.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-prng.c b/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-prng.c
index 491fcb7b8..010fa891c 100644
--- a/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-prng.c
+++ b/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-prng.c
@@ -8,6 +8,8 @@ int sun4i_ss_prng_seed(struct crypto_rng *tfm, const u8 *seed,
struct rng_alg *alg = crypto_rng_alg(tfm);
algt = container_of(alg, struct sun4i_ss_alg_template, alg.rng);
+ if (slen > sizeof(algt->ss->seed))
+ return -EINVAL;
memcpy(algt->ss->seed, seed, slen);
return 0;
--
2.51.0
On Thu, May 28, 2026 at 02:53:17PM +0000, Tianchu Chen wrote: > > diff --git a/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-prng.c b/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-prng.c > index 491fcb7b8..010fa891c 100644 > --- a/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-prng.c > +++ b/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-prng.c > @@ -8,6 +8,8 @@ int sun4i_ss_prng_seed(struct crypto_rng *tfm, const u8 *seed, > struct rng_alg *alg = crypto_rng_alg(tfm); > > algt = container_of(alg, struct sun4i_ss_alg_template, alg.rng); > + if (slen > sizeof(algt->ss->seed)) > + return -EINVAL; This should simply ignore the extra data instead of failing. Thanks, -- Email: Herbert Xu <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
May 29, 2026 at 2:11 PM, "Herbert Xu" <herbert@gondor.apana.org.au mailto:herbert@gondor.apana.org.au?to=%22Herbert%20Xu%22%20%3Cherbert%40gondor.apana.org.au%3E > wrote: > > On Thu, May 28, 2026 at 02:53:17PM +0000, Tianchu Chen wrote: > > > > > diff --git a/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-prng.c b/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-prng.c > > index 491fcb7b8..010fa891c 100644 > > --- a/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-prng.c > > +++ b/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-prng.c > > @@ -8,6 +8,8 @@ int sun4i_ss_prng_seed(struct crypto_rng *tfm, const u8 *seed, > > struct rng_alg *alg = crypto_rng_alg(tfm); > > > > algt = container_of(alg, struct sun4i_ss_alg_template, alg.rng); > > + if (slen > sizeof(algt->ss->seed)) > > + return -EINVAL; > > > This should simply ignore the extra data instead of failing. Thanks for pointing out, silent truncation is more appropriate here. I'll send a v2 patch with min_t soon. Best regards, Tianchu Chen
From: Tianchu Chen <flynnnchen@tencent.com>
sun4i_ss_prng_seed() copies the user-supplied seed into ss->seed
using the user-provided length with no bounds check. The crypto core
does not enforce slen <= seedsize before calling into the driver, so a
userspace caller via AF_ALG setsockopt(ALG_SET_KEY) can pass up to
sysctl_optmem_max bytes, overflowing the fixed-size buffer and
corrupting adjacent heap memory.
Clamp the copy length to the buffer size, matching the approach used by
loongson-rng for oversized seeds.
Discovered by Atuin - Automated Vulnerability Discovery Engine.
Fixes: 6298e948215f ("crypto: sunxi-ss - Add Allwinner Security System crypto accelerator")
Cc: stable@vger.kernel.org
Signed-off-by: Tianchu Chen <flynnnchen@tencent.com>
---
v2: Silently clamp oversized seeds with min_t instead of returning
-EINVAL (Herbert Xu).
drivers/crypto/allwinner/sun4i-ss/sun4i-ss-prng.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-prng.c b/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-prng.c
index 491fcb7b8..7f6a51dd8 100644
--- a/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-prng.c
+++ b/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-prng.c
@@ -8,7 +8,7 @@ int sun4i_ss_prng_seed(struct crypto_rng *tfm, const u8 *seed,
struct rng_alg *alg = crypto_rng_alg(tfm);
algt = container_of(alg, struct sun4i_ss_alg_template, alg.rng);
- memcpy(algt->ss->seed, seed, slen);
+ memcpy(algt->ss->seed, seed, min_t(unsigned int, slen, sizeof(algt->ss->seed)));
return 0;
}
--
2.51.0
On Fri, May 29, 2026 at 08:08:01AM +0000, Tianchu Chen wrote:
> From: Tianchu Chen <flynnnchen@tencent.com>
>
> sun4i_ss_prng_seed() copies the user-supplied seed into ss->seed
> using the user-provided length with no bounds check. The crypto core
> does not enforce slen <= seedsize before calling into the driver, so a
> userspace caller via AF_ALG setsockopt(ALG_SET_KEY) can pass up to
> sysctl_optmem_max bytes, overflowing the fixed-size buffer and
> corrupting adjacent heap memory.
>
> Clamp the copy length to the buffer size, matching the approach used by
> loongson-rng for oversized seeds.
>
> Discovered by Atuin - Automated Vulnerability Discovery Engine.
>
> Fixes: 6298e948215f ("crypto: sunxi-ss - Add Allwinner Security System crypto accelerator")
> Cc: stable@vger.kernel.org
> Signed-off-by: Tianchu Chen <flynnnchen@tencent.com>
> ---
> v2: Silently clamp oversized seeds with min_t instead of returning
> -EINVAL (Herbert Xu).
sun4i-ss-prng.c is useless, is still broken, and should just be deleted.
- Eric
Le Fri, May 29, 2026 at 09:10:57AM -0700, Eric Biggers a écrit :
> On Fri, May 29, 2026 at 08:08:01AM +0000, Tianchu Chen wrote:
> > From: Tianchu Chen <flynnnchen@tencent.com>
> >
> > sun4i_ss_prng_seed() copies the user-supplied seed into ss->seed
> > using the user-provided length with no bounds check. The crypto core
> > does not enforce slen <= seedsize before calling into the driver, so a
> > userspace caller via AF_ALG setsockopt(ALG_SET_KEY) can pass up to
> > sysctl_optmem_max bytes, overflowing the fixed-size buffer and
> > corrupting adjacent heap memory.
> >
> > Clamp the copy length to the buffer size, matching the approach used by
> > loongson-rng for oversized seeds.
> >
> > Discovered by Atuin - Automated Vulnerability Discovery Engine.
> >
> > Fixes: 6298e948215f ("crypto: sunxi-ss - Add Allwinner Security System crypto accelerator")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Tianchu Chen <flynnnchen@tencent.com>
> > ---
> > v2: Silently clamp oversized seeds with min_t instead of returning
> > -EINVAL (Herbert Xu).
>
> sun4i-ss-prng.c is useless, is still broken, and should just be deleted.
Hello
useless ? clearly no, it helped a lot on devices where it is.
Regards
On Fri, May 29, 2026 at 07:10:06PM +0200, Corentin Labbe wrote:
> Le Fri, May 29, 2026 at 09:10:57AM -0700, Eric Biggers a écrit :
> > On Fri, May 29, 2026 at 08:08:01AM +0000, Tianchu Chen wrote:
> > > From: Tianchu Chen <flynnnchen@tencent.com>
> > >
> > > sun4i_ss_prng_seed() copies the user-supplied seed into ss->seed
> > > using the user-provided length with no bounds check. The crypto core
> > > does not enforce slen <= seedsize before calling into the driver, so a
> > > userspace caller via AF_ALG setsockopt(ALG_SET_KEY) can pass up to
> > > sysctl_optmem_max bytes, overflowing the fixed-size buffer and
> > > corrupting adjacent heap memory.
> > >
> > > Clamp the copy length to the buffer size, matching the approach used by
> > > loongson-rng for oversized seeds.
> > >
> > > Discovered by Atuin - Automated Vulnerability Discovery Engine.
> > >
> > > Fixes: 6298e948215f ("crypto: sunxi-ss - Add Allwinner Security System crypto accelerator")
> > > Cc: stable@vger.kernel.org
> > > Signed-off-by: Tianchu Chen <flynnnchen@tencent.com>
> > > ---
> > > v2: Silently clamp oversized seeds with min_t instead of returning
> > > -EINVAL (Herbert Xu).
> >
> > sun4i-ss-prng.c is useless, is still broken, and should just be deleted.
>
> Hello
>
> useless ? clearly no, it helped a lot on devices where it is.
The only way this code is reachable is via "rng" algorithm type in
AF_ALG, which is almost never used. Everyone just uses the regular
Linux RNG (/dev/random etc) instead, as they should.
In fact, anyone were to accidentally use this it would be a security
vulnerability, seeing as sun4i_ss_prng_generate() doesn't actually fill
in all the bytes that were requested. It also doesn't wait for the FIFO
to be ready when reading data from it.
Is it possible that there's a misunderstanding here and you think this
provides entropy to the regular Linux RNG? It doesn't. hwrng does
that, crypto_rng does not.
The correct fix is to mark CRYPTO_DEV_SUN8I_CE_PRNG as BROKEN or remove
it entirely. Doing otherwise is not responsible.
- Eric
Le Fri, May 29, 2026 at 05:33:41PM +0000, Eric Biggers a écrit :
> On Fri, May 29, 2026 at 07:10:06PM +0200, Corentin Labbe wrote:
> > Le Fri, May 29, 2026 at 09:10:57AM -0700, Eric Biggers a écrit :
> > > On Fri, May 29, 2026 at 08:08:01AM +0000, Tianchu Chen wrote:
> > > > From: Tianchu Chen <flynnnchen@tencent.com>
> > > >
> > > > sun4i_ss_prng_seed() copies the user-supplied seed into ss->seed
> > > > using the user-provided length with no bounds check. The crypto core
> > > > does not enforce slen <= seedsize before calling into the driver, so a
> > > > userspace caller via AF_ALG setsockopt(ALG_SET_KEY) can pass up to
> > > > sysctl_optmem_max bytes, overflowing the fixed-size buffer and
> > > > corrupting adjacent heap memory.
> > > >
> > > > Clamp the copy length to the buffer size, matching the approach used by
> > > > loongson-rng for oversized seeds.
> > > >
> > > > Discovered by Atuin - Automated Vulnerability Discovery Engine.
> > > >
> > > > Fixes: 6298e948215f ("crypto: sunxi-ss - Add Allwinner Security System crypto accelerator")
> > > > Cc: stable@vger.kernel.org
> > > > Signed-off-by: Tianchu Chen <flynnnchen@tencent.com>
> > > > ---
> > > > v2: Silently clamp oversized seeds with min_t instead of returning
> > > > -EINVAL (Herbert Xu).
> > >
> > > sun4i-ss-prng.c is useless, is still broken, and should just be deleted.
> >
> > Hello
> >
> > useless ? clearly no, it helped a lot on devices where it is.
>
> The only way this code is reachable is via "rng" algorithm type in
> AF_ALG, which is almost never used. Everyone just uses the regular
> Linux RNG (/dev/random etc) instead, as they should.
>
> In fact, anyone were to accidentally use this it would be a security
> vulnerability, seeing as sun4i_ss_prng_generate() doesn't actually fill
> in all the bytes that were requested. It also doesn't wait for the FIFO
> to be ready when reading data from it.
>
> Is it possible that there's a misunderstanding here and you think this
> provides entropy to the regular Linux RNG? It doesn't. hwrng does
> that, crypto_rng does not.
>
I believe to have used rngd for that. ( or something like that)
Anyway, I understand why want to remove it.
On Mon, Jun 01, 2026 at 04:57:21PM +0200, Corentin Labbe wrote:
> Le Fri, May 29, 2026 at 05:33:41PM +0000, Eric Biggers a écrit :
> > On Fri, May 29, 2026 at 07:10:06PM +0200, Corentin Labbe wrote:
> > > Le Fri, May 29, 2026 at 09:10:57AM -0700, Eric Biggers a écrit :
> > > > On Fri, May 29, 2026 at 08:08:01AM +0000, Tianchu Chen wrote:
> > > > > From: Tianchu Chen <flynnnchen@tencent.com>
> > > > >
> > > > > sun4i_ss_prng_seed() copies the user-supplied seed into ss->seed
> > > > > using the user-provided length with no bounds check. The crypto core
> > > > > does not enforce slen <= seedsize before calling into the driver, so a
> > > > > userspace caller via AF_ALG setsockopt(ALG_SET_KEY) can pass up to
> > > > > sysctl_optmem_max bytes, overflowing the fixed-size buffer and
> > > > > corrupting adjacent heap memory.
> > > > >
> > > > > Clamp the copy length to the buffer size, matching the approach used by
> > > > > loongson-rng for oversized seeds.
> > > > >
> > > > > Discovered by Atuin - Automated Vulnerability Discovery Engine.
> > > > >
> > > > > Fixes: 6298e948215f ("crypto: sunxi-ss - Add Allwinner Security System crypto accelerator")
> > > > > Cc: stable@vger.kernel.org
> > > > > Signed-off-by: Tianchu Chen <flynnnchen@tencent.com>
> > > > > ---
> > > > > v2: Silently clamp oversized seeds with min_t instead of returning
> > > > > -EINVAL (Herbert Xu).
> > > >
> > > > sun4i-ss-prng.c is useless, is still broken, and should just be deleted.
> > >
> > > Hello
> > >
> > > useless ? clearly no, it helped a lot on devices where it is.
> >
> > The only way this code is reachable is via "rng" algorithm type in
> > AF_ALG, which is almost never used. Everyone just uses the regular
> > Linux RNG (/dev/random etc) instead, as they should.
> >
> > In fact, anyone were to accidentally use this it would be a security
> > vulnerability, seeing as sun4i_ss_prng_generate() doesn't actually fill
> > in all the bytes that were requested. It also doesn't wait for the FIFO
> > to be ready when reading data from it.
> >
> > Is it possible that there's a misunderstanding here and you think this
> > provides entropy to the regular Linux RNG? It doesn't. hwrng does
> > that, crypto_rng does not.
> >
>
> I believe to have used rngd for that. ( or something like that)
>
> Anyway, I understand why want to remove it.
rngd doesn't use AF_ALG. So no, it couldn't have used this driver.
- Eric
On Fri, May 29, 2026 at 05:33:41PM +0000, Eric Biggers wrote:
> On Fri, May 29, 2026 at 07:10:06PM +0200, Corentin Labbe wrote:
> > Le Fri, May 29, 2026 at 09:10:57AM -0700, Eric Biggers a écrit :
> > > On Fri, May 29, 2026 at 08:08:01AM +0000, Tianchu Chen wrote:
> > > > From: Tianchu Chen <flynnnchen@tencent.com>
> > > >
> > > > sun4i_ss_prng_seed() copies the user-supplied seed into ss->seed
> > > > using the user-provided length with no bounds check. The crypto core
> > > > does not enforce slen <= seedsize before calling into the driver, so a
> > > > userspace caller via AF_ALG setsockopt(ALG_SET_KEY) can pass up to
> > > > sysctl_optmem_max bytes, overflowing the fixed-size buffer and
> > > > corrupting adjacent heap memory.
> > > >
> > > > Clamp the copy length to the buffer size, matching the approach used by
> > > > loongson-rng for oversized seeds.
> > > >
> > > > Discovered by Atuin - Automated Vulnerability Discovery Engine.
> > > >
> > > > Fixes: 6298e948215f ("crypto: sunxi-ss - Add Allwinner Security System crypto accelerator")
> > > > Cc: stable@vger.kernel.org
> > > > Signed-off-by: Tianchu Chen <flynnnchen@tencent.com>
> > > > ---
> > > > v2: Silently clamp oversized seeds with min_t instead of returning
> > > > -EINVAL (Herbert Xu).
> > >
> > > sun4i-ss-prng.c is useless, is still broken, and should just be deleted.
> >
> > Hello
> >
> > useless ? clearly no, it helped a lot on devices where it is.
>
> The only way this code is reachable is via "rng" algorithm type in
> AF_ALG, which is almost never used. Everyone just uses the regular
> Linux RNG (/dev/random etc) instead, as they should.
>
> In fact, anyone were to accidentally use this it would be a security
> vulnerability, seeing as sun4i_ss_prng_generate() doesn't actually fill
> in all the bytes that were requested. It also doesn't wait for the FIFO
> to be ready when reading data from it.
>
> Is it possible that there's a misunderstanding here and you think this
> provides entropy to the regular Linux RNG? It doesn't. hwrng does
> that, crypto_rng does not.
>
> The correct fix is to mark CRYPTO_DEV_SUN8I_CE_PRNG as BROKEN or remove
> it entirely. Doing otherwise is not responsible.
Looking into it a bit more, just removing CRYPTO_DEV_SUN4I_SS_PRNG is
clearly the way to go. This patch does it:
https://lore.kernel.org/linux-crypto/20260529193648.18172-1-ebiggers@kernel.org
- Eric
© 2016 - 2026 Red Hat, Inc.