Bug 2177250

Summary:	glibc: ldd vdso64.so cause segfault
Product:	Red Hat Enterprise Linux 8	Reporter:	Paulo Andrade <pandrade>
Component:	glibc	Assignee:	glibc team <glibc-bugzilla>
Status:	CLOSED WONTFIX	QA Contact:	qe-baseos-tools-bugs
Severity:	low	Docs Contact:
Priority:	unspecified
Version:	8.7	CC:	ashankar, codonell, dj, fweimer, pfrankli, sipoyare
Target Milestone:	rc	Keywords:	Patch, Triaged
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	No Doc Update
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2023-07-28 13:16:42 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 Paulo Andrade 2023-03-10 15:21:30 UTC

# /lib64/ld-2.28.so --verify /usr/lib/modules/$(uname -r)/vdso/vdso64.so
Segmentation fault (core dumped)

This is basically the same issue as Fedora report at bz#2002756

The problem happens with ReaR, when building the ISO used for recovery,
it verifies that all libraries have their dependencies available.

Comment 1 Florian Weimer 2023-03-10 16:17:51 UTC

Confirmed, the crash appears to be in the same place:

==27== Process terminating with default action of signal 11 (SIGSEGV)
==27==  Bad permissions for mapped region at address 0x4800408
==27==    at 0x11310A: UnknownInlinedFun (get-dynamic-info.h:101)
==27==    by 0x11310A: _dl_map_object_from_fd (dl-load.c:1198)
==27==    by 0x114710: _dl_map_object (dl-load.c:2233)
==27==    by 0x125DB8: map_doit (rtld.c:653)
==27==    by 0x122EDB: _dl_catch_exception (dl-error-skeleton.c:208)
==27==    by 0x122F82: _dl_catch_error (dl-error-skeleton.c:227)
==27==    by 0x12A592: dl_main (rtld.c:1418)
==27==    by 0x1252B2: _dl_sysdep_start (dl-sysdep.c:256)
==27==    by 0x126BAA: _dl_start_final (rtld.c:490)
==27==    by 0x126BAA: _dl_start (rtld.c:583)
==27==    by 0x125C57: ??? (in /usr/lib64/ld-2.28.so)
==27==    by 0x2: ???
==27==    by 0x1FFF00068E: ???
==27==    by 0x1FFF000694: ???

This is probably not going to be easy to backport, though.

Is there a workaround in ReaR? Or is it just about the coredump showing up in the logs?

Comment 9 Florian Weimer 2023-07-28 13:16:42 UTC

The issue is purely cosmetic (ldd on a malformed DSO crashes). We do not plan to address it for Red Hat Enterprise Linux 8.