Your message dated Fri, 10 Jul 2026 17:54:49 +0200
with message-id
<kmh6ff2afkafnfisujlkcrowmqaso4swzdxumszie4yxvy7zvc@3uvu3s3c7bdp>
and subject line Re: Bug#1028504: libc6: valgrind reports "Invalid read of size
8" deep in decompose_rpath in dl-load.c
has caused the Debian Bug report #1028504,
regarding libc6: valgrind reports "Invalid read of size 8" deep in
decompose_rpath in dl-load.c
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 [email protected]
immediately.)
--
1028504: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028504
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: libc6
Version: 2.36-8
Severity: important
STR:
- apt install firefox valgrind
- valgrind --show-mismatched-frees=no firefox
valgrind will quickly show errors like:
==6383== Invalid read of size 8
==6383== at 0x4023A34: strncmp (strcmp-sse2.S:162)
==6383== by 0x4004C8E: is_dst (dl-load.c:216)
==6383== by 0x4005A5E: _dl_dst_count (dl-load.c:253)
==6383== by 0x4005C37: expand_dynamic_string_token (dl-load.c:395)
==6383== by 0x4005DA2: fillin_rpath.isra.0 (dl-load.c:483)
==6383== by 0x4006092: decompose_rpath (dl-load.c:654)
==6383== by 0x400824B: _dl_map_object (dl-load.c:2111)
==6383== by 0x4002280: openaux (dl-deps.c:64)
==6383== by 0x4BE0E99: _dl_catch_exception (dl-error-skeleton.c:208)
==6383== by 0x40025E9: _dl_map_object_deps (dl-deps.c:232)
==6383== by 0x400BB5C: dl_open_worker_begin (dl-open.c:592)
==6383== by 0x4BE0E99: _dl_catch_exception (dl-error-skeleton.c:208)
==6383== Address 0x4ebec59 is 9 bytes inside a block of size 15 alloc'd
==6383== at 0x48407B4: malloc (vg_replace_malloc.c:381)
==6383== by 0x402381A: malloc (rtld-malloc.h:56)
==6383== by 0x402381A: strdup (strdup.c:42)
==6383== by 0x4006024: decompose_rpath (dl-load.c:629)
==6383== by 0x400824B: _dl_map_object (dl-load.c:2111)
==6383== by 0x4002280: openaux (dl-deps.c:64)
==6383== by 0x4BE0E99: _dl_catch_exception (dl-error-skeleton.c:208)
==6383== by 0x40025E9: _dl_map_object_deps (dl-deps.c:232)
==6383== by 0x400BB5C: dl_open_worker_begin (dl-open.c:592)
==6383== by 0x4BE0E99: _dl_catch_exception (dl-error-skeleton.c:208)
==6383== by 0x400B2B5: dl_open_worker (dl-open.c:782)
==6383== by 0x4BE0E99: _dl_catch_exception (dl-error-skeleton.c:208)
==6383== by 0x400B6A7: _dl_open (dl-open.c:884)
Mike
--- End Message ---
--- Begin Message ---
fixed 1028504 1:3.20.0-1
thanks
Upstream released the fix in 3.20.0
Le jeudi 12 janvier 2023 à 21:40:40+0100, Aurelien Jarno a écrit :
> control: reassign -1 valgrind
> control: affects -1 libc6
>
> Hi,
>
> On 2023-01-12 10:15, Mike Hommey wrote:
> > Package: libc6
> > Version: 2.36-8
> > Severity: important
> >
> > STR:
> > - apt install firefox valgrind
> > - valgrind --show-mismatched-frees=no firefox
> >
> > valgrind will quickly show errors like:
> > ==6383== Invalid read of size 8
> > ==6383== at 0x4023A34: strncmp (strcmp-sse2.S:162)
>
> Looking at the source code the code in the glibc is correct. It reads
> the data in chunk of 16-bytes, which indeed can go slightly over the
> allocated memory, but extra care is taken to not cross a cache line.
>
> The solution there is to add a suppression file to valgrind to ignore
> that. I am therefore reassigning the bug to the valgrind package.
>
> Regards
> Aurelien
>
> --
> Aurelien Jarno GPG: 4096R/1DDD8C9B
> [email protected] http://www.aurel32.net
--
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2
It's far easier to fight for principles than to live up to them.
signature.asc
Description: PGP signature
--- End Message ---
