Two use-after-free bugs.
Jeremy Allison
jallison at ciq.com
Thu Mar 19 16:37:46 CET 2026
On Wed, Mar 18, 2026 at 5:15 PM <marco.bodrato at tutanota.com> wrote:
>
> Ciao,
>
> the subject is "use after free", can you show a piece of code that triggers this bug?
No, this concerns code cleanliness. Defensiveness if you like.
> 16 mar 2026, 22:56 da jallison at ciq.com:
>
> Bug #1:
> --------------------------------------------------------------------------------
> mpf_get_str() can realloc the str pointer passed into it, so the use
>
> of str in strlen() on line 79 can be pointing at freed memory.
>
> 312 /* If the string was alloced then resize it down to the actual space
> 313 required. */
>
> Are you sure?
> The comment says that the opposite: can realloc if the pointer
> was NOT passed.
Yes. You're correct. However, as mpf_get_str always returns
str, either allocated or passed in, IMHO always assigning the
pointer returned makes for consistency in use. Consistency
in use reduces bugs. So you are correct this is a matter of
taste and this is not currently a bug. Thanks for the correction.
> ------------------------------------------------------------------
> Bug #2
> ------------------------------------------------------------------
>
> In printf/asprntffuns.c: __gmp_asprintf_final looks like:
>
> 63 __gmp_asprintf_final (struct gmp_asprintf_t *d)
> 64 {
> 65 char *buf = d->buf;
> 66 ASSERT (d->alloc >= d->size + 1);
> 67 buf[d->size] = '\0';
> 68 __GMP_REALLOCATE_FUNC_MAYBE_TYPE (buf, d->alloc, d->size+1, char);
> 69 *d->result = buf;
> 70 return 0;
> 71 }
>
> If __GMP_REALLOCATE_FUNC_MAYBE_TYPE changes buf, as realloc() is wont
> to do, then d->buf is left as a wild pointer.
>
> And is there a line of code using d->buf after the call to __gmp_asprintf_final ?
No, currently there is not. Do you always want to depend on this ?
Will this always be the case in the future? Can you depend on all
future callers knowing this ?
More information about the gmp-bugs
mailing list