GNU bug report logs - #79805
possible missing null check in tostring()

Previous Next

To reply to this bug, email your comments to 79805 AT debbugs.gnu.org.
There is no need to reopen the bug first.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ray steven <checkscope.hyzc <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: possible missing null check in tostring()
Date: Sun, 9 Nov 2025 20:42:17 +0800

[Message part 1 (text/plain, inline)]

Hello coreutils maintainers,

I would like to report a potential NULL pointer dereference issue found in
the expr utility source code.

File: src/expr.c
Function: tostring
Line: around 459
Version: coreutils latest
Severity: Low (extremely unlikely, only occurs if memory allocator failed)

Description:
In the function tostring(), the return value of mpz_get_str(NULL, 10,
v->u.i)
is not checked before use. If memory allocation fails, mpz_get_str() may
return NULL.

The code then assigns this NULL pointer to v->u.s. Later, in functions such
as
eval2(), string operations like strcoll(l->u.s, r->u.s) can dereference the
NULL
pointer and cause a crash.

Example call path:
  eval -> eval1 -> eval2 -> tostring

Relevant code snippet:
  case integer:
    v->u.s = mpz_get_str (NULL, 10, v->u.i);
    mpz_clear (v->u.i);
    v->type = string;
    break;

Reasoning:
By default, GMP aborts on allocation failure, but this behavior can be
changed
by registering custom memory functions. If such a configuration is used, the
current code may continue execution with a NULL pointer, leading to
undefined
behavior or crash. Adding a defensive check would make the code robust in
both
default and customized environments.

Best regards,
CheckScope

[Message part 2 (text/html, inline)]

Message #8 received at 79805 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Ray steven <checkscope.hyzc <at> gmail.com>
Cc: 79805 <at> debbugs.gnu.org
Subject: Re: bug#79805: possible missing null check in tostring()
Date: Sun, 9 Nov 2025 22:29:33 -0800

On 2025-11-09 04:42, Ray steven wrote:
> If memory allocation fails, mpz_get_str() may
> return NULL.

I don't see how. When GMP functions exhaust memory, they exit; they 
don't return a null pointer.

Message #11 received at 79805 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Ray steven <checkscope.hyzc <at> gmail.com>, 79805 <at> debbugs.gnu.org
Subject: Re: bug#79805: possible missing null check in tostring()
Date: Sun, 9 Nov 2025 22:30:29 -0800

On 2025-11-09 04:42, Ray steven wrote:
> By default, GMP aborts on allocation failure, but this behavior can be
> changed
> by registering custom memory functions. If such a configuration is used,

Such a configuration is not used here.

Message #14 received at 79805 <at> debbugs.gnu.org (full text, mbox):

From: Grisha Levit <grishalevit <at> gmail.com>
To: Ray steven <checkscope.hyzc <at> gmail.com>
Cc: 79805 <at> debbugs.gnu.org
Subject: Re: bug#79805: possible missing null check in tostring()
Date: Mon, 10 Nov 2025 19:29:16 -0500

On Mon, Nov 10, 2025, 01:10 Ray steven <checkscope.hyzc <at> gmail.com> wrote:
> Reasoning:
> By default, GMP aborts on allocation failure, but this behavior can be
> changed by registering custom memory functions.

Only if one registers a custom allocation function whose behavior violates
the documented [1] requirement to terminate the program on failure.

    No error return is allowed from any of these functions, if they
    return then they must have performed the specified operation.
    In particular note that allocate_function or reallocate_function
    mustn’t return NULL.

[1] https://gmplib.org/manual/Custom-Allocation

Message #19 received at 79805-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Ray steven <checkscope.hyzc <at> gmail.com>
Cc: 79805-done <at> debbugs.gnu.org
Subject: Re: bug#79805: possible missing null check in tostring()
Date: Mon, 10 Nov 2025 16:46:10 -0800

As this is not a bug in expr (since it doesn't use GMP in a way that 
could trigger the bug) I'm closing the bug report.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.