But it *is* clearly inside the second PT_LOAD segment.
It's just that the check is:
&& (phdr->p_offset + phdr->p_filesz > shdr->sh_offset
|| (phdr->p_offset + phdr->p_memsz > shdr->sh_offset
&& shdr->sh_type == SHT_NOBITS)))
and it's on the cusp between p_filesz and p_memsz. So:
&& (phdr->p_offset + phdr->p_filesz > shdr->sh_offset
|| (phdr->p_offset + phdr->p_memsz > shdr->sh_offset
&& shdr->sh_type == SHT_NOBITS)
|| (phdr->p_offset + phdr->p_filesz == shdr->sh_offset
&& shdr->sh_size == 0)))
or perhaps better overflow-proofed:
&& ((shdr->sh_offset - phdr->p_offset <= phdr->p_filesz
&& (shdr->sh_offset - phdr->p_offset < phdr->p_filesz
|| shdr->sh_size == 0))
|| (shdr->sh_offset - phdr->p_offset < phdr->p_memsz
&& shdr->sh_type == SHT_NOBITS)))
I think we should accept these corner cases but not accept wild sh_addr or
sh_offset values just because they are technically meaningless with a zero
sh_size.
Thanks,
Roland