linux-kernel - Re: [PATCH] crypto: qcom-rng - fix infinite loop on requests not multiple of WORD

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-prev] [day] [month] [year] [list]

Date:   Sat, 7 May 2022 10:41:32 +0200
From:   Ondrej Mosnacek <omosnace@...hat.com>
To:     Brian Masney <bmasney@...hat.com>
Cc:     Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        "David S. Miller" <davem@...emloft.net>,
        linux-arm-msm@...r.kernel.org,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        Linux kernel mailing list <linux-kernel@...r.kernel.org>,
        Linux Stable maillist <stable@...r.kernel.org>
Subject: Re: [PATCH] crypto: qcom-rng - fix infinite loop on requests not
 multiple of WORD_SZ

On Tue, May 3, 2022 at 6:11 PM Brian Masney <bmasney@...hat.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/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@...r.kernel.org
> > Signed-off-by: Ondrej Mosnacek <omosnace@...hat.com>
>
> Reviewed-by: Brian Masney <bmasney@...hat.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@...r.kernel.org', you'll see
that most commits don't include the version hint any more.

-- 
Ondrej Mosnacek
Software Engineer, Linux Security - SELinux kernel
Red Hat, Inc.