[Bug dynamic-link/25486] New: ld-linux-x86-64.so exports 'calloc' but imports 'malloc' from 'libc.so.6'

[lzsiga at freemail dot c3.hu]

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

            Bug ID: 25486
           Summary: ld-linux-x86-64.so exports 'calloc' but imports
                    'malloc' from 'libc.so.6'
           Product: glibc
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: dynamic-link
          Assignee: unassigned at sourceware dot org
          Reporter: lzsiga at freemail dot c3.hu
  Target Milestone: ---

Hi, I think I found a situation where 'ld-linux-x86-64.so.2' exports its
'calloc' implementation (dl-minimal.c) but import 'malloc' from 'libc.so.6'.

Now 'ld-linux:malloc' returns the memory zeroed, but 'libc:malloc' returns the
memory dirty.

The result is a 'calloc' implementation which returns dirty memory.

The problem is described in details on these places:
https://stackoverflow.com/questions/59956996/problem-loading-a-library-with-ffi-in-php-7-4
https://www.linuxquestions.org/questions/programming-9/debugging-dlopen-4175668676/#post6084584
and also here the same issue in a different context:
https://stackoverflow.com/questions/39760479/why-does-calling-calloc-in-gdb-not-appear-to-zero-out-the-memory

Details:
User wants to load an external plugin into PHP via libffi. The plugin is linked
with wrong dependency list (here:
https://stackoverflow.com/questions/59956996/problem-loading-a-library-with-ffi-in-php-7-4#59994038
). Also the plugin depends on glib-2.0.so.

All these components stacked together result in glibs.so-2.0's constructor
calling ld-linux:calloc (which in turn calls libc:malloc) gets back dirty (not
zeroed) memory.

Running it with DL_DEBUG=all shows the event nicely (added line-number, removed
pid):

173486       relocation processing: /lib64/ld-linux-x86-64.so.2
173592       binding file /lib64/ld-linux-x86-64.so.2 [0] to
/lib/x86_64-linux-gnu/libc.so.6 [0]: normal symbol `malloc' [GLIBC_2.2.5]
173633       binding file /lib64/ld-linux-x86-64.so.2 [0] to
/lib/x86_64-linux-gnu/libc.so.6 [0]: normal symbol `calloc' [GLIBC_2.2.5]
...
184669       relocation processing: /usr/local/lib64/libglib-2.0.so.0 (lazy)
185310       symbol=calloc;  lookup in file=./libsomething.so [0]
185311       symbol=calloc;  lookup in file=/lib64/ld-linux-x86-64.so.2 [0]
185312       binding file /usr/local/lib64/libglib-2.0.so.0 [0] to
/lib64/ld-linux-x86-64.so.2 [0]: normal symbol `calloc' [GLIBC_2.2.5]
...
210561       calling init: /usr/local/lib64/libglib-2.0.so.0
210614       symbol=calloc;  lookup in file=./libsomething.so [0]
210615       symbol=calloc;  lookup in file=/lib64/ld-linux-x86-64.so.2 [0]
210616       binding file /usr/local/lib64/libglib-2.0.so.0 [0] to
/lib64/ld-linux-x86-64.so.2 [0]: normal symbol `calloc' [GLIBC_2.2.5]

Suggested solution: ld-linux-x86-64.so shouldn't export symbols that exist in
libc.so.6 (okay, they are 'Weak symbols' but that didn't prevent this problem);
but if it does, its 'calloc' implementation call do zero the memory it returns.

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