crypto: sun4i-ss: restrict PRNG seed length to prevent heap overflow

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(+)
  

Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:

New issues:
- [Critical] The newly added bounds check unconditionally rejects valid seeds and completely breaks PRNG initialization on 64-bit architectures.

Pre-existing issues:
- [Critical] This problem wasn't introduced by this patch, but the PRNG generation function silently truncates unaligned requested lengths, failing to generate random bytes for the remainder of the buffer while still returning success.
- [High] This problem wasn't introduced by this patch, but the patch silently permits undersized seeds, leading to partial seed updates.
- [High] This problem wasn't introduced by this patch, but the PRNG seed is copied into the shared device state without any locking, creating a data race with concurrent PRNG generations.
- [High] This problem wasn't introduced by this patch, but there is a blind read from TXFIFO in PRNG generation without checking if data is available.
--

commit ce68b95827dcfbd778d1a5a3d2de5fd10e821954
Author: Tianchu Chen <flynnnchen@tencent.com>
crypto: sun4i-ss: restrict PRNG seed length to prevent heap overflow

This commit restricts the PRNG seed length in sun4i_ss_prng_seed() to prevent
a heap overflow. Without bounds checking, user-supplied seeds via AF_ALG could
exceed the fixed-size buffer and corrupt adjacent memory.

Fixes: 6298e948215f ("crypto: sunxi-ss - Add Allwinner Security System crypto accelerator")
Cc: stable@vger.kernel.org

> diff --git a/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-prng.c b/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-prng.c
> index 491fcb7b81b40..010fa891c1056 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;

[Severity: Critical]
Does sizeof(algt->ss->seed) unconditionally reject valid seeds?

On 64-bit architectures, BITS_PER_LONG is 64, which makes the evaluation of
SS_SEED_LEN / BITS_PER_LONG result in 3. The seed array becomes u32 seed[3],
yielding a total size of 12 bytes. This would trigger the EINVAL branch for
standard 24-byte seeds and completely break PRNG initialization.

[Severity: High]
This is a pre-existing issue, but does this check silently permit undersized
seeds?

Allowing slen < seedsize enables partial memcpy operations that mix stale
memory with new entropy.

>  	memcpy(algt->ss->seed, seed, slen);

[Severity: High]
This isn't a bug introduced by this patch, but could this copy operation
create a data race?

The PRNG seed is copied into the shared device state without any locking,
which could lead to torn reads or writes with concurrent PRNG generations.

>  
>  	return 0;
>  }

[Severity: Critical]
This problem wasn't introduced by this patch, but are unaligned requested
lengths silently truncated by the generation function?

Looking at sun4i_ss_prng_generate() in the same file:

	unsigned int todo = (dlen / 4) * 4;
	...
	while (todo > 0) {
		...
	}

The unaligned modulo truncation skips remainder bytes while still returning
success. This fails to generate random bytes for the remainder of the buffer
and could potentially leak uninitialized memory to userspace.

[Severity: High]
This is a pre-existing issue, but does the generator perform a blind read
from the TXFIFO?

Looking at sun4i_ss_prng_generate() in the same file:

		/* Read the random data */
		len = min_t(size_t, SS_DATA_LEN / BITS_PER_BYTE, todo);
		readsl(ss->base + SS_TXFIFO, data, len / 4);

This reads from the TXFIFO without checking if data is actually available,
which could fetch unready values before hardware generation completes and
result in predictable or garbage PRNG output.
  

May 28, 2026 at 11:29 PM, sashiko-bot@kernel.org mailto:sashiko-bot@kernel.org  wrote:


> 
> Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
> 
> New issues:
> - [Critical] The newly added bounds check unconditionally rejects valid seeds and completely breaks PRNG initialization on 64-bit architectures.
> 
> Pre-existing issues:
> - [Critical] This problem wasn't introduced by this patch, but the PRNG generation function silently truncates unaligned requested lengths, failing to generate random bytes for the remainder of the buffer while still returning success.
> - [High] This problem wasn't introduced by this patch, but the patch silently permits undersized seeds, leading to partial seed updates.
> - [High] This problem wasn't introduced by this patch, but the PRNG seed is copied into the shared device state without any locking, creating a data race with concurrent PRNG generations.
> - [High] This problem wasn't introduced by this patch, but there is a blind read from TXFIFO in PRNG generation without checking if data is available.
> --
> 
> commit ce68b95827dcfbd778d1a5a3d2de5fd10e821954
> Author: Tianchu Chen <flynnnchen@tencent.com>
> crypto: sun4i-ss: restrict PRNG seed length to prevent heap overflow
> 
> This commit restricts the PRNG seed length in sun4i_ss_prng_seed() to prevent
> a heap overflow. Without bounds checking, user-supplied seeds via AF_ALG could
> exceed the fixed-size buffer and corrupt adjacent memory.
> 
> Fixes: 6298e948215f ("crypto: sunxi-ss - Add Allwinner Security System crypto accelerator")
> Cc: stable@vger.kernel.org
> 
> > 
> > diff --git a/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-prng.c b/drivers/crypto/allwinner/sun4i-ss/sun4i-ss-prng.c
> >  index 491fcb7b81b40..010fa891c1056 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;
> > 
> [Severity: Critical]
> Does sizeof(algt->ss->seed) unconditionally reject valid seeds?
> 
> On 64-bit architectures, BITS_PER_LONG is 64, which makes the evaluation of
> SS_SEED_LEN / BITS_PER_LONG result in 3. The seed array becomes u32 seed[3],
> yielding a total size of 12 bytes. This would trigger the EINVAL branch for
> standard 24-byte seeds and completely break PRNG initialization.
> 


sun4i-ss is designed for 32-bit ARM only (A10/A13/A20/A33). It's behind
ARCH_SUNXI in Kconfig so it never builds on 64-bit. On the real hardware
sizeof(ss->seed) is always 24, same as .seedsize.
  

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,
  

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