debcrafters-packages team mailing list archive
-
debcrafters-packages team
-
Mailing list archive
-
Message #06675
[Bug 2122102] [NEW] Corrupt DTV after reuse of a TLS module ID following dlclose with unused TLS
Public bug reported:
The issue affects glibc 2.34 to 2.38.
_dl_assign_tls_modid() assigns a slotinfo entry for a new module, but
does *not* do anything to the generation counter. The first time this
happens, the generation is zero and map_generation() returns the current
generation to be used during relocation processing. However, if
a slotinfo entry is later reused, it will already have a generation
assigned. If this generation has fallen behind the current global max
generation, then this causes an obsolete generation to be assigned
during relocation processing, as map_generation() returns this
generation if nonzero. _dl_add_to_slotinfo() eventually resets the
generation, but by then it is too late. This causes DTV updates to be
skipped, leading to NULL or broken TLS slot pointers and segfaults.
This was reported https://sourceware.org/bugzilla/show_bug.cgi?id=29039
and fixed by
https://github.com/bminor/glibc/commit/3921c5b40f293c57cb326f58713c924b0662ef59.
The relevant change has been applied to 2.35 release branch as well
https://github.com/bminor/glibc/commit/5f08ec08d03930050befec16fcc6264fa00c66fe.
Is there any plan to apply it to Jammy (22.04) which also is on Glibc
2.35 (I don't see it in
https://git.launchpad.net/ubuntu/+source/glibc/tree/elf/dl-
tls.c?h=ubuntu%2Fjammy-updates)?
** Affects: glibc (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of
Debcrafters packages, which is subscribed to glibc in Ubuntu.
https://bugs.launchpad.net/bugs/2122102
Title:
Corrupt DTV after reuse of a TLS module ID following dlclose with
unused TLS
Status in glibc package in Ubuntu:
New
Bug description:
The issue affects glibc 2.34 to 2.38.
_dl_assign_tls_modid() assigns a slotinfo entry for a new module, but
does *not* do anything to the generation counter. The first time this
happens, the generation is zero and map_generation() returns the current
generation to be used during relocation processing. However, if
a slotinfo entry is later reused, it will already have a generation
assigned. If this generation has fallen behind the current global max
generation, then this causes an obsolete generation to be assigned
during relocation processing, as map_generation() returns this
generation if nonzero. _dl_add_to_slotinfo() eventually resets the
generation, but by then it is too late. This causes DTV updates to be
skipped, leading to NULL or broken TLS slot pointers and segfaults.
This was reported
https://sourceware.org/bugzilla/show_bug.cgi?id=29039 and fixed by
https://github.com/bminor/glibc/commit/3921c5b40f293c57cb326f58713c924b0662ef59.
The relevant change has been applied to 2.35 release branch as well
https://github.com/bminor/glibc/commit/5f08ec08d03930050befec16fcc6264fa00c66fe.
Is there any plan to apply it to Jammy (22.04) which also is on Glibc
2.35 (I don't see it in
https://git.launchpad.net/ubuntu/+source/glibc/tree/elf/dl-
tls.c?h=ubuntu%2Fjammy-updates)?
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/2122102/+subscriptions