Support ELF with empty PT_DYNAMIC reference

[jan-auer]

Some ELF files may contain PT_DYNAMIC program headers that have a zero p_filesz pointing to invalid memory if the corresponding section has been stripped. This currently causes an error when parsing the dynamic headers.

[m4b]

sorry I missed this somehow

[m4b]

I'm just curious, why would this be empty?

[jan-auer]

Unfortunately, I don’t know the full chain that created such a file. Probably, the data pointed to by the header has been stripped, and to keep things easier the header was only rewritten instead of removed. At least, I’ve seen this behavior with sections.

[m4b]

I can’t remember isn’t the filessz effectively the dynamic loader filename ?

Which means the binary is just malformed if it’s 0.

Also afaik you cant meaningfully strip the PT_DYNAMIC, since it’s a program header and not a section header.

[romainthomas]

I would be curious to understand how a valid ELF file can have a PT_DYNAMIC segment with a filesize set to 0 ?
(I agree that it is possible for section)

@jan-auer can you share the sample ?

[m4b]

Yea I’m pretty sure it can’t. Iiuc it would have an empty dynamic loader and the kernel wouldn’t exec. At least last I checked these things.

Curious to see sample as well :)

[jan-auer]

Will try to do that - iirc this happened on a file we pulled from the Debian debug server, so it should be possible to share it.

[m4b]

Oh interesting. That might be it. If I recall correctly the stripped debug symbols (usually from objcopy) are a dynamic library that gdb knows to load if its build id matches another binary you run gdb on.

[philipc]

Yeah objcopy --only-keep-debug appears to set the PT_DYNAMIC filesz to 0.