[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: readelf reporting of e_shstrndx is slightly wrong
From: |
Nick Clifton |
Subject: |
Re: readelf reporting of e_shstrndx is slightly wrong |
Date: |
Tue, 21 Aug 2018 16:31:37 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 |
Hi Mike,
> If the file has no section name string table, this member holds the value
> |SHN_UNDEF|.
> If the section name string table section index is greater than or equal to
> |SHN_LORESERVE| (|0xff00|), this member has the value |SHN_XINDEX| (|0xffff|)
> The current readelf -h seems to assume that if there are more than 0xff00
> sections, then the shstrndx will also be past that. But there is nothing to
> prevent the section name string table from being section 1, in which case
> e_shstrndx should just be 1. But the readelf implementation has:
>
> else if (elf_header.e_shstrndx != SHN_UNDEF &&
> elf_header.e_shstrndx >= elf_header.e_shnum)
>
> printf(_(“<corrupt: out of range>”));
I disagree. The readelf code actually looks like this:
if (filedata->section_headers != NULL
&& header->e_shstrndx == (SHN_XINDEX & 0xffff))
printf (" (%u)", filedata->section_headers[0].sh_link);
else if (header->e_shstrndx != SHN_UNDEF
&& header->e_shstrndx >= header->e_shnum)
printf (_(" <corrupt: out of range>"));
There is no check that the file itself has more than 0xff00 sections.
Instead it checks to see if the e_shstrndx field is SHN_XINDEX and if
so it follows the link. Otherwise it checks that the index is either
SHN_UNDEF or a valid section number.
Note - the use if "& 0xffff" in the above code is confusing, and looks
surplus to me, but I do not think that it makes any difference to the
behaviour.
Cheers
Nick