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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 24 Aug 2021 20:26:10 +0200
From:   Borislav Petkov <>
To:     Len Baker <>
Cc:     Mauro Carvalho Chehab <>,
        Tony Luck <>,
        James Morse <>,
        Robert Richter <>,
        Joe Perches <>,
        David Laight <>,
        Kees Cook <>,,,
Subject: Re: [PATCH v4] EDAC/mc: Prefer strscpy over strcpy

On Tue, Aug 24, 2021 at 12:28:07PM +0200, Len Baker wrote:
> This is a task of the KSPP [1] and the main reason is to clean up the
> proliferation of str*cpy functions in the kernel.

That I understood - you prominently explain where the patches stem from.

What I can't parse is that formulation "previous step". What previous
step do you mean?

> Yes, you are right. The same discussion happened in the v3 review [2] and
> I agree with the reasons that Robert Richter exposed. Using the strlen()
> implementation it is not necessary to check the return code of strcpy and
> we can assume a silent truncation.
> [2]

Ok, looking at the asm, gcc is actually smart enough not to call
strlen() twice on the same buffer.

But then there's this in the strscpy() kernel-doc comment:

"The destination buffer is always NUL terminated, unless it's

so looking at the code, we're merrily decrementing len but nothing's
checking whether len can become 0. Because if it does, strscpy() will

	if (count == 0 || WARN_ON_ONCE(count > INT_MAX))
		return -E2BIG;

so if p ends up pointing to something which is *not* '\0', strlen() will
go off into the weeds.

So I don't care if it doesn't look just as nice - it better be correct
in all cases first.



Powered by blists - more mailing lists