The commit referenced in the Fixes tag removed the 'break' from the else branch in qcom_rng_read(), causing an infinite loop whenever 'max' is not a multiple of WORD_SZ. This can be reproduced e.g. by running:
kcapi-rng -b 67 >/dev/null
There are many ways to fix this without adding back the 'break', but they all seem more awkward than simply adding it back, so do just that.
Tested on a machine with Qualcomm Amberwing processor.
Fixes: a680b1832ced ("crypto: qcom-rng - ensure buffer for generate is completely filled") Cc: stable@vger.kernel.org Signed-off-by: Ondrej Mosnacek omosnace@redhat.com --- drivers/crypto/qcom-rng.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/drivers/crypto/qcom-rng.c b/drivers/crypto/qcom-rng.c index 11f30fd48c141..031b5f701a0a3 100644 --- a/drivers/crypto/qcom-rng.c +++ b/drivers/crypto/qcom-rng.c @@ -65,6 +65,7 @@ static int qcom_rng_read(struct qcom_rng *rng, u8 *data, unsigned int max) } else { /* copy only remaining bytes */ memcpy(data, &val, max - currsize); + break; } } while (currsize < max);
On Tue, May 03, 2022 at 01:50:10PM +0200, Ondrej Mosnacek wrote:
The commit referenced in the Fixes tag removed the 'break' from the else branch in qcom_rng_read(), causing an infinite loop whenever 'max' is not a multiple of WORD_SZ. This can be reproduced e.g. by running:
kcapi-rng -b 67 >/dev/nullThere are many ways to fix this without adding back the 'break', but they all seem more awkward than simply adding it back, so do just that.
Tested on a machine with Qualcomm Amberwing processor.
Fixes: a680b1832ced ("crypto: qcom-rng - ensure buffer for generate is completely filled") Cc: stable@vger.kernel.org Signed-off-by: Ondrej Mosnacek omosnace@redhat.com
Reviewed-by: Brian Masney bmasney@redhat.com
We should add '# 5.17+' to the end of the stable line.
On Tue, May 3, 2022 at 6:11 PM Brian Masney bmasney@redhat.com wrote:
On Tue, May 03, 2022 at 01:50:10PM +0200, Ondrej Mosnacek wrote:
The commit referenced in the Fixes tag removed the 'break' from the else branch in qcom_rng_read(), causing an infinite loop whenever 'max' is not a multiple of WORD_SZ. This can be reproduced e.g. by running:
kcapi-rng -b 67 >/dev/nullThere are many ways to fix this without adding back the 'break', but they all seem more awkward than simply adding it back, so do just that.
Tested on a machine with Qualcomm Amberwing processor.
Fixes: a680b1832ced ("crypto: qcom-rng - ensure buffer for generate is completely filled") Cc: stable@vger.kernel.org Signed-off-by: Ondrej Mosnacek omosnace@redhat.com
Reviewed-by: Brian Masney bmasney@redhat.com
We should add '# 5.17+' to the end of the stable line.
Is that really relied upon any more? AFAIK, the stable maintainer(s) already compute the target versions from the Fixes: tag. And the version based on the original commit would be inaccurate in many cases, as the commit may have been already backported to earlier streams and you need to patch those as well. Thus, I believe it's better to leave out the version hint and force people to look up the Fixes: commit instead, which is more reliable. Also if you grep the latest mainline commits for 'Cc: stable@vger.kernel.org', you'll see that most commits don't include the version hint any more.
linux-stable-mirror@lists.linaro.org
-
Brian Masney -
Ondrej Mosnacek