linux-kernel - Re: [PATCH v2] s390: Fix strrchr() implementation

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]

Message-ID: <YVxVg7sgn8PJ5MTk@osiris>
Date:   Tue, 5 Oct 2021 15:39:15 +0200
From:   Heiko Carstens <hca@...ux.ibm.com>
To:     Juergen Gross <jgross@...e.com>
Cc:     Roberto Sassu <roberto.sassu@...wei.com>, gor@...ux.ibm.com,
        borntraeger@...ibm.com, linux-s390@...r.kernel.org,
        linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH v2] s390: Fix strrchr() implementation

On Tue, Oct 05, 2021 at 03:24:33PM +0200, Juergen Gross wrote:
> On 05.10.21 15:14, Heiko Carstens wrote:
> > On Tue, Oct 05, 2021 at 02:08:36PM +0200, Roberto Sassu wrote:
> > > Fix two problems found in the strrchr() implementation for s390
> > > architectures: evaluate empty strings (return the string address instead of
> > > NULL, if '\0' is passed as second argument); evaluate the first character
> > > of non-empty strings (the current implementation stops at the second).
> > > 
> > > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> > > Cc: stable@...r.kernel.org
> > > Reported-by: Heiko Carstens <hca@...ux.ibm.com> (incorrect behavior with empty strings)
> > > Signed-off-by: Roberto Sassu <roberto.sassu@...wei.com>
> > > ---
> > >   arch/s390/lib/string.c | 15 +++++++--------
> > >   1 file changed, 7 insertions(+), 8 deletions(-)
> > 
> > Applied, thanks!
> > 
> 
> Really? I just wanted to write a response: len is unsigned (size_t)
> and compared to be >= 0, which sounds like always true.

Yeah.. I did some out-of-tree tests, but of course using int instead
of unsigned int. However sparse complains also. So this wouldn't have
hit upstream.
Many thanks for pointing this out anyway!