[Bug libc/25428] New: [Loader] _dl_map_object Memory contents valid but Registers contents are invalid/corrupted

["akhipatel at gmail dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=25428

            Bug ID: 25428
           Summary: [Loader] _dl_map_object Memory contents valid but
                    Registers contents are invalid/corrupted
           Product: glibc
           Version: 2.24
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: akhipatel at gmail dot com
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

Dear All 

Recently I got many issues with same backtrace, issue occurred after long test
with My complete stack,unfortunately I am unable to reproduce this issue with
sample test application. 

Since my Coredump contents are valid but application is getting crashed
accessing invalid address stored in R1,

In all issues my observations are 
1-> Backtrack is similar 
2-> Memory contents are valid but Registers r9/r1 contents are
invalid/corrupted. 
3-> 
gdb) p/x l->l_info[14]->d_un.d_val
$1 = 0xd128
(gdb)  p/x l->l_info[5]->d_un.d_ptr
$2 = 0x45c47f38
(gdb)  x/1x 0x45c47f38+0xd128
0x45c55060:        0x7462696c              >>>>>>>>>>>>> Valid 

0x41008c2c <+164>:        ldr        r3, [r3, #4]                              
                // 0xd128 = p/x l->l_info[14]->d_un.d_val
   0x41008c30 <+168>:        ldr        r9, [r2, #4]                           
                //0x45c47f38 = p/x l->l_info[5]->d_un.d_ptr
   0x41008c34 <+172>:        add        r9, r9, r3                             
        //0x7462696c
   0x41008c38 <+176>:        mov        r1, r9
   0x41008c3c <+180>:        bl        0x4101a13c <strcmp>
=> 0x41008c40 <+184>:        cmp        r0, #0
   0x41008c44 <+188>:        bne        0x41008bd8 <_dl_map_object+80>
   0x41008c48 <+192>:        mov        r1, r9
   0x41008c4c <+196>:        ldr        r0, [r8, #28]
   0x41008c50 <+200>:        bl        0x41005ad0 <add_name_to_object>

   Seems Expected value in r9/r1 is 0x7462696c but actual value is 0x55555554 

(gdb) info r
r0             0x46fa23fd        1190798333
r1             0x55555554        1431655764
r2             0x45ca1b54        1170873172
r3             0x6c        108
r4             0x46fa23fc        1190798332
r5             0x0        0
r6             0x374f0        226544
r7             0x2        2
r8             0x41670        267888
r9             0x55555554        1431655764
r10            0x0        0
r11            0xbe264224        3190178340
r12            0x80000000        2147483648
sp             0xbe261ff0        0xbe261ff0
lr             0x41008c40        1090554944
pc             0x41008c40        0x41008c40 <_dl_map_object+184>
cpsr           0x20000010        536870928
(gdb)



(gdb)bt
#0  strcmp (p1=<optimized out>, p2=<optimized out>) at
/usr/src/debug/glibc-2.24/string/strcmp.c:39
#1  0x41008c40 in _dl_map_object (loader=0xb67610e8, name=0x438e130e
"terTMCloneTable", type=1, trace_mode=0, mode=0, nsid=0) at
/usr/src/debug/glibc-2.24/elf/dl-load.c:2009
#2  0x4100e0b8 in openaux (a=0xbe67ec50) at
/usr/src/debug/glibc-2.24/elf/dl-deps.c:63
#3  0x4101057c in _dl_catch_error (objname=0x41030830 <data>,
objname@entry=0xbe67ec4c, errstring=0x0, errstring@entry=0xbe67ec48,
mallocedp=0xbe67ec4c, mallocedp@entry=0xbe67ec47, operate=0xbe67ec48,
args=args@entry=0xbe67ec50) at /usr/src/debug/glibc-2.24/elf/dl-error.c:187
#4  0x4100e2a4 in _dl_map_object_deps (map=map@entry=0x41030908,
preloads=<optimized out>, npreloads=npreloads@entry=0,
trace_mode=trace_mode@entry=0, open_mode=<optimized out>, open_mode@entry=0) at
/usr/src/debug/glibc-2.24/elf/dl-deps.c:254
#5  0x41002b44 in dl_main (phdr=<optimized out>, phnum=<optimized out>,
user_entry=<optimized out>, auxv=<optimized out>) at
/usr/src/debug/glibc-2.24/elf/rtld.c:1608
#6  0x41017ce0 in _dl_sysdep_start (start_argptr=start_argptr@entry=0xbe67ede0,
dl_main=0x41001054 <dl_main>) at
/usr/src/debug/glibc-2.24/elf/../elf/dl-sysdep.c:249
#7  0x410051f8 in _dl_start_final (arg=0xbe67ede0) at
/usr/src/debug/glibc-2.24/elf/rtld.c:307
#8  _dl_start (arg=0xbe67ede0) at /usr/src/debug/glibc-2.24/elf/rtld.c:413
#9  0x41000a70 in _start () from ./symbols/lib/ld-linux.so.3
Backtrace stopped: previous frame identical to this frame (corrupt stack?)


We added below debug patch in _dl_map_object, and found "soname_offset" is
invalid but if we read from coredump it seems valid 




-         soname = ((const char *) D_PTR (l, l_info[DT_STRTAB])
-                   + l->l_info[DT_SONAME]->d_un.d_val);
+         strtab = (char *)D_PTR (l, l_info[DT_STRTAB]);
+         soname_offset = l->l_info[DT_SONAME]->d_un.d_val;
+         soname = strtab + soname_offset;

(gdb) p soname+ soname_offset
$13 = 0xe542a356 <error: Cannot access memory at address 0xe542a356>
(gdb)

(gdb) p soname_offset  // stored in local variable
$1 = 1688293803
(gdb) p l->l_info[14]->d_un.d_val  // fetched from coredump (which read from
actual so file on flash)
$2 = 2071
(gdb)

Now for me seems Loader issue Please comments.

-- 
You are receiving this mail because:
You are on the CC list for the bug.