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