Re: [PATCH] elf: Check invalid hole in PT_LOAD segments [BZ #28838]

[Florian Weimer <fweimer@redhat.com>]

* H. J. Lu:

> commit 163f625cf9becbb82dfec63a29e566324129c0cd
> Author: H.J. Lu <hjl.tools@gmail.com>
> Date:   Tue Dec 21 12:35:47 2021 -0800
>
>     elf: Remove excessive p_align check on PT_LOAD segments [BZ #28688]
>
> removed the p_align check against the page size.  It caused the loader
> crash in shared objects with the invalid p_align.  Update _dl_map_segments
> to detect invalid holes.  This fixes BZ #28838.

Commit message should reference commit ID and mention the failing
test/module name.

> ---
>  elf/dl-map-segments.h | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/elf/dl-map-segments.h b/elf/dl-map-segments.h
> index 172692b120..fd24cf5d01 100644
> --- a/elf/dl-map-segments.h
> +++ b/elf/dl-map-segments.h
> @@ -113,6 +113,9 @@ _dl_map_segments (struct link_map *l, int fd,
>               unallocated.  Then jump into the normal segment-mapping loop to
>               handle the portion of the segment past the end of the file
>               mapping.  */
> +	  if (__glibc_unlikely (loadcmds[nloadcmds - 1].mapstart <
> +				c->mapend))
> +	    return N_("ELF load command address/offset not page-aligned");
>            if (__glibc_unlikely
>                (__mprotect ((caddr_t) (l->l_addr + c->mapend),
>                             loadcmds[nloadcmds - 1].mapstart - c->mapend,

This seems to be fairly risky because I don't think that so far, we
enforce increasing LOAD segment addresses (although required by te EHF
specification).

Given

LDFLAGS-tst-p_alignmod3.so += -Wl,-z,max-page-size=0x100,-z,common-page-size=0x100

and RELRO construction for that

  .../elf/tst-p_alignmod3.so: cannot change memory protections

seems to be a valid failure string for this test.  However, worst case,
there could be a different kind of failure, if the RELRO mprotect start
is page-aligned by chance, and the kernel rounds up the end address to a
page boundary.  The RELRO protection then covers more than what the link
editor expected, and this can cause crashes later on.  But this isn't
something we can detect easily, I think.

Thanks,
Florian