linux-kernel - Re: [RFC PATCH v1 6/6] tools/include/string: Implement `strdup()` and `strndup()`

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]

Date:   Mon, 21 Mar 2022 18:36:37 +0700
From:   Ammar Faizi <ammarfaizi2@...weeb.org>
To:     Willy Tarreau <w@....eu>
Cc:     "Paul E. McKenney" <paulmck@...nel.org>,
        Alviro Iskandar Setiawan <alviro.iskandar@...weeb.org>,
        Nugraha <richiisei@...il.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        GNU/Weeb Mailing List <gwml@...r.gnuweeb.org>
Subject: Re: [RFC PATCH v1 6/6] tools/include/string: Implement `strdup()` and
 `strndup()`

On 3/21/22 2:53 PM, Willy Tarreau wrote:
> Hi Ammar,
[...]
>> +static void free(void *ptr);
>> +static void *malloc(size_t len);
>> +static void *realloc(void *old_ptr, size_t new_size);
> 
> Better include the required h files here.

I can't do that, in nolibc.h, we have something like this:

```
   #include "stdlib.h" <--- We inlcude string.h from here
   #include "string.h" <--- This is a no-op.
```

Note, stdlib.h is included first before string.h, next, in stdlib.h, we
have this:

```
   #include "string.h"

   // malloc, calloc, free here
```

If I include "stdlib.h" in "string.h", it will just be a no-op, and the
declarations will not be taken, because the declarations happen after
#include "string.h". So it doesn't work. It's somewhat circular dependency.

   stdlib.h needs string.h
   string.h needs stdlib.h

One of them must fully see the other before they can use the defined functions
in another header.

Suggestion welcome...

I am thinking of creating a new header just for the forward declarations
where all function declarations live there, we just split off the real
functions' body.

[...]
> 
> This version is suboptimal in terms of code size, CPU usage and memory
> usage. And it even seems it contains a buffer overflow: if the string
> is exactly a multiple of 2048, it seems to me that you'll write the
> trailing zero past the end. Please instead use the more intuitive form
> below (not tested but you get the idea):
> 
> 	size_t len = strlen(str);
> 	char *ret = malloc(len + 1);
> 	if (ret)
> 		memcpy(ret, str, len);
> 	return ret;

Ah right, that's indeed overflow. Will fold this in as you suggested.

[...]
> Here it can cost quite a lot for large values of maxlen. Please just use
> a variant of the proposal above like this one:
> 
> 	size_t len;
> 	char *ret;
> 
> 	len = strlen(str);
> 	if (len > maxlen)
> 		len = maxlen;
> 	ret = malloc(len + 1);
> 	if (ret)
> 		memcpy(ret, str, len);
> 	return ret;

Will take the Alviro's suggestion for this part...

-- 
Ammar Faizi