Re: [PATCH] Fix possible strscpy() buffer overflows

[Borislav Petkov]

On Mon, May 11, 2026 at 01:13:05PM +0000, Andrei Purdea wrote:
> But this wasn't spelled out explicitly in the doc, because you're not
> really supposed to use strlen() to specify the destination buffer
> size.

Why am I not supposed to? Says who?

> Why would that be safer? There's already a strlen() call inside
> strscpy.

Do you mean this thing:

        sized_strscpy(dst, src, sizeof(dst) + __must_be_array(dst) +    \
				^^^^^^^^^^
                                __must_be_cstr(dst) + __must_be_cstr(src))

?

> (and even if you don't want to read the implementation, the
> documentation implies this, by saying "Copy the string", because bytes

How about documents it properly?

Obviously this new interface can confuse people...

> Plus strscpy_pad() needs to know the actual destination buffer size to

Oh boy.

IOW, before you use this function, ignore all the comments and read the source
completely and fully. Why am I even hoping for something better...

> know how many bytes to pad if you want to pad.  If you give it a 3rd
> argument, then most of the time it's gonna be less then the size of the
> buffer, so it's not gonna do any padding at all, so it's just gonna be
> equivalent to strscpy() without _pad()


Lemme explain:

It should be written there explicitly so that whoever touches this code, can
go and *think* hard first what the source and destination are. Do they make
sense, what happens if she or he writes a string in there which is bigger than
RPMSG_NAME_SIZE - 1 and then wonders why this fancy strscpy truncates it?

In this particular case, it would be better to avoid this silly string copy
altogether.

Because obviously using that interface is not trivial.

So let's see what Shubhrajyoti finds out.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette