I am surprised there is no consensus on mailing lists about this.

libgmp is library for big numbers.

It is not a library for very big numbers, because if libgmp meets a very big number, it calls abort() and coredumps. Over 2000 packages depend on it on Ubuntu 20.

Simple PoC on Ubuntu 20:

guest3@ubuntu20:~/prim$ gawk --bignum 'BEGIN { a = 2 ^ 2 ^41; print "a =", a }'
gmp: overflow in mpz type
Aborted (core dumped)
guest3@ubuntu20:~/prim$ gawk 'BEGIN { a = 2 ^ 2 ^41; print "a =", a }'
a = +inf

Ubuntu issued advisory about similar issue in libgmp.

Discussion on OSS-security mailing list.

Is triggering abort() and coredump considered denial of service?

Answers suggest that to trigger a DoS, one first needs a service. I think a service in this context might be a client processing untrusted input.

  • Probably yes, depends a bit what disclaimers are in the GMP docs. There's no real impact in the scenario you show, but if a networked app was taking large numbers from remote input, that would be a concern. In general, a library should support that use case - unless the documentation explicitly tells you not to use it like that.
    – paj28
    Commented Oct 21, 2022 at 9:12
  • 1
    If some library allows you to execute $a = $b / $c and you supply $c = 0, and the application isn't prepared for divide by zero exception, it will die. That's not a vulnerability on the library, it's an application that does not validates user input.
    – ThoriumBR
    Commented Oct 21, 2022 at 13:53

2 Answers 2


Is triggering abort() and coredump considered denial of service?

Yes, obviously, but the word "triggering" is doing a lot of work there. Specifically, it needs to be triggerable

  • on demand (doesn't have to be perfectly reliable, but it does need to be in response to some action)
  • by an attacker who lacks privileges to kill the process normally (your example doesn't count, because you're doing it to yourself; generally means they are either remote or the attack is cross-user)
  • in code where it matters whether it runs (that is, not a toy or something you stand up just to knock down; it needs to be serving some purpose that the crash interrupts).

If you have a service or application (that consumes untrusted input) where an unprivileged attacker can trigger this crash, yeah, that's obviously a DoS; they don't come much plainer than "repeatable on-demand process crash". But your example doesn't demonstrate a vulnerability, merely a situation in which, if this library were used to process untrusted input in a meaningful program, it may introduce a vulnerability.

  • Thanks, I agree with your answer. I am surprised the opinion of a lot of people is "this is harmless".
    – joro
    Commented Oct 21, 2022 at 12:49
  • And a service that uses this would have to not handle errors and exits from this sub-porcess.
    – schroeder
    Commented Oct 21, 2022 at 14:44
  • @schroeder Assuming that it's spinning off subprocesses, yes, I'd say that falls under "matters whether it runs". If the subprocess was only going to serve one request before terminating anyhow, or if the parent monitors all the child processes and restarts them on demand without loss of data or getting stuck in a loop trying to serve a malicious request, then it doesn't matter. Those are pretty specific criteria, though. Lots of services either run a bunch of stuff in-process, or store data there that will be lost in a crash, or simply don't handle crashes gracefully.
    – CBHacking
    Commented Oct 22, 2022 at 8:32

Denial of Service means that a service is denied. There is no service in your example, so no service is impacted and so it is not a Denial of Service.

If the library is instead used in some service and an attacker could trigger this problem to crash the service, then it would be considered a Denial of Service - but for this specific service and not for the library.

So, it this issue might be used as part of a Denial of Service attack. But not every use of the library will result in a denial of service attack, either because there is no service in the first place or because the issue can not be exploited by someone attacking the service.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .