Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1074642

Summary:	libdwfl find_aux_sym triggers a kernel heuristic on userspace
Product:	Red Hat Enterprise Linux 7	Reporter:	Josh Stone <jistone>
Component:	elfutils	Assignee:	Mark Wielaard <mjw>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Martin Cermak <mcermak>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	7.0	CC:	fche, mbenitez, mcermak, mjw
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	elfutils-0.158-3.el7	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-06-13 11:25:23 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Josh Stone 2014-03-10 18:06:04 UTC

Description of problem:
When libdwfl opens .gnu_debugdata in find_aux_sym(), the odd addressing of that embedded file may trigger a kernel heuristic in open_elf which flips the whole module from ET_EXEC to ET_DYN.  Apart from being plain wrong, this also changes the way dwfl biases addresses, to our detriment.

Version-Release number of selected component (if applicable):
elfutils-0.158-2.el7.x86_64
systemtap-2.4-11.el7.x86_64
*no* coreutils-debuginfo (else find_aux_sym isn't used)

How reproducible:
100%

Steps to Reproduce:
1. stap -e 'probe process.plt("strstr"),process.function("_start") {next}' \
   -c /usr/bin/ls -p2

Actual results:
> process("/usr/bin/ls").statement(0x402950) /* pc=.dynamic+0x402950 */ /* <- process("/usr/bin/ls").plt("strstr").statement(0x402950) */
> process("/usr/bin/ls").function("_start") /* pc=.dynamic+0x4b48 */ /* <- process("/usr/bin/ls").plt("strstr"),process("/usr/bin/ls").function("_start") */

Note that both are called ".dynamic", which is found by dwfl_module_relocations returning >0.  It should not do that for ET_EXEC.

Expected results:
Should be the same as *with* coreutils-debuginfo, like:
> process("/usr/bin/ls").statement(0x402950) /* pc=.absolute+0x2950 */ /* <- process("/usr/bin/ls").plt("strstr").statement(0x402950) */
> process("/usr/bin/ls").function("_start") /* pc=.absolute+0x4b48 */ /* <- process("/usr/bin/ls").plt("strstr"),process("/usr/bin/ls").function("_start") */

Additional info:
https://sourceware.org/bugzilla/show_bug.cgi?id=16676#c2
https://lists.fedorahosted.org/pipermail/elfutils-devel/2014-March/003878.html

Comment 1 Mark Wielaard 2014-03-10 21:29:01 UTC

This is indeed an issue/regression compared to old (non-debugdata containing files). Fix seems to be understood. Just needs a bit more testing.
https://lists.fedorahosted.org/pipermail/elfutils-devel/2014-March/003884.html

Comment 2 Mark Wielaard 2014-03-11 10:46:21 UTC

Proposed upstream fix:
https://lists.fedorahosted.org/pipermail/elfutils-devel/2014-March/003886.html

Comment 4 Mark Wielaard 2014-03-14 11:03:21 UTC

Josh also made a proper testcase for this in upstream elfutils:
https://lists.fedorahosted.org/pipermail/elfutils-devel/2014-March/003890.html

It was added as commit 51fff30ac9d9eb245e7df8eb5c07658d04d6ad45
Author: Josh Stone <jistone>
Date:   Tue Mar 11 18:13:55 2014 -0700

    libdwfl: test dwflsyms on ET_EXEC with minisymtab
    
    This adds testfilebaxmin, an ET_EXEC binary with .gnu_debugdata that
    doesn't match the load address of the main file.  A previous bug made
    this trigger a kernel heuristic that forces the module to act like
    ET_DYN, which makes things like dwfl_module_relocate_address report
    relative addresses rather than proper absolute addresses.
    
    For example, before the fix dwflsyms would print:
    
        deregister_tm_clones (0) 0x400430, rel: 0x430 (.text)
    
    Now it properly prints:
    
        deregister_tm_clones (0) 0x400430, rel: 0x400430 (.text)
    
    These new test additions confirm that it's fixed.
    
    Signed-off-by: Josh Stone <jistone>

Comment 5 Martin Cermak 2014-03-17 08:48:55 UTC

(In reply to Mark Wielaard from comment #4)
> Josh also made a proper testcase for this in upstream elfutils:

Hello Mark, I tried to use this testcase on both unfixed elfutils-0.158-2.el7 and fixed elfutils-0.158-3.el7 which has the elfutils-0.158-mod-e_type.patch applied. The testcase gives identical results for both old and new version:


 7.0 S x86_64 # eu-readelf -s testfilebaxmin

Symbol table [ 5] '.dynsym' contains 3 entries:
 1 local symbol  String table: [ 6] '.dynstr'
  Num:            Value   Size Type    Bind   Vis          Ndx Name
    0: 0000000000000000      0 NOTYPE  LOCAL  DEFAULT    UNDEF 
    1: 0000000000000000      0 FUNC    GLOBAL DEFAULT    UNDEF __libc_start_main.5 (2)
    2: 0000000000000000      0 NOTYPE  WEAK   DEFAULT    UNDEF __gmon_start__
 7.0 S x86_64 # eu-readelf --elf-section -s testfilebaxmin

Symbol table [27] '.symtab' contains 42 entries:
 35 local symbols  String table: [28] '.strtab'
  Num:            Value   Size Type    Bind   Vis          Ndx Name
    0: 0000000000000000      0 NOTYPE  LOCAL  DEFAULT    UNDEF 
    1: 0000000000400430      0 FUNC    LOCAL  DEFAULT       13 deregister_tm_clones
    2: 0000000000400460      0 FUNC    LOCAL  DEFAULT       13 register_tm_clones
    3: 00000000004004a0      0 FUNC    LOCAL  DEFAULT       13 __do_global_dtors_aux
    4: 0000000000600e18      0 OBJECT  LOCAL  DEFAULT       19 __do_global_dtors_aux_fini_array_entry
    5: 00000000004004c0      0 FUNC    LOCAL  DEFAULT       13 frame_dummy
    6: 0000000000600e10      0 OBJECT  LOCAL  DEFAULT       18 __frame_dummy_init_array_entry
    7: 00000000004004f0     20 FUNC    LOCAL  DEFAULT       13 foo
    8: 0000000000600e18      0 NOTYPE  LOCAL  DEFAULT       18 __init_array_end
    9: 0000000000600e10      0 NOTYPE  LOCAL  DEFAULT       18 __init_array_start
   10: 0000000000400238      0 SECTION LOCAL  DEFAULT        1 
   11: 0000000000400254      0 SECTION LOCAL  DEFAULT        2 
   12: 0000000000400274      0 SECTION LOCAL  DEFAULT        3 
   13: 0000000000400298      0 SECTION LOCAL  DEFAULT        4 
   14: 00000000004002b8      0 SECTION LOCAL  DEFAULT        5 
   15: 0000000000400300      0 SECTION LOCAL  DEFAULT        6 
   16: 0000000000400338      0 SECTION LOCAL  DEFAULT        7 
   17: 0000000000400340      0 SECTION LOCAL  DEFAULT        8 
   18: 0000000000400360      0 SECTION LOCAL  DEFAULT        9 
   19: 0000000000400378      0 SECTION LOCAL  DEFAULT       10 
   20: 00000000004003a8      0 SECTION LOCAL  DEFAULT       11 
   21: 00000000004003d0      0 SECTION LOCAL  DEFAULT       12 
   22: 0000000000400400      0 SECTION LOCAL  DEFAULT       13 
   23: 00000000004005c4      0 SECTION LOCAL  DEFAULT       14 
   24: 00000000004005d0      0 SECTION LOCAL  DEFAULT       15 
   25: 00000000004005e0      0 SECTION LOCAL  DEFAULT       16 
   26: 0000000000400628      0 SECTION LOCAL  DEFAULT       17 
   27: 0000000000600e10      0 SECTION LOCAL  DEFAULT       18 
   28: 0000000000600e18      0 SECTION LOCAL  DEFAULT       19 
   29: 0000000000600e20      0 SECTION LOCAL  DEFAULT       20 
   30: 0000000000600e28      0 SECTION LOCAL  DEFAULT       21 
   31: 0000000000600ff8      0 SECTION LOCAL  DEFAULT       22 
   32: 0000000000601000      0 SECTION LOCAL  DEFAULT       23 
   33: 0000000000601028      0 SECTION LOCAL  DEFAULT       24 
   34: 0000000000601034      0 SECTION LOCAL  DEFAULT       25 
   35: 00000000004005c0      2 FUNC    GLOBAL DEFAULT       13 __libc_csu_fini
   36: 0000000000400504     40 FUNC    GLOBAL DEFAULT       13 bar
   37: 00000000004005c4      0 FUNC    GLOBAL DEFAULT       14 _fini
   38: 0000000000400550    101 FUNC    GLOBAL DEFAULT       13 __libc_csu_init
   39: 0000000000400400      0 FUNC    GLOBAL DEFAULT       13 _start
   40: 000000000040052c     35 FUNC    GLOBAL DEFAULT       13 main
   41: 00000000004003a8      0 FUNC    GLOBAL DEFAULT       11 _init


So since I see no difference in the output between the old and new version, I'm not sure if this testcase can be used to test the fix. By the way, wouldn't it be useful to include proper testcase in the RH RPM along with the fix itself?

Comment 6 Mark Wielaard 2014-03-17 09:12:37 UTC

(In reply to Martin Cermak from comment #5)
> (In reply to Mark Wielaard from comment #4)
> > Josh also made a proper testcase for this in upstream elfutils:
> 
> Hello Mark, I tried to use this testcase on both unfixed
> elfutils-0.158-2.el7 and fixed elfutils-0.158-3.el7 which has the
> elfutils-0.158-mod-e_type.patch applied. The testcase gives identical
> results for both old and new version:
> 
>  7.0 S x86_64 # eu-readelf -s testfilebaxmin
> [...]
> So since I see no difference in the output between the old and new version,
> I'm not sure if this testcase can be used to test the fix.

The eu-readelf --elf-section -s output should be the same before/after. The tests/dwflsyms -e output however should be different before/after.

> By the way,
> wouldn't it be useful to include proper testcase in the RH RPM along with
> the fix itself?

Sure, but since it was a separate commit that was done later than the fix itself it probably needs a new bug report to get in.

Comment 7 Martin Cermak 2014-03-17 11:24:41 UTC

(In reply to Mark Wielaard from comment #6)
> The eu-readelf --elf-section -s output should be the same before/after. The
> tests/dwflsyms -e output however should be different before/after.
>

Ahh, I missed that testcase! OK, so I took elfutils-0.158-3.el7.src.rpm, performed rpmbuild -bp, then -bc and finally make check in the BUILD directory. This way I got dwflsyms binary, which according to ldd is linked against system libraries. Then I performed something like ./rpmbuild/BUILD/elfutils-0.158/tests/dwflsyms -e testfilebaxmin > /tmp/<log> for both old and new elfutils(-libs). Following is the result (same for all three arches):

 7.0 S x86_64 # diff /tmp/{old,new}
2,4c2,4
<    1: FUNC    LOCAL   deregister_tm_clones (0) 0x400430, rel: 0x430 (.text)
<    2: FUNC    LOCAL   register_tm_clones (0) 0x400460, rel: 0x460 (.text)
<    3: FUNC    LOCAL   __do_global_dtors_aux (0) 0x4004a0, rel: 0x4a0 (.text)
---
>    1: FUNC    LOCAL   deregister_tm_clones (0) 0x400430, rel: 0x400430 (.text)
>    2: FUNC    LOCAL   register_tm_clones (0) 0x400460, rel: 0x400460 (.text)
>    3: FUNC    LOCAL   __do_global_dtors_aux (0) 0x4004a0, rel: 0x4004a0 (.text)
6c6
<    5: FUNC    LOCAL   frame_dummy (0) 0x4004c0, rel: 0x4c0 (.text)
---
>    5: FUNC    LOCAL   frame_dummy (0) 0x4004c0, rel: 0x4004c0 (.text)
8c8
<    7: FUNC    LOCAL   foo (20) 0x4004f0, rel: 0x4f0 (.text)
---
>    7: FUNC    LOCAL   foo (20) 0x4004f0, rel: 0x4004f0 (.text)
38,44c38,44
<   37: FUNC    GLOBAL  __libc_csu_fini (2) 0x4005c0, rel: 0x5c0 (.text)
<   38: FUNC    GLOBAL  bar (40) 0x400504, rel: 0x504 (.text)
<   39: FUNC    GLOBAL  _fini (0) 0x4005c4, rel: 0x5c4 (.fini)
<   40: FUNC    GLOBAL  __libc_csu_init (101) 0x400550, rel: 0x550 (.text)
<   41: FUNC    GLOBAL  _start (0) 0x400400, rel: 0x400 (.text)
<   42: FUNC    GLOBAL  main (35) 0x40052c, rel: 0x52c (.text)
<   43: FUNC    GLOBAL  _init (0) 0x4003a8, rel: 0x3a8 (.init)
---
>   37: FUNC    GLOBAL  __libc_csu_fini (2) 0x4005c0, rel: 0x4005c0 (.text)
>   38: FUNC    GLOBAL  bar (40) 0x400504, rel: 0x400504 (.text)
>   39: FUNC    GLOBAL  _fini (0) 0x4005c4, rel: 0x4005c4 (.fini)
>   40: FUNC    GLOBAL  __libc_csu_init (101) 0x400550, rel: 0x400550 (.text)
>   41: FUNC    GLOBAL  _start (0) 0x400400, rel: 0x400400 (.text)
>   42: FUNC    GLOBAL  main (35) 0x40052c, rel: 0x40052c (.text)
>   43: FUNC    GLOBAL  _init (0) 0x4003a8, rel: 0x4003a8 (.init)

This looks right to me. I'm switching this bug to verified based on this test.

> 
> > By the way,
> > wouldn't it be useful to include proper testcase in the RH RPM along with
> > the fix itself?
> 
> Sure, but since it was a separate commit that was done later than the fix
> itself it probably needs a new bug report to get in.

Reported bug 1077154.

Comment 8 Ludek Smid 2014-06-13 11:25:23 UTC

This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.