From alx at kernel.org Sat Jun 21 19:10:58 2025 From: alx at kernel.org (Alejandro Colomar) Date: Sat, 21 Jun 2025 21:10:58 +0200 Subject: Bug in reallocf(3) when calling realloc(3) Message-ID: <5pxe5f7s74pmrvw5fntv7llx46x6a4d6s4yt6tjrpkjcv54pny@fu27o3vwhw3u> Bon dia Guillem, I've just checked the implementation of reallocf(3bsd), and it looks like it has a memory leak. Admittedly, a small one, but I just wanted to report it. I'll suggest two proposals, plus keeping the status quo, and explain the advantages of each of them. Here's the current code in libbsd: $ grepc -tfd reallocf . ./src/reallocf.c:void * reallocf(void *ptr, size_t size) { void *nptr; nptr = realloc(ptr, size); /* * When the System V compatibility option (malloc "V" flag) is * in effect, realloc(ptr, 0) frees the memory and returns NULL. * So, to avoid double free, call free() only when size != 0. * realloc(ptr, 0) can't fail when ptr != NULL. */ if (!nptr && ptr && size != 0) free(ptr); return (nptr); } The last sentence in that comment is false. realloc(nonnull,0) can fail in systems in which realloc(nonnull,0) normally returns non-null, such as the BSDs or musl. Let's say the system is unable to find enough space for the metadata necessary for the new 0-sized block of memory. It would return NULL and keep the old pointer intact. I've CCed musl@ so that they can verify that this is true on their implementation. I didn't see anything in their code suggesting that it can't fail. The same also seems to be true in FreeBSD, if I'm reading correctly. I've also CCed them, so that they can confirm, and also because the libbsd implementation is pasted from FreeBSD, so they have the same bug. So, assuming that r(p,0) can indeed fail, there are two alternatives that are portable to every POSIX system: a) Check ENOMEM. void * reallocf(void *ptr, size_t size) { int e; void *nptr; e = errno; errno = 0; nptr = realloc(ptr, size); if (nptr == NULL) { if (errno == ENOMEM) free(ptr); return NULL; } errno = e; return nptr; } This approach is very complex, although it is the most pedantically correct approach (unless I introduced accidentally some bug, which might happen, due to the difficulty of calling realloc(3) portably; blame SysV). b) Don't do that at all; pass a dummy size of 1. void * reallocf(void *ptr, size_t size) { void *nptr; nptr = realloc(ptr, size ? size : 1); if (nptr == NULL) free(ptr); return nptr; } This approach is the simplest, and it's portable to all realloc(3)s that have ever existed. However, it allocates one byte too much, which has a bad consequence: it can hide logic errors where the programmer is accessing one byte after the requested size. Sanitizers would think that the :1 was done on purpose, and thus be silent. c) You could keep the memory leak. It should be very rare, I guess. But you never know. I think b) is simple enough and the drawback is also rare enough (because a logic error that only manifests for a size of 0 should be rare, even though not impossible). BTW, I'm working on a proposal to restore the traditional specification of realloc(3), the one that allocates a zero-sized object (returns non-null), the one inherited from Unix V7. There's some support, and i think it might pass in the C Committee and the Austin Group. But feel free to chime in and voice your support if you're interested in it. Have a lovely day! Alex -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From alx at kernel.org Sat Jun 21 19:37:06 2025 From: alx at kernel.org (Alejandro Colomar) Date: Sat, 21 Jun 2025 21:37:06 +0200 Subject: [musl] Bug in reallocf(3) when calling realloc(3) In-Reply-To: <20250621192751.GL1827@brightrain.aerifal.cx> References: <5pxe5f7s74pmrvw5fntv7llx46x6a4d6s4yt6tjrpkjcv54pny@fu27o3vwhw3u> <20250621192751.GL1827@brightrain.aerifal.cx> Message-ID: Hi Rich, On Sat, Jun 21, 2025 at 03:27:51PM -0400, Rich Felker wrote: > On Sat, Jun 21, 2025 at 09:10:58PM +0200, Alejandro Colomar wrote: > > Bon dia Guillem, > > > > I've just checked the implementation of reallocf(3bsd), and it looks > > like it has a memory leak. Admittedly, a small one, but I just wanted > > to report it. I'll suggest two proposals, plus keeping the status quo, > > and explain the advantages of each of them. > > > > Here's the current code in libbsd: > > > > $ grepc -tfd reallocf . > > ./src/reallocf.c:void * > > reallocf(void *ptr, size_t size) > > { > > void *nptr; > > > > nptr = realloc(ptr, size); > > > > /* > > * When the System V compatibility option (malloc "V" flag) is > > * in effect, realloc(ptr, 0) frees the memory and returns NULL. > > * So, to avoid double free, call free() only when size != 0. > > * realloc(ptr, 0) can't fail when ptr != NULL. > > */ > > if (!nptr && ptr && size != 0) > > free(ptr); > > return (nptr); > > } > > > > The last sentence in that comment is false. realloc(nonnull,0) can fail > > in systems in which realloc(nonnull,0) normally returns non-null, such > > as the BSDs or musl. Let's say the system is unable to find enough > > space for the metadata necessary for the new 0-sized block of memory. > > It would return NULL and keep the old pointer intact. > > > > I've CCed musl@ so that they can verify that this is true on their > > implementation. I didn't see anything in their code suggesting that it > > can't fail. > > Yes this is true. realloc returning null *always* indicates failure > (and accordingly, memory has not been freed) in our past and current > implementations, and indeed it can fail when resizing down (to zero or > otherwise). Thanks! BTW, my message didn't reach freebsd-bugs@, as I'm not subscribed. If anyone is subscribed to that list and can resend my message, or can CC a FreeBSD mainainer, it would be good. Have a lovely day! Alex -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From dalias at libc.org Sat Jun 21 19:27:51 2025 From: dalias at libc.org (Rich Felker) Date: Sat, 21 Jun 2025 15:27:51 -0400 Subject: [musl] Bug in reallocf(3) when calling realloc(3) In-Reply-To: <5pxe5f7s74pmrvw5fntv7llx46x6a4d6s4yt6tjrpkjcv54pny@fu27o3vwhw3u> References: <5pxe5f7s74pmrvw5fntv7llx46x6a4d6s4yt6tjrpkjcv54pny@fu27o3vwhw3u> Message-ID: <20250621192751.GL1827@brightrain.aerifal.cx> On Sat, Jun 21, 2025 at 09:10:58PM +0200, Alejandro Colomar wrote: > Bon dia Guillem, > > I've just checked the implementation of reallocf(3bsd), and it looks > like it has a memory leak. Admittedly, a small one, but I just wanted > to report it. I'll suggest two proposals, plus keeping the status quo, > and explain the advantages of each of them. > > Here's the current code in libbsd: > > $ grepc -tfd reallocf . > ./src/reallocf.c:void * > reallocf(void *ptr, size_t size) > { > void *nptr; > > nptr = realloc(ptr, size); > > /* > * When the System V compatibility option (malloc "V" flag) is > * in effect, realloc(ptr, 0) frees the memory and returns NULL. > * So, to avoid double free, call free() only when size != 0. > * realloc(ptr, 0) can't fail when ptr != NULL. > */ > if (!nptr && ptr && size != 0) > free(ptr); > return (nptr); > } > > The last sentence in that comment is false. realloc(nonnull,0) can fail > in systems in which realloc(nonnull,0) normally returns non-null, such > as the BSDs or musl. Let's say the system is unable to find enough > space for the metadata necessary for the new 0-sized block of memory. > It would return NULL and keep the old pointer intact. > > I've CCed musl@ so that they can verify that this is true on their > implementation. I didn't see anything in their code suggesting that it > can't fail. Yes this is true. realloc returning null *always* indicates failure (and accordingly, memory has not been freed) in our past and current implementations, and indeed it can fail when resizing down (to zero or otherwise). Rich