Closed haadr closed 7 months ago
for each note, the offset is incremented with an assumed 4-byte alignment (?)
The padding for note data should definitely always be 4-bytes. See "Note Section" chapter of the ELF spec.
Since this section is 8-byte aligned, the last loop will try to parse 4 bytes only (the rest of the padding), which is not enough for a complete note.
Ah I see, the alignment on the segment is 8 bytes, causing 4 additional 0x00 bytes after the 4 note padding bytes.
What I am not sure about is whether the p_memsz
size is supposed to include or exclude padding. In the .elf you provided, the additional padding is included in the size.
That said, I feel like it's probably a good idea to stop trying to parse notes if there are not enough bytes left.
I'll work on a PR to fix this in the next days.
I've put up a fix PR for this bug here: https://github.com/eliben/pyelftools/pull/537
@eliben could you take a look? tyvm!
All below is tested with pyelftools Version: 0.30.
Context
As in https://github.com/eliben/pyelftools/issues/534, I've got a
libqtwebenginequickplugin.so
where qt has injected a.note.qt.metadata
section and note.As we can see, the note is of size 120.
Bug ❓
When trying to iterate over the notes I get
Using pyelftools to inspect the note before the crash, I see
It looks like the section (and desc?) is padded with a total of 7 bytes.
Fix :question:
It seems to me that
Since this section is 8-byte aligned, the last loop will try to parse 4 bytes only (the rest of the padding), which is not enough for a complete note.
The following is a quick fix that worked for me, but I don't know whether it makes sense/is the best way to solve that. I reasoned that with an empty name and desc, 12 bytes is the smallest a note could be.
Reproduction
Script used to reproduce error (almost same as elf_notes.py example)
output from readelf -a is attached. shared object file is attached. it's libqtwebenginequickplugin.so from a standard openSUSE Tumbleweed install.
libqtwebenginequickplugin.so.txt readelf-a.txt