should asprintf and friends guarantee sane pointer on failure?

[Eric Blake]

This thread in oss-security was an interesting read:
https://www.openwall.com/lists/oss-security/2024/07/26/2

it spawned this ongoing thread in glibc:
https://inbox.sourceware.org/libc-alpha/871q3cqy0j.fsf@oldenburg.str.redhat.com/

I'm wondering if gnulib should guarantee that asprintf() and friends
always set the pointer to a free()able value, even on failure (where
the obvious assignment would be NULL), so that we aren't leaving the
door open for subtle security issues down the road.  POSIX Issue 8
recently standardized asprintf(), but intentionally allows the older
glibc behavior of leaving the pointer unchanged on failure (which
risks the pointer being uninitialized and therefore unsafe to free()
except on success of asprintf), but it ALSO allows even worse behavior
where a libc that is inconsistent on whether the pointer is changed
(altered on some error paths but not others) could lead to a memory
leak or other risky behaviors on failure.

Here's an example of code that in pam_systemd that depends on old
glibc behavior of leaving the pointer unchanged on failure, which
means that any change to glibc may need versioned symbols:

https://bugs.freedesktop.org/show_bug.cgi?id=90017

But for gnulib, I can argue that being able to unconditionally call
free(ptr) after asprintf(&ptr,...) is probably an easier coding
paradigm to guarantee (in part because BSD libc guarantees it) than
leaving ptr unspecified (may or may not be changed on error) or
untouched (what glibc used to do, but POSIX doesn't guarantee it and
it requires more boilerplate to check correctly so more programs are
likely to get it wrong, including the oss-security post about getting
it wrong turning into a security bug).

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization:  qemu.org | libguestfs.org