man/man3/malloc.3: STANDARDS, HISTORY, BUGS: Clarify (non)conformance of realloc...

Link: <https://nabijaczleweli.xyz/content/blogn_t/017-malloc0.html>
Link: <https://sourceware.org/pipermail/libc-alpha/1999-April/000956.html>
Link: <https://inbox.sourceware.org/libc-alpha/nbyurzcgzgd5rdybbi4no2kw5grrc32k63svf7oq73nfcbus5r@77gry66kpqfr/>
Link: <https://inbox.sourceware.org/libc-alpha/20241019014002.3684656-1-siddhesh@sourceware.org/T/#u>
Link: <https://inbox.sourceware.org/libc-alpha/qukfe5yxycbl5v7ooskvqdnm3au3orohbx4babfltegi47iyly@or6dgf7akeqv/T/#u>
Link: <https://github.com/bminor/glibc/commit/7c2b945e1fd64e0a5a4dbd6ae6592a7314dcd4b5>
Link: <https://github.com/llvm/llvm-project/issues/113065>
Link: <https://www.austingroupbugs.net/view.php?id=400>
Link: <https://www.austingroupbugs.net/view.php?id=526>
Link: <https://www.austingroupbugs.net/view.php?id=688>
Link: <https://sourceware.org/bugzilla/show_bug.cgi?id=12547>
Link: <https://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_400.htm>
Link: <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n868.htm>
Link: <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2438.htm>
Link: <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2464.pdf>
Link: <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3621.txt>
Link: <https://pubs.opengroup.org/onlinepubs/9699919799.2008edition/functions/realloc.html>
Link: <https://pubs.opengroup.org/onlinepubs/9699919799.2013edition/functions/realloc.html>
Link: <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120744>
Link: <https://lore.kernel.org/lkml/20220213182443.4037039-1-keescook@chromium.org/>
Link: <https://awakened1712.github.io/hacking/hacking-whatsapp-gif-rce/>
Link: <https://gbhackers.com/whatsapp-double-free-vulnerability/>
Cc: <bug-gnulib@gnu.org>
Cc: <musl@lists.openwall.com>
Cc: <libc-alpha@sourceware.org>
Cc: наб <nabijaczleweli@nabijaczleweli.xyz>
Cc: Douglas McIlroy <douglas.mcilroy@dartmouth.edu>
Cc: Paul Eggert <eggert@cs.ucla.edu>
Cc: Robert Seacord <rcseacord@gmail.com>
Cc: Elliott Hughes <enh@google.com>
Cc: Bruno Haible <bruno@clisp.org>
Cc: JeanHeyd Meneide <phdofthehouse@gmail.com>
Cc: Rich Felker <dalias@libc.org>
Cc: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
Cc: Joseph Myers <josmyers@redhat.com>
Cc: Florian Weimer <fweimer@redhat.com>
Cc: Andreas Schwab <schwab@suse.de>
Cc: Thorsten Glaser <tg@mirbsd.de>
Cc: Eric Blake <eblake@redhat.com>
Cc: Vincent Lefevre <vincent@vinc17.net>
Cc: Mark Harris <mark.hsj@gmail.com>
Cc: Collin Funk <collin.funk1@gmail.com>
Cc: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
Cc: DJ Delorie <dj@redhat.com>
Cc: Cristian Rodríguez <cristian@rodriguez.im>
Cc: Siddhesh Poyarekar <siddhesh@gotplt.org>
Cc: Sam James <sam@gentoo.org>
Cc: Mark Wielaard <mark@klomp.org>
Cc: "Maciej W. Rozycki" <macro@redhat.com>
Cc: Martin Uecker <ma.uecker@gmail.com>
Cc: Christopher Bazley <chris.bazley.wg14@gmail.com>
Cc: Eskil Steenberg <eskil@obsession.se>
Cc: Terence Kelly <tpkelly@eecs.umich.edu>
Cc: Daniel Krügler <daniel.kruegler@googlemail.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Valdis Klētnieks <valdis.kletnieks@vt.edu>
Signed-off-by: Alejandro Colomar <alx@kernel.org>

diff --git a/man/man3/malloc.3 b/man/man3/malloc.3
index bf0bb276eed32e0c9549b9146c6eb5dd0b0d6478..499dc7db934e79cba5bf9db119e42e45f7f6d8e4 100644 (file)
--- a/man/man3/malloc.3
+++ b/man/man3/malloc.3
@@ -250,10 +250,48 @@ T}        Thread safety   MT-Safe
 .BR calloc ()
 .TQ
 .BR realloc ()
-C11, POSIX.1-2008.
+C23, POSIX.1-2024.
 .TP
 .BR reallocarray ()
-None.
+POSIX.1-2024.
+.SS realloc(p, 0)
+The behavior of
+.I realloc(p,\~0)
+in glibc doesn't conform to any of
+C99,
+C11,
+POSIX.1-2001,
+POSIX.1-2004,
+POSIX.1-2008,
+POSIX.1-2013,
+POSIX.1-2017,
+or POSIX.1-2024.
+The C17 specification was changed to make it conforming,
+but that specification made it
+impossible to write code that reliably
+determines if the input pointer is freed after
+.IR realloc(p,\~0) ,
+and C23 changed it again to make this undefined behavior,
+acknowledging that the C17 specification was broad enough that
+undefined behavior wasn't worse than that.
+.P
+.BR reallocarray ()
+suffers the same issues in glibc.
+.P
+musl libc and the BSDs conform to all versions of ISO C and POSIX.1.
+.P
+gnulib provides the
+.I realloc-posix
+module,
+which provides wrappers
+.BR realloc ()
+and
+.BR reallocarray ()
+that conform to all versions of ISO C and POSIX.1.
+.P
+There's a proposal to standardize the BSD behavior:
+.UR https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3621.txt
+.UE .
 .SH HISTORY
 .TP
 .BR malloc ()
@@ -278,6 +316,18 @@ starting in glibc 2.30.
 preserved
 .I errno
 starting in glibc 2.33.
+.SS realloc(p,\~0)
+C89 was ambiguous in its specification of
+.IR realloc(p,\~0) .
+C99 partially fixed this.
+.P
+The original implementation in glibc would have been conforming to C99.
+However, and ironically,
+trying to comply with C99 before the standard was released,
+glibc changed its behavior in glibc 2.1.1 into something that ended up
+not conforming to the final C99 specification
+(but this is debated,
+as the wording of the standard seems self-contradicting).
 .SH NOTES
 By default, Linux follows an optimistic memory allocation strategy.
 This means that when
@@ -391,6 +441,34 @@ as POSIX and the C standard do not allow replacement of
 .BR calloc (),
 and
 .BR realloc ().
+.SH BUGS
+Programmers would naturally expect by induction that
+.I \%realloc(p,\~size)
+is consistent with
+.I free(p)
+and
+.IR malloc(size) ,
+as that is the behavior in the general case.
+This is not explicitly required by POSIX.1-2024 or C11,
+but all conforming implementations are consistent with that.
+.P
+The glibc implementation of
+.BR realloc ()
+is not consistent with that,
+and as a consequence,
+it is dangerous to call
+.I \%realloc(p,\~0)
+in glibc.
+.P
+A trivial workaround for glibc is calling it as
+.IR \%realloc(p,\~size?size:1) .
+.P
+The workaround for
+.BR reallocarray ()
+in glibc
+\[em]which shares the same bug\[em]
+would be
+.IR \%reallocarray(p,\~n?n:1,\~size?size:1) .
 .SH EXAMPLES
 .EX
 #include <err.h>