Re: [PATCH v2] crypto: sun4i-ss - clamp PRNG seed length to prevent heap overflow

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [Critical] The PRNG hardware state is shared globally across all crypto API instances, allowing unprivileged users to predictably control the RNG state for others.
- [High] The PRNG seed buffer size incorrectly depends on BITS_PER_LONG, causing seed truncation and halving entropy on 64-bit systems.
- [High] sun4i_ss_prng_seed modifies the shared PRNG seed buffer without taking the required device spinlock.
- [High] The driver fails to validate that the provided seed length is sufficient before updating the PRNG seed state.
- [High] sun4i_ss_prng_generate silently ignores trailing bytes when the requested length is not a multiple of 4, leaving parts of the caller's buffer uninitialized.
--

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

This commit clamps the copy length in sun4i_ss_prng_seed() to prevent a
heap overflow when a user supplies an oversized seed via AF_ALG. It uses
min_t to restrict the length to the size of the destination seed buffer.

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

[Severity: Critical]
This is a pre-existing issue, but the PRNG hardware state is shared globally
across all crypto API instances. Since there is no per-tfm context and the
driver registers as stdrng with priority 300, can an unprivileged user open
an AF_ALG socket and use setsockopt to inject a chosen seed here? This would
allow them to predict the sequence of random numbers generated for other
processes or kernel subsystems relying on the same RNG.

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

[Severity: High]
This is a pre-existing issue, but does this function modify the shared PRNG
seed buffer without taking the required device spinlock? In
sun4i_ss_prng_generate(), the code acquires spin_lock_bh(&ss->slock) before
accessing the buffer. Concurrent calls to sun4i_ss_prng_seed() and generate
could cause a data race resulting in torn state.

> +	memcpy(algt->ss->seed, seed, min_t(unsigned int, slen, sizeof(algt->ss->seed)));

[Severity: High]
This is a pre-existing issue, but does the seed buffer size incorrectly
depend on BITS_PER_LONG? If the driver defines the seed array using
SS_SEED_LEN / BITS_PER_LONG, on 64-bit systems this becomes an array of 3
elements (12 bytes) instead of the expected 24 bytes. This would mean the
sizeof() calculation silently truncates valid 24-byte seeds to 12 bytes and
fails to initialize half of the PRNG hardware seed registers.

>  
>  	return 0;

[Severity: High]
This is a pre-existing issue, but does this function fail to validate that
the provided seed length is sufficient? If a caller provides an undersized
seed, the memcpy will partially update the array, but the function will
still unconditionally return 0. Should the code return an error when the
seed is too small instead of signaling a successful reseeding?

>  }

[Severity: High]
This is a pre-existing issue, but looking at sun4i_ss_prng_generate(), if
the requested length is not a multiple of 4, the remaining bytes are
silently ignored while still returning 0 (success). Does this leave portions
of the caller's buffer completely uninitialized, potentially causing
information disclosure or cryptographic vulnerabilities if predictable memory
is used as key material?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/4d4407c05835a50413fa1e974e3aa3f4abfe2d5b@linux.dev?part=1