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.

This bug was initially created as a copy of Bug #2001062

I am copying this bug because: same thing applies to json-c



Multiple JSON libraries have the same API functions. This can cause the wrong function to be used if there are multiple JSON libraries in the dynamic library list. This may manifest as a segfault or very odd behavior. Fixing these libraries will of course require recursive version bumps and rebuilds of packages that use them so they utilize the versioned symbol.

The "very odd behavior" case is very interesting. See this firewalld bug report:

  https://github.com/firewalld/firewalld/issues/819

In the firewalld case, python GI module pulls in libmount which pulls in libcryptsetup which pulls in json-c.

Example conflict: libnftables uses libjansson. libcryptsetup uses json-c. It's not clear which json_object_get() function will be used.

Note: JSON-GLib is also likely affected. But I did not track down any fixes on their end. If 2/3 of the libraries are versioned then I _think_ it should be okay.

--

firewalld bug report: https://github.com/firewalld/firewalld/issues/819
guestfs bug report: bug 1923971
jansson bug report: https://github.com/akheron/jansson/issues/460
json-c bug report: https://github.com/json-c/json-c/issues/621

Upstream fixes:

  jansson: https://github.com/akheron/jansson/pull/540
  json-c: https://github.com/json-c/json-c/pull/639

When checked result on rawhide, exported symbols seem to be different in json-c-0.15-2.fc35.x86_64.

# nm -D /usr/lib64/libjson-c.so.* | grep json_ | tail -3
00000000000066d0 T json_tokener_set_flags@@JSONC_0.14
0000000000006c60 T json_type_to_name@@JSONC_0.14
0000000000006710 T json_util_get_last_err@@JSONC_0.14

But on RHEL8 no versions are present.
# nm -D /usr/lib64/libjson-c.so.* | grep @ | wc -l
0

Is it correct? It seems to me unversioned symbols have to be kept for backward compatibility, but versioned symbols should be provided in addition. New version has still only unversioned symbols. Would it be enough to avoid conflict in single binary?

objdump -T /lib64/libjson-c.so.* prints JSONC_0.14 namespace in both. Maybe just nm tool abilities have changed in Rawhide.

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 (json-c bug fix and enhancement update), 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/RHBA-2022:2027