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....@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