Bug 1085728

Summary:	xtables-addons: missing symbols
Product:	[openSUSE] openSUSE Tumbleweed	Reporter:	Arjen de Korte <suse+build>
Component:	Kernel	Assignee:	Richard Biener <rguenther>
Status:	RESOLVED FIXED	QA Contact:	E-mail List <qa-bugs>
Severity:	Normal
Priority:	P5 - None	CC:	mls, rguenther, tiwai
Version:	Current
Target Milestone:	---
Hardware:	Other
OS:	Other
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Arjen de Korte 2018-03-16 20:35:26 UTC

The xtables-addons-kmp-default module has been partially broken for the past two months. This was reported earlier as https://bugzilla.opensuse.org/show_bug.cgi?id=1076650 but this bug was frivolously closed as a duplicate while the problem quite clearly still existed (and still does).

From the buildlog of the xtables-addons, the following is extracted.

https://build.opensuse.org/build/security:netfilter/openSUSE_Tumbleweed/x86_64/xtables-addons/_log

Problems start after this line:

[   66s] + /usr/lib/rpm/find-debuginfo.sh -j8 --build-id-seed 3.0-120.25 --unique-debug-suffix -3.0-120.25.x86_64 --unique-debug-src-base xtables-addons-3.0-120.25.x86_64 --run-dwz --dwz-low-mem-die-limit 10000000 --dwz-max-die-limit 50000000 -S debugsourcefiles.list /home/abuild/rpmbuild/BUILD/xtables-addons-3.0

The following lines repeat dozens of times (with small variations in some numbers) so I extracted only a handful to show what is going on. The above mentioned buildlog will invariably show many more.

[   67s] objcopy: /home/abuild/rpmbuild/BUILDROOT/xtables-addons-3.0-120.25.x86_64/lib/modules/4.15.8-1-default/extra/xt_LOGMARK.ko: invalid string offset 85573 >= 522 for section `b'

[...]

[   67s] objcopy: /home/abuild/rpmbuild/BUILDROOT/xtables-addons-3.0-120.25.x86_64/lib/modules/4.15.8-1-default/extra/xt_LOGMARK.ko(la.debug_info): relocation 4493 has invalid symbol index 33554443

[...]

[   67s] objcopy: /home/abuild/rpmbuild/BUILDROOT/xtables-addons-3.0-120.25.x86_64/lib/modules/4.15.8-1-default/extra/xt_LOGMARK.ko: invalid relocation type 43

Note that between builds, which particular kernel modules break, varies. Sometimes it is just one (like here), but I've seen builds where two or more would show similar behavior.

When the resulting package is installed, typically something like the following line will repeat dozens of time, sometimes with garbage data from strings in the module in some of these repeating lines:

depmod: WARNING: /lib/modules/4.15.8-1-default/extra/xt_LOGMARK.ko needs unknown symbol (null)

Effectively, modules where the build and installation emits these warnings are broken. You can't install/use them at all.

The worrying thing here is, that the same xtables-addons sources will break in different ways between builds, so I suspect that the problem that leads to this is actually somewhere else (tooling) rather than xtables-addons itself.

Comment 1 Takashi Iwai 2018-03-28 14:27:40 UTC

Richard, we seem still have some issue.

Comment 2 Richard Biener 2018-03-29 07:03:15 UTC

I will investigate once more.

Comment 3 Richard Biener 2018-03-29 10:45:15 UTC

debugedit somehow totally garbles some files.

/usr/lib/rpm/debugedit -b /home/abuild/rpmbuild/BUILD/xtables-addons-3.0 -d /usr/src/debug/xtables-addons-3.0-0.x86_64 xt_DHCPMAC.ko

seems to run into a section size change issue, failing to update the SHDRs?

> readelf -S xt_DHCPMAC.ko
There are 41 section headers, starting at offset 0x870a8:

Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
  [ 0] et                NULL             0000000000000000  00000000
       0000000000000000  0000000000000000           0     0     0
  [ 1] ab                NOTE             0000000000000000  00000040
       0000000000000024  0000000000000000   A       0     0     4
  [ 2] ela.text          PROGBITS         0000000000000000  00000070
       0000000000000340  0000000000000000  AX       0     0     16
  [ 3] id                RELA             0000000000000000  0004a4e0
       00000000000000c0  0000000000000018   I      38     2     8
  [ 4] ela.init.text     PROGBITS         0000000000000000  000003b0
       000000000000003c  0000000000000000  AX       0     0     1
  [ 5] xt                RELA             0000000000000000  0004a5a0
       00000000000000a8  0000000000000018   I      38     4     8
...
  [37] ck                RELA             0000000000000000  00086e58
       00000000000000c0  0000000000000018   I      38    36     8
  [38] t                 SYMTAB           0000000000000000  00049da8
       0000000000000528  0000000000000018          39    44     8
  [39] ab                STRTAB           0000000000000000  0004a2d0
       000000000000020b  0000000000000000           0     0     1
  [40] ab                STRTAB           0000000000000000  00086f18
       000000000000018d  0000000000000000           0     0     1

the .shstrtab (40) starts with

Hex dump of section 'ab':
  0x00000000 65740000 2e73796d 74616200 2e737472 et...symtab..str
  0x00000010 74616200 2e736873 74727461 62002e6e tab..shstrtab..n
  0x00000020 6f74652e 676e752e 6275696c 642d6964 ote.gnu.build-id

and suspiciously 37 (.rela.debug_frame) contains (look at the end!)

Hex dump of section 'ck':
  0x00000000 455f4944 5f766572 6d616769 63313400 E_ID_vermagic14.
  0x00000010 736b625f 636f7079 5f626974 73007874 skb_copy_bits.xt
  0x00000020 5f726567 69737465 725f6d61 74636800 _register_match.
  0x00000030 5f5f7468 69735f6d 6f64756c 6500736b __this_module.sk
  0x00000040 625f6d61 6b655f77 72697461 626c6500 b_make_writable.
  0x00000050 636c6561 6e75705f 6d6f6475 6c65005f cleanup_module._
  0x00000060 5f66656e 7472795f 5f00696e 69745f6d _fentry__.init_m
  0x00000070 6f64756c 65007874 5f756e72 65676973 odule.xt_unregis
  0x00000080 7465725f 6d617463 68005f5f 73746163 ter_match.__stac
  0x00000090 6b5f6368 6b5f6661 696c0078 745f7265 k_chk_fail.xt_re
  0x000000a0 67697374 65725f74 61726765 74007874 gister_target.xt
  0x000000b0 5f756e72 65676973 7465725f 74617267 _unregister_targ

so the real .shstrtab should start at 00086f1c instead of 00086f18.

So there's a off-by-4 error somewhere...

It also looks like actual data is somehow swapped between sections?!

To better debug the corruption one has to binary patch the broken
ELF file to at least get the shstrtab offset correct..

Comment 4 Richard Biener 2018-03-29 10:54:37 UTC

https://github.com/rpm-software-management/rpm/issues/423

Comment 5 Arjen de Korte 2018-10-18 09:15:03 UTC

This problem seems to be resolved. I can no longer reproduce this.