I've reported the following bug in the MPFR mailing-list. I think I've fixed the issues on the MPFR side in master, but MPFR is still affected by the bug on the GMP side (gmp_vasprintf): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057344 The vasprintf.c code (for the formatted output functions) does not handle null characters correctly. These characters can occur by using %c with the value 0. This is shown by the check_null tsprintf.c test: https://gitlab.inria.fr/mpfr/mpfr/-/commit/78e72e6538fabc1b720d97e862ec45354e5c9c3f The possible consequences are: - possible memory corruption with custom memory allocators that do not ignore the size parameter of the "free" function; - a part of the buffer fails to be overwritten (with possible security issues if the buffer contains sensitive data that were expected to be overwritten); - an assertion failure when GNU MPFR has been configured with assertion checking (--enable-assert). Note that some of these issues partly come from a bug in gmp_vasprintf (such as the incorrect return value), which I've reported here: https://gmplib.org/list-archives/gmp-bugs/2023-December/005420.html I think that I have fixed these issues on the MPFR side with https://gitlab.inria.fr/mpfr/mpfr/-/commit/390e51ef8570da4e338e9806ecaf2d022210d951 but the first two consequences remain due to the gmp_vasprintf bug.
Control: tags -1 fixed-upstream The gmp_vasprintf function is actually correct (but its documentation is not; and it is gmp_sprintf that is incorrect, which is not a problem for MPFR). I've fixed the remaining bugs in MPFR.
Hi Vincent, On Fri, 15 Dec 2023 04:53:51 +0100 Vincent Lefevre <vincent@vinc17.net> wrote: In which version is this fixed? 4.2.2? Paul
Hi Paul, Yes, it is fixed in 4.2.2, but this assumes that GMP does not use its buggy vsnprintf replacement (i.e. it uses either the system vsnprintf function or the replacement that was patched one year ago in the development branch). I suppose that for Debian, the system vsnprintf function is used on all platforms (this is decided at GMP build time, after some tests for C conformance in GMP's configure script). If the buggy vsnprintf replacement is used, the MPFR testsuite would fail. I've put the following section in the INSTALL file about such a failure:------------------------------------------------------------------------ tfprintf and tsprintf failures in check_null -------------------------------------------- If you get the failures $ ./tfprintf Error in test #40: mpfr_vfprintf printed 1 characters instead of 4 $ ./tsprintf Error in check_null, i = 0 expected r = 1, s = { 0, 0, 1 } got r = 0, s = { 0, 1, 1 } the cause is probably that GMP uses a buggy vsnprintf replacement. The reason GMP uses its own vsnprintf replacement is that during configure, it detected that the vsnprintf function from the C library is buggy. But the replacement from GMP 6.3.0 and below also has its own bugs. This means that using the formatted output functions with %c and the value 0 will yield an erratic behavior. For the above issue, this is fixed in the GMP development branch: https://gmplib.org/repo/gmp/rev/4ac76064639e You can have details at https://gmplib.org/list-archives/gmp-bugs/2023-December/005420.html https://gitlab.inria.fr/mpfr/mpfr/-/commit/390e51ef85 These tests can be skipped by defining the MPFR_TESTS_SKIP_CHECK_NULL macro, but you should rather get a fixed vsnprintf replacement. ------------------------------------------------------------------------
Hi, On Sun, 23 Mar 2025 11:37:45 +0100 Vincent Lefevre <vincent@vinc17.net> wrote: I was able to successfully build mpfr4_4.2.2-1.dsc using sbuild. I can see that "make check" is invoked as part of that and the "tfprintf" and "tsprintf" test cases pass. So it seems like this bug can be closed. Best Regards, Fiona
Version: 4.2.2-1 Yes, the MPFR behavior concerning %c and the value 0 should not be affected by the GMP bug in Debian, where vsnprintf is expected to be correct on all architectures. So, closing.