Your message dated Fri, 11 Apr 2025 16:48:54 +0200
with message-id <20250411144854.ge2...@cventin.lip.ens-lyon.fr>
and subject line Re: Bug#1057355: libmpfr6: major formatted output function
bugs with %c and the value 0
has caused the Debian Bug report #1057355,
regarding libmpfr6: major formatted output function bugs with %c and the value 0
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
1057355: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057355
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: libmpfr6
Version: 4.2.0-1
Severity: grave
Tags: security upstream
Justification: user security hole
Forwarded: https://sympa.inria.fr/sympa/arc/mpfr/2023-12/msg00000.html
X-Debbugs-Cc: Debian Security Team <t...@security.debian.org>
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.
-- System Information:
Debian Release: 12.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-13-amd64 (SMP w/1 CPU thread; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=POSIX, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages libmpfr6 depends on:
ii libc6 2.36-9+deb12u3
ii libgmp10 2:6.2.1+dfsg1-1.1
libmpfr6 recommends no packages.
libmpfr6 suggests no packages.
-- no debconf information
--
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
--- End Message ---
--- Begin Message ---
Version: 4.2.2-1
On 2025-04-11 16:19:28 +0200, Fiona Ebner 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.
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.
--
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)
--- End Message ---
