systemd uses malloc_usable_size() everywhere to use memory blocks obtained through malloc, but that is abuse since the malloc_usable_size() interface isn't meant for this kind of use, it is for diagnostics only. This is also why systemd behaviour is flaky when built with _FORTIFY_SOURCE. One way to make this more standard (and hence safer) is to, at every malloc_usable_size() call, also 'reallocate' the block so that the compiler can see the larger size. This is done through a dummy reallocator whose only purpose is to tell the compiler about the larger usable size, it doesn't do any actual reallocation. Florian Weimer pointed out that this doesn't solve the problem of an allocator potentially growing usable size at will, which will break the implicit assumption in systemd use that the value returned remains constant as long as the object is valid. The safest way to fix that is for systemd to step away from using malloc_usable_size() like this. Resolves #22801.
util: make memdup() or friends safer
We recently started making more use of malloc_usable_size() and rely on it (see the string_erase() story). Given that we don't really support sytems where malloc_usable_size() cannot be trusted beyond statistics anyway, let's go fully in and rework GREEDY_REALLOC() on top of it: instead of passing around and maintaining the currenly allocated size everywhere, let's just derive it automatically from malloc_usable_size(). I am mostly after this for the simplicity this brings. It also brings minor efficiency improvements I guess, but things become so much nicer to look at if we can avoid these allocation size variables everywhere. Note that the malloc_usable_size() man page says relying on it wasn't "good programming practice", but I think it does this for reasons that don't apply here: the greedy realloc logic specifically doesn't rely on the returned extra size, beyond the fact that it is equal or larger than what was requested. (This commit was supposed to be a quick patch btw, but apparently we use the greedy realloc stuff quite a bit across the codebase, so this ends up touching *a*lot* of code.)
Reported/found by Coccinelle
This is another attempt at d4b604baeadbb2498e4f2c3e260260eed210f5d6 and #12438 Instead of blindly using the extra allocated space, let's do so only after telling libc about it, via a second realloc(). The second realloc() should be quick, since it never has to copy memory around.
This reverts commit d4b604baeadbb2498e4f2c3e260260eed210f5d6. When realloc() is called, the extra memory between the originally requested size and the end of malloc_usable_size() isn't copied. (at least with the version of glibc that currently ships on Arch Linux) As a result, some elements get lost and use uninitialized memory, most commonly 0, and can lead to crashes. fixes #12384
It's a glibc-specific API, but supported on FreeBSD and musl too at least, hence fairly common. This way we can reduce our calls to realloc() as much as possible.