← Back to team overview

debcrafters-packages team mailing list archive

[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