Bug 87940 - reading uninitialized memory in _dl_relocate_object_internal
reading uninitialized memory in _dl_relocate_object_internal
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
9
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-04-03 16:12 EST by John Reiser
Modified: 2016-11-24 10:13 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-04-04 09:00:46 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
input commands to reproduce bug, with output transcript (3.00 KB, text/plain)
2003-04-03 16:14 EST, John Reiser
no flags Details

  None (edit)
Description John Reiser 2003-04-03 16:12:39 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529

Description of problem:
_dl_relocate_object_internal reads uninitialized local memory when running the
test program iconvdata/bug-iconv1.  The source is
-----elf/dl-reloc.c line 44
static void __attribute_noinline__
allocate_static_tls (struct link_map *map)
{
  size_t offset, used, check;

# if TLS_TCB_AT_TP
  offset = roundup (GL(dl_tls_static_used) + map->l_tls_blocksize,
                    map->l_tls_align);
  used = offset;
  check = offset + TLS_TCB_SIZE;
# elif TLS_DTV_AT_TP
  offset = roundup (GL(dl_tls_static_used), map->l_tls_align);
  used = offset + map->l_tls_blocksize;     ##### l_tls_blocksize uninit, sometimes
-----
but the context is
-----elf/dl-reloc.c line 209
#define CHECK_STATIC_TLS(map, sym_map)                                        \
    do {                                                                      \
      if (__builtin_expect ((sym_map)->l_tls_offset == 0, 0))                 \
        allocate_static_tls (sym_map);                                        \
    } while (0)

#include "dynamic-link.h"
-----
because gcc does not obey the __attribute_noinline__.


Version-Release number of selected component (if applicable):
glibc-2.3.2-11.9

How reproducible:
Always

Steps to Reproduce:
1.Enter commands in attached file bug.gdb.
2.Notice that the watchpoint reports no write to stack-local address $ebp-0x5c,
yet that location is read.
3.
    

Actual Results:  Stack-local location $ebp-0x5c is read before it is written.

Expected Results:  Write $ebp-0x5c before reading it.

Additional info:
Comment 1 John Reiser 2003-04-03 16:14:41 EST
Created attachment 90882 [details]
input commands to reproduce bug, with output transcript

Piping into gdb does not work for me, so I copy+paste each line individually.
Comment 2 Jakub Jelinek 2003-04-04 09:00:46 EST
No, you're looking at very different source to what _dl_relocate_object
is doing at those instructions.
The read from unitialized stack is in the second _ELF_DYNAMIC_DO_RELOC
macro definition in elf/dynamic-link.h:
        for (ranges_index = 0; ranges_index < 2; ++ranges_index)              \
          elf_dynamic_do_##reloc ((map),                                      \
                                  ranges[ranges_index].start,                 \
                                  ranges[ranges_index].size,                  \
                                  ranges[ranges_index].lazy);                 \
second iteration of the loop, ie. read from ranges[1].start.
Yes, it is read from unitialized memory, but does it matter?
ranges[1].size is initialized (to 0) if this happens, and if 3rd arg to
elf/do-rel.h's elf_machine_do_rel is 0, the second (nor fourth) argument
don't matter at all (end = reladdr + 0 and so all the loops with r < end
condition are never executed.

Note You need to log in before you can comment on or make changes to this bug.