Bug 386428 - [PATCH] isoimagewriter crashes with default Fedora RPM build flags (hardened build) due to libudev dlopen hack (weak symbols)
Summary: [PATCH] isoimagewriter crashes with default Fedora RPM build flags (hardened ...
Status: RESOLVED FIXED
Alias: None
Product: isoimagewriter
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Fedora RPMs Linux
: NOR crash
Target Milestone: ---
Assignee: Jonathan Riddell
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-11-01 13:58 UTC by Kevin Kofler
Modified: 2020-12-17 08:44 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 0.8
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Kofler 2017-11-01 13:58:33 UTC
The isoimagewriter code goes to great length to not link directly to the libudev shared library, but declare its symbols as weak and open it using dlopen. Unfortunately, the weak symbol trick does not work with the default flags for Fedora RPM builds (hardened_build enabled): the function addresses end up being NULL, so the code tries to execute NULL and segfaults. (Note that dlopen itself works if it is used with dlsym, but the weak symbols do not work.)

I do not see a valid reason to dlopen libudev to begin with. First of all, the soname has been constant at libudev.so.1 for 5 years now. A distribution still shipping libudev.so.0 is probably ancient and binaries built on it will not run without recompiling on a distro that old anyway. And distribution packages will always be linked against the correct libudev soname, no matter what it is.

Therefore, I suggest to just link libudev directly, as per the following patch:
https://src.fedoraproject.org/rpms/isoimagewriter/blob/master/f/isoimagewriter-link-libudev-dynamically.patch
or to at least give distributors a CMake option to do that if you really want to keep dlopen support (but as I explained above, I think it is not all that useful to begin with).
Comment 1 Justin Zobel 2020-12-17 05:32:32 UTC
Thank you for the crash report.

As it has been a while since this was reported, can you please test and confirm if this issue is still occurring or if this bug report can be marked as resolved.

I have set the bug status to "needsinfo" pending your response, please change back to "reported" or "resolved/worksforme" when you respond, thank you.
Comment 2 Kevin Kofler 2020-12-17 08:44:36 UTC
This was reportedly fixed in 0.8 in 2019.