linux-kernel - Re: [PATCH] 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] [thread-next>] [day] [month] [year] [list]

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

On Tue, Oct 05, 2021 at 09:26:21AM +0200, Roberto Sassu wrote:
> Access the string at len - 1 instead of len.
> 
> Signed-off-by: Roberto Sassu <roberto.sassu@...wei.com>
> ---
>  arch/s390/lib/string.c | 12 ++++++------
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/s390/lib/string.c b/arch/s390/lib/string.c
> index cfcdf76d6a95..162a391788ad 100644
> --- a/arch/s390/lib/string.c
> +++ b/arch/s390/lib/string.c
> @@ -261,12 +261,12 @@ char *strrchr(const char *s, int c)
>  {
>         size_t len = __strend(s) - s;
>  
> -       if (len)
> -	       do {
> -		       if (s[len] == (char) c)
> -			       return (char *) s + len;
> -	       } while (--len > 0);
> -       return NULL;
> +	if (len)
> +		do {
> +			if (s[len - 1] == (char) c)
> +				return (char *) s + len - 1;
> +		} while (--len > 0);
> +	return NULL;

You missed to tell what this is supposed to fix. The patch however is
incorrect: the terminating null byte is considered part of the
string. With your patch strrchr(somestring, 0) would not work
correctly anymore.

However our strrchr implementation is indeed broken, since for an
empty string and searching for the null byte would incorrectly return
NULL. Luckily there is not a single invocation in the kernel which
doing that.