Description of problem: LibELF can't add a Program Header when e_type is set to OS/Proc specific. Version-Release number of selected component (if applicable): elfutil:96e140f6687922606657a76f185a73cf47908ef2 master How reproducible: Steps to Reproduce: 1. Create an ELF with the e_type value set to a vendor specific value (ex. 0xffa0) and 1 Program Header 2. Call the elf_update function Actual results: The elf_update function will fail with ELF_E_INVALID_PHDR. Expected results: The elf_update e_type check should allow PH creation when e_type is set to OS/Proc specific. Additional info: The actual check is done in elf32_updatenull.c -> updatenull_wrlock function: if (ehdr->e_type != ET_EXEC && ehdr->e_type != ET_DYN ... The check should be: if (ehdr->e_type != ET_EXEC && ehdr->e_type != ET_DYN && ehdr->e_type < ET_LOOS ...
The intention of the check seems to have been to deny creating a phdr for an ET_REL file. It also denies an phdr for ET_NONE. Or as in this case any e_type in the OS specific or Processor specific range. Do we want to tweak the check as suggested to only allow creating a phdr for an ET_EXEC, ET_DYN, ET_CORE or any OS or Processor specific e_type value (and denying for ET_NONE, ET_REL or any unassigned number not in the OS specific or Processor specific range)? Or might we just remove this check completely and let the user shoot themselves into their feet?
Pushed fix to upstream master. commit 8b5f017ddf1684e225ef59f9243ef411b2556e9c Author: Mark Wielaard <mjw> Date: Wed Jul 6 15:27:56 2016 +0200 libelf: Allow updating phdrs for any e_type. elf[32|64]_updatenull would sanity check the e_type before allowing to update the phdrs. This prevents creating an ET_REL file with phdrs. It also prevents creating any vendor specific ELF file having phdrs. We only check this when updating/writing out the file. But we would just read such files. Don't prevent people from creating unexpected ELF files. elflint will warn for such files. While writing a new testcase for this another bug was found that prevented updating a just created phdr because elf_getphdrnum would sanity check the phdr offset in the file (which doesn't exist yet). Fix that by only doing such a sanity check if the phdrs haven't been read in or created yet. This second bug should have been found by the existing elfshphehdr test, but that test contained a typo checking elf_getphdrnum. It tested that the called failed when there were no phdrs, but then elf_getphdrnum should simply succeed and return zero. https://bugzilla.redhat.com/show_bug.cgi?id=1352232 Signed-off-by: Mark Wielaard <mjw>
This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle. Changing version to '25'.
elfutils-0.167-1.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-de1f4e692b
elfutils-0.167-1.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-de1f4e692b
elfutils-0.167-1.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.
elfutils-0.167-1.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-1bc61e8f20
elfutils-0.167-1.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-1bc61e8f20
elfutils-0.167-1.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.