linux-kernel - Re: [PATCH 2/4] tools/nolibc: Fix strlcat() return code and size usage

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: <428e1561-3219-4567-90df-7130013f3468@sdfg.com.ar>
Date: Sun, 18 Feb 2024 16:33:59 -0300
From: Rodrigo Campos <rodrigo@...g.com.ar>
To: Willy Tarreau <w@....eu>
Cc: Thomas Weißschuh <linux@...ssschuh.net>,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/4] tools/nolibc: Fix strlcat() return code and size
 usage

On 2/18/24 07:20, Willy Tarreau wrote:
> Hi Rodrigo,
> 
> 
> OK this looks good to me.

I'll use that version in the next send then, thanks!

> I think your test on src != orig_src is not
> trivial and that testing instead if (len < size) would be better, and
> possibly even shorter.

Fixed that, thanks.

>> Note the "if size < len, then len=size", I couldn't get rid of it because we
>> need to account for the smaller size of dst if we don't get passed it for
>> the return code.
> 
> Please no, again as I mentioned earlier, it's wrong to use strlen(dst) in
> this case: the only situation where we'd accept size < len is if dst is
> already not zero-terminated, which means that strlen() cannot be used, or
> you'd need strnlen() for that, I'm just seeing that we have it, I thought
> we didn't.

Right, sorry.

>> What do you think? Can you make them shorter?
> 
> I don't want to enter that activity again this week-end ;-)  It's sufficient
> here.

haha, fair :)

>> If you like one of these, I can repost with the improved tests too.
> 
> Yeah please check the few points above for your version, make sure to
> clean it up according to the kernel's coding style (empty line after
> variable declaration, */ on the next line for the multi-line comment
> etc) and that's fine.

Will do



Best,
Rodrigo