Created attachment 1514054 [details] Original BPF ELF file (grundig.o) According to readelf -SW, the grundig.o file starts out with: Section Headers: [Nr] Name Type Address Off Size ES Flg Lk Inf Al [ 0] NULL 0000000000000000 000000 000000 00 0 0 0 [ 1] .strtab STRTAB 0000000000000000 000896 000140 00 0 0 1 [ 2] .text PROGBITS 0000000000000000 000040 000000 00 AX 0 0 4 [ 3] grundig PROGBITS 0000000000000000 000040 000510 00 AX 0 0 8 Running this: $ /usr/lib/rpm/debugedit -b /foo -d /usr/src/debug/foo -l grundig.list grundig.o results in: Section Headers: [Nr] Name Type Address Off Size ES Flg Lk Inf Al [ 0] NULL 0000000000000000 000000 000000 00 0 0 0 [ 1] STRTAB 0000000000000000 000896 000140 00 0 0 1 [ 2] PROGBITS 0000000000000000 000040 000000 00 AX 0 0 4 [ 3] PROGBITS 0000000000000000 000040 000510 00 AX 0 0 8 So the resulting ELF file has been corrupted. rpm-4.14.2.1-2.fc29.x86_64 elfutils-0.174-5.fc29.x86_64
This leads to corrupt BPF files in v4l-utils-1.16.2-2.fc29 (e.g., /usr/lib/udev/rc_keymaps/protocols/grundig.o).
Replicated on f29, but the odd thing is that there is nothing in the file that debugedit should care about. So since it doesn't need to change anything it really shouldn't even try to (re)write the file. So the simplest workaround would be to just exit early, although it would be good to to understand why what should be a noop write corrupts the section string table. Also I think bpf object .o (EM_BPF ET_REL) files should not be executable. In which case find-debuginfo.sh should just ignore them.
I suspect that the core issue is a bug at rpm, as reported on this issue: https://github.com/rpm-software-management/rpm/pull/604 It seems that the fix reached rpm upstream 3 days ago. It should be noticed that on non-x86 archs it isn't even possible to build the BPF files because of the executable flag. So, I suspect that a better solution would be to port back this patch to rpm package: https://github.com/rpm-software-management/rpm/pull/604/commits/37d2a0b033bceb53a6a89fe1714c8fe3830c504b
(In reply to Mauro Carvalho Chehab from comment #3) > I suspect that the core issue is a bug at rpm, as reported on this issue: > > https://github.com/rpm-software-management/rpm/pull/604 > > It seems that the fix reached rpm upstream 3 days ago. It should be noticed > that on non-x86 archs it isn't even possible to build the BPF files because > of the executable flag. > > So, I suspect that a better solution would be to port back this patch to rpm > package: > > https://github.com/rpm-software-management/rpm/pull/604/commits/ > 37d2a0b033bceb53a6a89fe1714c8fe3830c504b Sorry, this comment (as-is) was supposed to be at bug #1659055. Anyway, we noticed that the find-debuginfo.sh script was incorrectly tagging BPF files as executable. This patch (already applied upstream) fixes it: https://github.com/rpm-software-management/rpm/pull/604/commits/37d2a0b033bceb53a6a89fe1714c8fe3830c504b It makes sense to backport it to Fedora 29 and upper, as it is currently causing problems on some packages like v4l-utils (see bug #1659055).
(In reply to Mauro Carvalho Chehab from comment #4) > Anyway, we noticed that the find-debuginfo.sh script was incorrectly tagging > BPF files as executable. This patch (already applied upstream) fixes it: > > https://github.com/rpm-software-management/rpm/pull/604/commits/ > 37d2a0b033bceb53a6a89fe1714c8fe3830c504b > > It makes sense to backport it to Fedora 29 and upper, as it is currently > causing problems on some packages like v4l-utils (see bug #1659055). As mentioned in that pull request I think that commit is incorrect (it would also exclude kernel modules). I don't believe it was committed upstream in rpm. But a fix in rpm would indeed be around that lookup (but it shouldn't use the file utility though, that causes issues in itself, since the human readable output isn't stable). But the v4l-utils commit (also mentioned in that rpm pull request) does seem to work around it for now: https://github.com/kamomil/v4l-utils/commit/6155b042ee7541944173b1947ddbc038a2f544bf
The "ignore object files" commit certainly wasn't upstreamed, the submitter closed it by himself after discovering the simple fix of making the files non-executable (which the file(s) in question should've been to begin with so it was really just the right thing to do).
(In reply to Panu Matilainen from comment #6) > The "ignore object files" commit certainly wasn't upstreamed, the submitter > closed it by himself after discovering the simple fix of making the files > non-executable (which the file(s) in question should've been to begin with > so it was really just the right thing to do). Yeah, I ended by misreading the issue at rpm file. Thanks for pointing that! The proposed fix of making install to remove the execute flag was ported already to v4l-utils upstream and merged at v4l-utils-1.16.3. That should hopefully solve the issue for that specific file. I'm runining a scratch build right now. Still, I think that something could be improved at rpm packaging, in order to at least provide a clue for packagers that BPF files should not have exec flags.
I suspect the corruption happens because debugedit attempts to add a build ID. How well-tested is that code?
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Although the original issue has been fixed (see https://github.com/kamomil/v4l-utils/commit/6155b042ee7541944173b1947ddbc038a2f544bf) I like to keep this open for now to better understand the issues pointed out in comment #2. I suspect this is related to this upsteam issue: https://github.com/rpm-software-management/rpm/issues/423
Reassigning to elfutils, under the assumption that this is the same bug as upstream https://github.com/rpm-software-management/rpm/issues/423
(In reply to Panu Matilainen from comment #11) > Reassigning to elfutils, under the assumption that this is the same bug as > upstream https://github.com/rpm-software-management/rpm/issues/423 I think that is correct. Which also means this is the same as https://bugzilla.redhat.com/show_bug.cgi?id=1716380 (Already fixed in rawhide, update pending for f30.) *** This bug has been marked as a duplicate of bug 1716380 ***