Bug#1042373: marked as done (libc6: The BUG is related to #1042020 (`reallocarray()` on amd64))
Your message dated Sat, 29 Jul 2023 19:22:23 +0200
with message-id <ZMVKzxsNTriSDdSC@aurel32.net>
and subject line Re: Bug#1042373: libc6: The BUG is related to #1042020 (`reallocarray()` on amd64)
has caused the Debian Bug report #1042373,
regarding libc6: The BUG is related to #1042020 (`reallocarray()` on amd64)
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 owner@bugs.debian.org
immediately.)
--
1042373: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042373
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: libc6
Version: 2.37-6
Severity: important
The reason for the crash in `mmv` (Issue #104020) is a malfunction of
`reallocarray()`. I tested it. Even with completely harmless parameters,
a valid pointer and two relatively small `size_t` values (88, 8 or
something like that), `reallocarray()` breaks `mmv` with an `invalid
pointer` abort. In the same situation, a normal `realloc()` with the
product of the two `size_t` values and the same pointer works fine.
I tested it with the source package of `mmv` (by creating a version
which uses `realloc()` instead of `reallocarray()`).
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (900, 'testing'), (800, 'unstable')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.4.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled
Versions of packages libc6 depends on:
ii libgcc-s1 13.1.0-9
Versions of packages libc6 recommends:
ii libidn2-0 2.3.4-1
Versions of packages libc6 suggests:
ii cdebconf [debconf-2.0] 0.270
ii debconf [debconf-2.0] 1.5.82
ii glibc-doc 2.37-6
ii libc-l10n 2.37-6
ii libnss-nis 3.1-4
ii libnss-nisplus 1.3-4
ii locales 2.37-6
-- debconf information excluded
--- End Message ---
--- Begin Message ---
Hi,
On 2023-07-27 09:54, Aurelien Jarno wrote:
> Hi,
>
> On 2023-07-27 08:57, Boris Jakubith wrote:
> > Package: libc6
> > Version: 2.37-6
> > Severity: important
> >
> > The reason for the crash in `mmv` (Issue #104020) is a malfunction of
> > `reallocarray()`. I tested it. Even with completely harmless parameters,
> > a valid pointer and two relatively small `size_t` values (88, 8 or
> > something like that), `reallocarray()` breaks `mmv` with an `invalid
> > pointer` abort. In the same situation, a normal `realloc()` with the
> > product of the two `size_t` values and the same pointer works fine.
>
> The fact that an "invalid pointer" error is returned has nothing to do
> with the size arguments, but with the validity of the pointers. As you
> are able to reproduce the issue, could you please share a small
> testcase? That would ease the debugging.
As pointed out by Simon McVittie in bug#1042020, the pointer passed to
reallocarray() is not valid from the glibc point of view, as it has not
been allocated with glibc.
> > I tested it with the source package of `mmv` (by creating a version
> > which uses `realloc()` instead of `reallocarray()`).
>
> That looks very strange because reallocarray() is just a wrapper around
> realloc(), it doesn't change the pointer that is passed.
reallocarray() does not appear to be wrapped, so the glibc one is used.
Your strategy to reimplement reallocarray() based on realloc() is
actually the good one to fix the issue.
In any case the bug is not in glibc, so I am closing it.
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://aurel32.net
--- End Message ---
Reply to: