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 1988715 - annocheck segfaults sometimes when processing multiple parameters and symlink is involved
Summary: annocheck segfaults sometimes when processing multiple parameters and symlink...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: annobin
Version: 9.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: beta
: ---
Assignee: Nick Clifton
QA Contact: Martin Cermak
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-07-31 13:06 UTC by Jan Pazdziora (Red Hat)
Modified: 2021-12-07 21:23 UTC (History)
6 users (show)

Fixed In Version: annobin-9.87-1.el9
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-12-07 21:20:54 UTC
Type: Bug
Target Upstream Version:
Embargoed:
pm-rhel: mirror+

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-91774 0 None None None 2021-07-31 13:12:17 UTC

Description Jan Pazdziora (Red Hat) 2021-07-31 13:06:58 UTC 
Description of problem:

Running annocheck /usr/lib64/libstdc++.so.6* which should process libstdc++.so.6.0.29 and libstdc++.so.6.0.29 via symlink on s390x ends with segfault. Running annocheck on individual paths seems to work fine.

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

annobin-annocheck-9.79-1.el9.s390x
libstdc++-11.1.1-6.1.el9.s390x

How reproducible:

Deterministic.

Steps to Reproduce:
1. Check that we have one .so and a symlink to it:
   ls -la /usr/lib64/libstdc++.so.6*

2. Check the order in which shell expands the metacharacter:
   echo /usr/lib64/libstdc++.so.6*

3. Check that running annocheck via symlink passes:
   annocheck --skip-all /usr/lib64/libstdc++.so.6

4. Check that running annocheck on the .so passes:
   annocheck --skip-all /usr/lib64/libstdc++.so.6.*

5. Now run annocheck, passing it as parameters both the symlink and the .so:
   annocheck --skip-all /usr/lib64/libstdc++.so.6*

Actual results:

# ls -la /usr/lib64/libstdc++.so.6*
lrwxrwxrwx. 1 root root      19 Jun 23 16:33 /usr/lib64/libstdc++.so.6 -> libstdc++.so.6.0.29
-rwxr-xr-x. 1 root root 2529384 Jun 23 16:35 /usr/lib64/libstdc++.so.6.0.29

# echo /usr/lib64/libstdc++.so.6*
/usr/lib64/libstdc++.so.6 /usr/lib64/libstdc++.so.6.0.29

# annocheck --skip-all /usr/lib64/libstdc++.so.6
annocheck: Version 9.79.
Hardened: libstdc++.so.6: PASS.

# annocheck --skip-all /usr/lib64/libstdc++.so.6.*
annocheck: Version 9.79.
Hardened: libstdc++.so.6.0.29: PASS.

# annocheck --skip-all /usr/lib64/libstdc++.so.6*
annocheck: Version 9.79.
Hardened: libstdc++.so.6.0.29: PASS.
Segmentation fault (core dumped)

Expected results:

# ls -la /usr/lib64/libstdc++.so.6*
lrwxrwxrwx. 1 root root      19 Jun 23 16:33 /usr/lib64/libstdc++.so.6 -> libstdc++.so.6.0.29
-rwxr-xr-x. 1 root root 2529384 Jun 23 16:35 /usr/lib64/libstdc++.so.6.0.29

# echo /usr/lib64/libstdc++.so.6*
/usr/lib64/libstdc++.so.6 /usr/lib64/libstdc++.so.6.0.29

# annocheck --skip-all /usr/lib64/libstdc++.so.6
annocheck: Version 9.79.
Hardened: libstdc++.so.6: PASS.

# annocheck --skip-all /usr/lib64/libstdc++.so.6.*
annocheck: Version 9.79.
Hardened: libstdc++.so.6.0.29: PASS.

# annocheck --skip-all /usr/lib64/libstdc++.so.6*
annocheck: Version 9.79.
Hardened: libstdc++.so.6.0.29: PASS.
Hardened: libstdc++.so.6: PASS.

Or, once bug 1988714 is resolved

# annocheck --skip-all /usr/lib64/libstdc++.so.6*
annocheck: Version 9.79.
Hardened: libstdc++.so.6: PASS.
Hardened: libstdc++.so.6.0.29: PASS.

Additional info:
Comment 2 Nick Clifton 2021-08-09 11:43:35 UTC 
Hi Jan,

  Is this problem s390x specific ?  Ie if you run annocheck on say an x86_64 host, does it also seg-fault ?

  I tried reproducing the problem with the latest annocheck (9.84) but there was no seg-fault.  This was on an x86_64 host however.

Cheers
  Nick
Comment 4 Václav Kadlčík 2021-08-16 05:41:22 UTC 
Yes, this is s390x-specific. Just ran into it while verifying bz1988450.

# rpm -qf /usr/lib64/libstdc++.so.6 /usr/bin/annocheck
libstdc++-11.2.1-2.2.el9.s390x
annobin-annocheck-9.83-3.el9.s390x

# ls -l /usr/lib64/libstdc++.so.6 /usr/lib64/libstdc++.so.6.0.29
lrwxrwxrwx. 1 root root      19 Aug 13 23:21 /usr/lib64/libstdc++.so.6 -> libstdc++.so.6.0.29
-rwxr-xr-x. 1 root root 2532832 Aug 13 23:23 /usr/lib64/libstdc++.so.6.0.29

# annocheck /usr/lib64/libstdc++.so.6 /usr/lib64/libstdc++.so.6.0.29
annocheck: Version 9.83.
Hardened: libstdc++.so.6.0.29: PASS.
Segmentation fault (core dumped)

Seems to segfault in glibc:
systemd-coredump[40069]: [🡕] Process 40063 (annocheck) of user 0 dumped core.
  
  Stack trace of thread 40063:
  #0  0x000003ffa8a807e0 __vfprintf_internal (libc.so.6 + 0x807e0)
  #1  0x000003ffa8a92148 __vasprintf_internal (libc.so.6 + 0x92148)
  #2  0x000003ffa8b287a4 __asprintf_chk (libc.so.6 + 0x1287a4)
  #3  0x000002aa10c10b54 build_note_checker (annocheck + 0x10b54)
  #4  0x000002aa10c07534 annocheck_walk_notes (annocheck + 0x7534)
  #5  0x000002aa10c0d460 check_note_section (annocheck + 0xd460)
  #6  0x000002aa10c080a6 process_elf (annocheck + 0x80a6)
  #7  0x000002aa10c08bc8 process_file (annocheck + 0x8bc8)
  #8  0x000002aa10c05e78 main (annocheck + 0x5e78)
  #9  0x000003ffa8a32982 __libc_start_call_main (libc.so.6 + 0x32982)
  #10 0x000003ffa8a32a5e __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x32a5e)
  #11 0x000002aa10c06500 _start (annocheck + 0x6500)

Tried with glibc-2.34-1.el9.s390x and glibc-2.34-2.el9.s390x, the segfault
happens with both.
Comment 5 Nick Clifton 2021-08-16 11:28:41 UTC 
Right - I have tracked it down.  There is an assumption in the annocheck code that the symbol names found using the elfutils-libelf library will be persistent and can be used repeatedly.  For the s390x version at least this is not true, and the strings need to be copied.  

I have a local patch ready to apply once the RHEL-9 mass rebuild finishes.
Comment 6 Nick Clifton 2021-08-16 12:12:28 UTC 
Fixed in annobin-9.87-1.el9
Comment 8 Martin Cermak 2021-08-20 12:45:48 UTC 
Verified with annobin-9.90-1.el9.
Note You need to log in before you can comment on or make changes to this bug.