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 2033255

Summary:	annocheck reports that ld-linux-aarch64.so.1 fails stack-prot test
Product:	Red Hat Enterprise Linux 9	Reporter:	Jan Pazdziora (Red Hat) <jpazdziora>
Component:	annobin	Assignee:	Nick Clifton <nickc>
Status:	CLOSED ERRATA	QA Contact:	Václav Kadlčík <vkadlcik>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	9.0	CC:	fweimer, jpazdziora, mcermak, nickc, rlemosor, vkadlcik
Target Milestone:	rc	Keywords:	Bugfix, Triaged
Target Release:	---	Flags:	pm-rhel: mirror+
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	annobin-10.40-1.el9	Doc Type:	No Doc Update
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2022-05-17 12:33:28 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:
Bug Depends On:
Bug Blocks:	2044387

Description Jan Pazdziora (Red Hat) 2021-12-16 11:28:16 UTC

Description of problem:

Running

  annocheck --verbose --skip-all --test-stack-prot /usr/lib/ld-linux-aarch64.so.1

fails with

  FAIL: stack-prot test because stack protection deliberately disabled (function: init_have_lse_atomics)

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

annobin-annocheck-10.37-1.el9.aarch64
glibc-2.34-13.el9.aarch64

How reproducible:

Deterministic.

Steps to Reproduce:
1. dnf -y --nogpgcheck debuginfo-install glibc glibc-gconv-extra
2. annocheck --verbose --skip-all --test-stack-prot /usr/lib/ld-linux-aarch64.so.1

Actual results:

annocheck: Version 10.37.
Hardened: /usr/lib/ld-linux-aarch64.so.1: PASS: stack-prot test 
Hardened: /usr/lib/ld-linux-aarch64.so.1: info: ALSO written in Assembler (source: DW_AT_language string).
Hardened: /usr/lib/ld-linux-aarch64.so.1: Command line options not recorded in DWARF DW_AT_producer variable.
Hardened: /usr/lib/ld-linux-aarch64.so.1: FAIL: stack-prot test because stack protection deliberately disabled (function: init_have_lse_atomics) 
Hardened: /usr/lib/ld-linux-aarch64.so.1: info: For more information visit: https://sourceware.org/annobin/annobin.html/Test-stack-prot.html
Hardened: /usr/lib/ld-linux-aarch64.so.1: skip: stack-prot test because function check_match is part of the C library's startup code, which executes before stack protection is established 
Hardened: ld-linux-aarch64.so.1: Overall: FAIL.

Expected results:

No FAIL.

Additional info:

Running on /lib/ld-linux-aarch64.so.1 actually passes

annocheck: Version 10.37.
Hardened: /lib/ld-linux-aarch64.so.1: PASS: stack-prot test 
Hardened: /lib/ld-linux-aarch64.so.1: info: ALSO written in Assembler (source: DW_AT_language string).
Hardened: /lib/ld-linux-aarch64.so.1: Command line options not recorded in DWARF DW_AT_producer variable.
Hardened: /lib/ld-linux-aarch64.so.1: skip: stack-prot test because the ld-linux-aarch64.so.1 binary is a special case, hand-crafted by the glibc build system 
Hardened: ld-linux-aarch64.so.1: Overall: PASS.

so I wonder if this is another instance of (or caused by change for) bug 2022973.

Comment 2 Nick Clifton 2021-12-17 10:20:01 UTC

(In reply to Jan Pazdziora from comment #0)
Hi Jan,

> Hardened: /usr/lib/ld-linux-aarch64.so.1: FAIL: stack-prot test because

> Running on /lib/ld-linux-aarch64.so.1 actually passes

> so I wonder if this is another instance of (or caused by change for) bug
> 2022973.

It is.  Annocheck now contains a list of known glibc binaries for which certain tests should be skipped.  /lib/ld-linux-aarch64.so.1 is one of these binaries.  The list uses hard coded paths, which is why /usr/lib/ld-linux-aarch64.so.1 is not matching. 

*But* as far as I can see the glibc-2.34-13.el9.aarch64 rpm does not contain a /usr/lib/ld-linux-aarch64.so binary, nor a symbolic link to one.  So I am not sure where yours is coming from.  I can add /usr/lib/ld-linux-aarch64.so.1 of course, but I would like to confirm that this is a valid glibc binary.  (The whole point of using hard coded paths in annocheck was so that users could not spoof the checks by renaming their binaries).

Cheers
  Nick

Comment 3 Jan Pazdziora (Red Hat) 2021-12-17 18:28:24 UTC

(In reply to Nick Clifton from comment #2)
>
> *But* as far as I can see the glibc-2.34-13.el9.aarch64 rpm does not contain
> a /usr/lib/ld-linux-aarch64.so binary, nor a symbolic link to one.  So I am
> not sure where yours is coming from.  I can add
> /usr/lib/ld-linux-aarch64.so.1 of course, but I would like to confirm that
> this is a valid glibc binary.  (The whole point of using hard coded paths in
> annocheck was so that users could not spoof the checks by renaming their
> binaries).

The glibc-2.34-13.el9.aarch64 ships /lib/ld-linux-aarch64.so.1 (lists it as such in %files). But as with /sbin in bug 2022973, /lib is a symlink to /usr/lib, so the file actually lands at /usr/lib/ld-linux-aarch64.so.1. Our annocheck scans avoid symlinks and just walk the directories.

Comment 4 Nick Clifton 2021-12-20 14:00:50 UTC

Fixed in annobin-10.39-1.el9

Comment 12 errata-xmlrpc 2022-05-17 12:33:28 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (new packages: annobin), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2022:2342