Bug 2021814

Summary:	Please rebuild with json-c-0.13.1-3
Product:	Red Hat Enterprise Linux 8	Reporter:	Tomas Korbar <tkorbar>
Component:	bind	Assignee:	Petr Menšík <pemensik>
Status:	CLOSED ERRATA	QA Contact:	Petr Sklenar <psklenar>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	8.6	CC:	bnater, psklenar
Target Milestone:	rc	Keywords:	Triaged
Target Release:	---	Flags:	pm-rhel: mirror+
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	bind-9.11.36-2.el8	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2022-05-10 15:29:44 UTC	Type:	---
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:	2001063, 2013993, 2219521
Bug Blocks:

Description Tomas Korbar 2021-11-10 09:33:38 UTC

Hi,
please rebuild your package with the latest json-c.
Json-c was until recently providing unversioned symbols in library and
it was discovered that multiple json libraries are providing the same
symbols. This caused weird behaviour when 2 libraries with common symbols
were linked at the same time.
Rebuild with versioned symbols is a precaution against this kind of issues.

Comment 1 Petr Menšík 2021-11-15 17:03:07 UTC

It would be rebuilt with a rebase. I guess no separate rebuild would be needed.

Basic testing can be done when bind-devel is installed, before rebuild:
# rpm -q bind-libs --requires | grep json-c
libjson-c.so.4()(64bit)

# nm -D /usr/lib64/libisc.so | grep json_
                 U json_object_array_add
                 U json_object_new_array
                 U json_object_new_int
                 U json_object_new_int64
                 U json_object_new_object
                 U json_object_new_string
                 U json_object_object_add
                 U json_object_put

After rebuild with new json-c, json-c namespace should be added to symbols and to requires of new package:
# (checked on Fedora Rawhide, therefore soname bump is present)
# rpm -q bind-libs --requires | grep json-c
libjson-c.so.5()(64bit)
libjson-c.so.5(JSONC_0.14)(64bit)

Also symbols should include new namespace on undefined symbols, which should prevent collision in dynamic loader symbols.
nm -D /usr/lib64/libisc.so | grep json_
                 U json_object_array_add
                 U json_object_new_array
                 U json_object_new_int
                 U json_object_new_int64
                 U json_object_new_object
                 U json_object_new_string
                 U json_object_object_add
                 U json_object_put

I am not sure if this change is not breaking ABI for any binaries linked to previous version. New binary would not work without new json-c, which is okay. Old binary must work also with new json-c without recompilation, otherwise we may cause breaks to customer's own programs.

Comment 3 Petr Menšík 2021-11-15 17:37:07 UTC

Forgot bind-libs-lite have to be tested in RHEL8, because it contains libisc.so and libdns.so, which references json-c functions.

Package dependencies to be checked:
# rpm -q bind-libs-lite --requires | grep json-c
libjson-c.so.4()(64bit)
libjson-c.so.4(JSONC_0.14)(64bit)

bind-libs dependency will stay without symbol and that is ok, because no code from those libraries uses json-c. RHEL9 have them merged together, but RHEL8 does not.

Comment 4 Petr Menšík 2021-11-15 20:27:10 UTC

Maybe it is difference just inside nm utility. readelf can list also versioned symbols from json-c:

# readelf --dyn-syms /usr/lib64/libjson-c.so.* | grep @JSONC | tail
   177: 0000000000005170    70 FUNC    GLOBAL DEFAULT   13 json_object_object_get@@JSONC_0.14
   178: 0000000000003d70     9 FUNC    GLOBAL DEFAULT   13 array_list_length@@JSONC_0.14
   179: 0000000000005fe0    75 FUNC    GLOBAL DEFAULT   13 json_object_array_get_idx@@JSONC_0.14
   180: 0000000000005ef0    75 FUNC    GLOBAL DEFAULT   13 json_object_array_add@@JSONC_0.14
   181: 0000000000005c40    43 FUNC    GLOBAL DEFAULT   13 json_object_set_string@@JSONC_0.14
   182: 0000000000004ac0    19 FUNC    GLOBAL DEFAULT   13 json_object_get_userdata@@JSONC_0.14
   183: 0000000000005740    26 FUNC    GLOBAL DEFAULT   13 json_object_double_to_jso@@JSONC_0.14
   184: 0000000000004040   230 FUNC    GLOBAL DEFAULT   13 mc_info@@JSONC_0.14
   185: 0000000000003b90    27 FUNC    GLOBAL DEFAULT   13 array_list_get_idx@@JSONC_0.14
   186: 0000000000003e30    11 FUNC    GLOBAL DEFAULT   13 mc_get_debug@@JSONC_0.14

# LD_DEBUG=versions ldd /lib64/libisc.so.110? 2>&1 | grep -i json
     11931:	checking for version `JSONC_0.14' in file /lib64/libjson-c.so.4 [0] required by file /lib64/libisc.so.1107 [0]
     11931:	checking for version `GLIBC_2.3' in file /lib64/ld-linux-x86-64.so.2 [0] required by file /lib64/libjson-c.so.4 [0]
     11931:	checking for version `GLIBC_2.8' in file /lib64/libc.so.6 [0] required by file /lib64/libjson-c.so.4 [0]
     11931:	checking for version `GLIBC_2.14' in file /lib64/libc.so.6 [0] required by file /lib64/libjson-c.so.4 [0]
     11931:	checking for version `GLIBC_2.3' in file /lib64/libc.so.6 [0] required by file /lib64/libjson-c.so.4 [0]
     11931:	checking for version `GLIBC_2.4' in file /lib64/libc.so.6 [0] required by file /lib64/libjson-c.so.4 [0]
     11931:	checking for version `GLIBC_2.2.5' in file /lib64/libc.so.6 [0] required by file /lib64/libjson-c.so.4 [0]
     11931:	checking for version `GLIBC_2.3.4' in file /lib64/libc.so.6 [0] required by file /lib64/libjson-c.so.4 [0]
	libjson-c.so.4 => /lib64/libjson-c.so.4 (0x00007f49b5d01000)

Some versioning information is present obviously. It would depend on how it is processed by dynamic loader. According to objdump it seems correct:
# objdump -T /lib64/libisc.so.110? | grep json_
0000000000000000      DF *UND*	0000000000000000  JSONC_0.14  json_object_object_add
0000000000000000      DF *UND*	0000000000000000  JSONC_0.14  json_object_new_int64
0000000000000000      DF *UND*	0000000000000000  JSONC_0.14  json_object_new_int
0000000000000000      DF *UND*	0000000000000000  JSONC_0.14  json_object_new_array
0000000000000000      DF *UND*	0000000000000000  JSONC_0.14  json_object_new_string
0000000000000000      DF *UND*	0000000000000000  JSONC_0.14  json_object_array_add
0000000000000000      DF *UND*	0000000000000000  JSONC_0.14  json_object_put
0000000000000000      DF *UND*	0000000000000000  JSONC_0.14  json_object_new_object

Where previous build has no namespace on those symbols:
# objdump -T /lib64/libisc.so.110? | grep json_
0000000000000000      DF *UND*	0000000000000000              json_object_new_string
0000000000000000      DF *UND*	0000000000000000              json_object_new_array
0000000000000000      DF *UND*	0000000000000000              json_object_put
0000000000000000      DF *UND*	0000000000000000              json_object_new_int64
0000000000000000      DF *UND*	0000000000000000              json_object_array_add
0000000000000000      DF *UND*	0000000000000000              json_object_new_object
0000000000000000      DF *UND*	0000000000000000              json_object_new_int
0000000000000000      DF *UND*	0000000000000000              json_object_object_add

so it seems okay. nm tool from binutils-2.30-110.el8.x86_64 does not just display what binutils-2.37-17.fc36.x86_64 can.

Comment 13 errata-xmlrpc 2022-05-10 15:29:44 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 (Moderate: bind security, 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/RHSA-2022:2092