[binutils] error in readelf when trying to search for missing section header table

[pini]

Hello,

I stumbled upon the following error when reading data from a file that has
no section header table.

The file I tested has the `e_shoff` and `e_shnum` members set to zero in
the ELF header, which are the expected values when the file has no section
header table (according to e.g. "gABI" docs).

Reading such a file with e.g. "readelf -h" leads to the following output
regarding section headers:

  Start of section headers:          0 (bytes into file)
  Number of section headers:         0 (64)

and also reports this error:

readelf: Error: Reading 4096 bytes extends past end of file for section
headers

Looking into the source code in readelf.c, it seems due do the `e_shnum`
member being overriden, in the `process_file_header` function, by the
value of the `sh_size` member of the first section
(`filedata->section_headers[0].sh_size`), under the condition that the
section header table was loaded and that the `e_shnum` member is zero
(`filedata->section_headers != NULL && header->e_shnum == SHN_UNDEF`).

This would be valid if the offset of the section header table was non-zero
(i.e. the table actually exists).

It turns out that the `section_headers` field of `filedata` is loaded in
both `get_32bit_section_headers` and `get_64bit_section_headers` functions
for `num` entries unless `num` is zero, which also seems legit.

The `num` variable is set to either the file header `e_shnum` member or to
1 if the `probe` parameter is set (`unsigned int num = probe ? 1 :
filedata->file_header.e_shnum`).

The `probe` parameter is given to these functions through a call to the
`get_section_headers` function, which is in turn called only once with the
`probe` parameter set, in the `process_object` function, along with the
following comment:

"There may be some extensions in the first section header.
Don't bomb if we can't read it."

I would add "... unless the table does not exist" (in which case there is
no "first section header").

I looks to me that the overall behaviour of the tool is incorrect
regarding the file content.

One possible fix would be to set the `num` variable to 1 only when the
`probe` parameter is set *and* the `e_shoff` member is non-zero (i.e. the
table exists): `unsigned int num = probe && filedata->file_header.e_shoff
? 1 : filedata->file_header.e_shnum`.

Does this seem correct?

Thanks a lot for your feedback.
Best regards,

-- 
Pierre-Nicolas