diff mbox series

tst-p_alignmod3.so: Disable GNU_RELRO segment

Message ID 20220126214100.2433851-1-hjl.tools@gmail.com
State Dropped
Headers
Series tst-p_alignmod3.so: Disable GNU_RELRO segment |

Checks

Context Check Description
dj/TryBot-apply_patch success Patch applied to master at the time it was sent
dj/TryBot-32bit success Build for i686

Commit Message

H.J. Lu Jan. 26, 2022, 9:41 p.m. UTC 
  tst-p_alignmod3.so has invalid p_align on LOAD segments which can't work
with GNU_RELRO.  Pass -z norelro to linker to disable GNU_RELRO segment
to trigger

.../elf/tst-p_alignmod3.so: ELF load command address/offset not page-aligned

instead of

.../elf/tst-p_alignmod3.so: cannot change memory protections
---
 elf/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Michael Hudson-Doyle Jan. 31, 2022, 2:36 a.m. UTC | #1 
On Thu, 27 Jan 2022 at 10:41, H.J. Lu via Libc-alpha <
libc-alpha@sourceware.org> wrote:

> tst-p_alignmod3.so has invalid p_align on LOAD segments which can't work
> with GNU_RELRO.  Pass -z norelro to linker to disable GNU_RELRO segment
> to trigger
>

This helps for me on most Ubuntu architectures (s390x, arm64, ppc64el,
probably armhf although that build hasn't finished yet) but I still see a
failure on amd64 which still seems to hit the "cannot change memory
protections" case (full log here:
https://launchpad.net/~mwhudson/+archive/ubuntu/devirt/+build/23110381) and
i386 (full log here:
https://launchpad.net/~mwhudson/+archive/ubuntu/devirt/+build/23110384)
where the loader seems to be segfaulting:

(gdb) r
Starting program:
/build/glibc-xBQSrs/glibc-2.34.9000-596-g4556b6edae/build-tree/i386-libc/elf/ld-linux.so.2
--library-path
../build-tree/i386-libc:../build-tree/i386-libc/math:../build-tree/i386-libc/elf:../build-tree/i386-libc/dlfcn:../build-tree/i386-libc/nss:../build-tree/i386-libc/nis:../build-tree/i386-libc/rt:../build-tree/i386-libc/resolv:../build-tree/i386-libc/mathvec:../build-tree/i386-libc/support:../build-tree/i386-libc/nptl
../build-tree/i386-libc/elf/tst-p_align3

Program received signal SIGSEGV, Segmentation fault.
0xf7fe9f08 in mprotect () at ../sysdeps/unix/syscall-template.S:120
120 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
(gdb) bt
#0  0xf7fe9f08 in mprotect () at ../sysdeps/unix/syscall-template.S:120
#1  0xf7fcd299 in _dl_map_segments (loader=<optimized out>, has_holes=true,
maplength=2044, nloadcmds=<optimized out>, loadcmds=0xffffc650, type=3,
    header=<optimized out>, fd=3, l=0xf7fb7a70) at ./dl-map-segments.h:116
#2  _dl_map_object_from_fd (name=name@entry=0xf7fb9b03
"/build/glibc-xBQSrs/glibc-2.34.9000-596-g4556b6edae/build-tree/i386-libc/elf/tst-p_alignmod3.so",

    origname=origname@entry=0x0, fd=<optimized out>, fbp=<optimized out>,
realname=<optimized out>, loader=<optimized out>, l_type=<optimized out>,
mode=<optimized out>,
    stack_endp=<optimized out>, nsid=<optimized out>) at dl-load.c:1258
#3  0xf7fcebcd in _dl_map_object (loader=0xf7ffda70, name=0xf7fb9b03
"/build/glibc-xBQSrs/glibc-2.34.9000-596-g4556b6edae/build-tree/i386-libc/elf/tst-p_alignmod3.so",

    type=1, trace_mode=0, mode=0, nsid=<optimized out>) at dl-load.c:2327
#4  0xf7fc8378 in openaux (a=0xffffcc98) at dl-deps.c:64
#5  0xf7fdf8c4 in _dl_catch_exception (exception=0xffffcc8c,
operate=0xf7fc8340 <openaux>, args=0xffffcc98) at dl-error-skeleton.c:208
#6  0xf7fc87f0 in _dl_map_object_deps (map=<optimized out>,
preloads=<optimized out>, npreloads=<optimized out>, trace_mode=<optimized
out>, open_mode=<optimized out>)
    at dl-deps.c:248
#7  0xf7fe5bcf in dl_main (phdr=<optimized out>, phnum=<optimized out>,
user_entry=<optimized out>, auxv=<optimized out>) at rtld.c:1969
#8  0xf7fe1c66 in _dl_sysdep_start (start_argptr=0xffffd440,
dl_main=0xf7fe3ba0 <dl_main>) at ../elf/dl-sysdep.c:256
#9  0xf7fe393f in _dl_start_final (arg=0xffffd440) at rtld.c:506
#10 _dl_start (arg=<optimized out>) at rtld.c:595
#11 0xf7fe273b in _start () from
/build/glibc-xBQSrs/glibc-2.34.9000-596-g4556b6edae/build-tree/i386-libc/elf/ld-linux.so.2

I think but am not sure that "loadcmds[nloadcmds - 1].mapstart" is 0 and
"c->mapend" is 4096 so mprotect is getting called with an insane len in
this code:

          if (__glibc_unlikely
              (__mprotect ((caddr_t) (l->l_addr + c->mapend),
                           loadcmds[nloadcmds - 1].mapstart - c->mapend,
                           PROT_NONE) < 0))
            return DL_MAP_SEGMENTS_ERROR_MPROTECT;
        }

but it's all pretty new to me. It's also possible that this is something
about how Ubuntu's binutils is configured, I suppose.

Cheers,
mwh


> .../elf/tst-p_alignmod3.so: ELF load command address/offset not
> page-aligned
>
> instead of
>
> .../elf/tst-p_alignmod3.so: cannot change memory protections
> ---
>  elf/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/elf/Makefile b/elf/Makefile
> index daafb5cf12..6229add1fc 100644
> --- a/elf/Makefile
> +++ b/elf/Makefile
> @@ -2619,7 +2619,7 @@ $(objpfx)tst-p_alignmod2.so:
> $(objpfx)tst-p_alignmod-base.so
>         cp $(objpfx)tst-p_alignmod-base.so $@
>         $(PYTHON) $(..)scripts/tst-elf-edit.py -a 1 $@
>
> -LDFLAGS-tst-p_alignmod3.so +=
> -Wl,-z,max-page-size=0x100,-z,common-page-size=0x100
> +LDFLAGS-tst-p_alignmod3.so +=
> -Wl,-z,max-page-size=0x100,-z,common-page-size=0x100,-z,norelro
>
>  $(objpfx)tst-p_align3: $(objpfx)tst-p_alignmod3.so
>  $(objpfx)tst-p_align3.out: tst-p_align3.sh $(objpfx)tst-p_align3
> --
> 2.34.1
>
>
H.J. Lu Jan. 31, 2022, 4:49 a.m. UTC | #2 
On Sun, Jan 30, 2022 at 6:36 PM Michael Hudson-Doyle
<michael.hudson@canonical.com> wrote:
>
>
>
> On Thu, 27 Jan 2022 at 10:41, H.J. Lu via Libc-alpha <libc-alpha@sourceware.org> wrote:
>>
>> tst-p_alignmod3.so has invalid p_align on LOAD segments which can't work
>> with GNU_RELRO.  Pass -z norelro to linker to disable GNU_RELRO segment
>> to trigger
>
>
> This helps for me on most Ubuntu architectures (s390x, arm64, ppc64el, probably armhf although that build hasn't finished yet) but I still see a failure on amd64 which still seems to hit the "cannot change memory protections" case (full log here: https://launchpad.net/~mwhudson/+archive/ubuntu/devirt/+build/23110381) and i386 (full log here: https://launchpad.net/~mwhudson/+archive/ubuntu/devirt/+build/23110384) where the loader seems to be segfaulting:
>
> (gdb) r
> Starting program: /build/glibc-xBQSrs/glibc-2.34.9000-596-g4556b6edae/build-tree/i386-libc/elf/ld-linux.so.2 --library-path ../build-tree/i386-libc:../build-tree/i386-libc/math:../build-tree/i386-libc/elf:../build-tree/i386-libc/dlfcn:../build-tree/i386-libc/nss:../build-tree/i386-libc/nis:../build-tree/i386-libc/rt:../build-tree/i386-libc/resolv:../build-tree/i386-libc/mathvec:../build-tree/i386-libc/support:../build-tree/i386-libc/nptl ../build-tree/i386-libc/elf/tst-p_align3
>
> Program received signal SIGSEGV, Segmentation fault.
> 0xf7fe9f08 in mprotect () at ../sysdeps/unix/syscall-template.S:120
> 120 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
> (gdb) bt
> #0  0xf7fe9f08 in mprotect () at ../sysdeps/unix/syscall-template.S:120
> #1  0xf7fcd299 in _dl_map_segments (loader=<optimized out>, has_holes=true, maplength=2044, nloadcmds=<optimized out>, loadcmds=0xffffc650, type=3,
>     header=<optimized out>, fd=3, l=0xf7fb7a70) at ./dl-map-segments.h:116
> #2  _dl_map_object_from_fd (name=name@entry=0xf7fb9b03 "/build/glibc-xBQSrs/glibc-2.34.9000-596-g4556b6edae/build-tree/i386-libc/elf/tst-p_alignmod3.so",
>     origname=origname@entry=0x0, fd=<optimized out>, fbp=<optimized out>, realname=<optimized out>, loader=<optimized out>, l_type=<optimized out>, mode=<optimized out>,
>     stack_endp=<optimized out>, nsid=<optimized out>) at dl-load.c:1258
> #3  0xf7fcebcd in _dl_map_object (loader=0xf7ffda70, name=0xf7fb9b03 "/build/glibc-xBQSrs/glibc-2.34.9000-596-g4556b6edae/build-tree/i386-libc/elf/tst-p_alignmod3.so",
>     type=1, trace_mode=0, mode=0, nsid=<optimized out>) at dl-load.c:2327
> #4  0xf7fc8378 in openaux (a=0xffffcc98) at dl-deps.c:64
> #5  0xf7fdf8c4 in _dl_catch_exception (exception=0xffffcc8c, operate=0xf7fc8340 <openaux>, args=0xffffcc98) at dl-error-skeleton.c:208
> #6  0xf7fc87f0 in _dl_map_object_deps (map=<optimized out>, preloads=<optimized out>, npreloads=<optimized out>, trace_mode=<optimized out>, open_mode=<optimized out>)
>     at dl-deps.c:248
> #7  0xf7fe5bcf in dl_main (phdr=<optimized out>, phnum=<optimized out>, user_entry=<optimized out>, auxv=<optimized out>) at rtld.c:1969
> #8  0xf7fe1c66 in _dl_sysdep_start (start_argptr=0xffffd440, dl_main=0xf7fe3ba0 <dl_main>) at ../elf/dl-sysdep.c:256
> #9  0xf7fe393f in _dl_start_final (arg=0xffffd440) at rtld.c:506
> #10 _dl_start (arg=<optimized out>) at rtld.c:595
> #11 0xf7fe273b in _start () from /build/glibc-xBQSrs/glibc-2.34.9000-596-g4556b6edae/build-tree/i386-libc/elf/ld-linux.so.2
>
> I think but am not sure that "loadcmds[nloadcmds - 1].mapstart" is 0 and "c->mapend" is 4096 so mprotect is getting called with an insane len in this code:
>
>           if (__glibc_unlikely
>               (__mprotect ((caddr_t) (l->l_addr + c->mapend),
>                            loadcmds[nloadcmds - 1].mapstart - c->mapend,
>                            PROT_NONE) < 0))
>             return DL_MAP_SEGMENTS_ERROR_MPROTECT;
>         }
>
> but it's all pretty new to me. It's also possible that this is something about how Ubuntu's binutils is configured, I suppose.

tst-p_alignmod3.so is invalid and is very sensitive to how it is built.
But the loader shouldn't crash in any case.  Please provide i386 and
x86-64 tst-p_alignmod3.so so that I can fix it.

> Cheers,
> mwh
>
>>
>> .../elf/tst-p_alignmod3.so: ELF load command address/offset not page-aligned
>>
>> instead of
>>
>> .../elf/tst-p_alignmod3.so: cannot change memory protections
>> ---
>>  elf/Makefile | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/elf/Makefile b/elf/Makefile
>> index daafb5cf12..6229add1fc 100644
>> --- a/elf/Makefile
>> +++ b/elf/Makefile
>> @@ -2619,7 +2619,7 @@ $(objpfx)tst-p_alignmod2.so: $(objpfx)tst-p_alignmod-base.so
>>         cp $(objpfx)tst-p_alignmod-base.so $@
>>         $(PYTHON) $(..)scripts/tst-elf-edit.py -a 1 $@
>>
>> -LDFLAGS-tst-p_alignmod3.so += -Wl,-z,max-page-size=0x100,-z,common-page-size=0x100
>> +LDFLAGS-tst-p_alignmod3.so += -Wl,-z,max-page-size=0x100,-z,common-page-size=0x100,-z,norelro
>>
>>  $(objpfx)tst-p_align3: $(objpfx)tst-p_alignmod3.so
>>  $(objpfx)tst-p_align3.out: tst-p_align3.sh $(objpfx)tst-p_align3
>> --
>> 2.34.1
>>
Michael Hudson-Doyle Jan. 31, 2022, 7:49 a.m. UTC | #3 
On Mon, 31 Jan 2022 at 17:49, H.J. Lu <hjl.tools@gmail.com> wrote:

> On Sun, Jan 30, 2022 at 6:36 PM Michael Hudson-Doyle
> <michael.hudson@canonical.com> wrote:
> >
> >
> >
> > On Thu, 27 Jan 2022 at 10:41, H.J. Lu via Libc-alpha <
> libc-alpha@sourceware.org> wrote:
> >>
> >> tst-p_alignmod3.so has invalid p_align on LOAD segments which can't work
> >> with GNU_RELRO.  Pass -z norelro to linker to disable GNU_RELRO segment
> >> to trigger
> >
> >
> > This helps for me on most Ubuntu architectures (s390x, arm64, ppc64el,
> probably armhf although that build hasn't finished yet) but I still see a
> failure on amd64 which still seems to hit the "cannot change memory
> protections" case (full log here:
> https://launchpad.net/~mwhudson/+archive/ubuntu/devirt/+build/23110381)
> and i386 (full log here:
> https://launchpad.net/~mwhudson/+archive/ubuntu/devirt/+build/23110384)
> where the loader seems to be segfaulting:
> >
> > (gdb) r
> > Starting program:
> /build/glibc-xBQSrs/glibc-2.34.9000-596-g4556b6edae/build-tree/i386-libc/elf/ld-linux.so.2
> --library-path
> ../build-tree/i386-libc:../build-tree/i386-libc/math:../build-tree/i386-libc/elf:../build-tree/i386-libc/dlfcn:../build-tree/i386-libc/nss:../build-tree/i386-libc/nis:../build-tree/i386-libc/rt:../build-tree/i386-libc/resolv:../build-tree/i386-libc/mathvec:../build-tree/i386-libc/support:../build-tree/i386-libc/nptl
> ../build-tree/i386-libc/elf/tst-p_align3
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > 0xf7fe9f08 in mprotect () at ../sysdeps/unix/syscall-template.S:120
> > 120 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
> > (gdb) bt
> > #0  0xf7fe9f08 in mprotect () at ../sysdeps/unix/syscall-template.S:120
> > #1  0xf7fcd299 in _dl_map_segments (loader=<optimized out>,
> has_holes=true, maplength=2044, nloadcmds=<optimized out>,
> loadcmds=0xffffc650, type=3,
> >     header=<optimized out>, fd=3, l=0xf7fb7a70) at
> ./dl-map-segments.h:116
> > #2  _dl_map_object_from_fd (name=name@entry=0xf7fb9b03
> "/build/glibc-xBQSrs/glibc-2.34.9000-596-g4556b6edae/build-tree/i386-libc/elf/tst-p_alignmod3.so",
> >     origname=origname@entry=0x0, fd=<optimized out>, fbp=<optimized
> out>, realname=<optimized out>, loader=<optimized out>, l_type=<optimized
> out>, mode=<optimized out>,
> >     stack_endp=<optimized out>, nsid=<optimized out>) at dl-load.c:1258
> > #3  0xf7fcebcd in _dl_map_object (loader=0xf7ffda70, name=0xf7fb9b03
> "/build/glibc-xBQSrs/glibc-2.34.9000-596-g4556b6edae/build-tree/i386-libc/elf/tst-p_alignmod3.so",
> >     type=1, trace_mode=0, mode=0, nsid=<optimized out>) at dl-load.c:2327
> > #4  0xf7fc8378 in openaux (a=0xffffcc98) at dl-deps.c:64
> > #5  0xf7fdf8c4 in _dl_catch_exception (exception=0xffffcc8c,
> operate=0xf7fc8340 <openaux>, args=0xffffcc98) at dl-error-skeleton.c:208
> > #6  0xf7fc87f0 in _dl_map_object_deps (map=<optimized out>,
> preloads=<optimized out>, npreloads=<optimized out>, trace_mode=<optimized
> out>, open_mode=<optimized out>)
> >     at dl-deps.c:248
> > #7  0xf7fe5bcf in dl_main (phdr=<optimized out>, phnum=<optimized out>,
> user_entry=<optimized out>, auxv=<optimized out>) at rtld.c:1969
> > #8  0xf7fe1c66 in _dl_sysdep_start (start_argptr=0xffffd440,
> dl_main=0xf7fe3ba0 <dl_main>) at ../elf/dl-sysdep.c:256
> > #9  0xf7fe393f in _dl_start_final (arg=0xffffd440) at rtld.c:506
> > #10 _dl_start (arg=<optimized out>) at rtld.c:595
> > #11 0xf7fe273b in _start () from
> /build/glibc-xBQSrs/glibc-2.34.9000-596-g4556b6edae/build-tree/i386-libc/elf/ld-linux.so.2
> >
> > I think but am not sure that "loadcmds[nloadcmds - 1].mapstart" is 0 and
> "c->mapend" is 4096 so mprotect is getting called with an insane len in
> this code:
> >
> >           if (__glibc_unlikely
> >               (__mprotect ((caddr_t) (l->l_addr + c->mapend),
> >                            loadcmds[nloadcmds - 1].mapstart - c->mapend,
> >                            PROT_NONE) < 0))
> >             return DL_MAP_SEGMENTS_ERROR_MPROTECT;
> >         }
> >
> > but it's all pretty new to me. It's also possible that this is something
> about how Ubuntu's binutils is configured, I suppose.
>
> tst-p_alignmod3.so is invalid and is very sensitive to how it is built.
> But the loader shouldn't crash in any case.  Please provide i386 and
> x86-64 tst-p_alignmod3.so so that I can fix it.
>

I've uploaded them to https://people.canonical.com/~mwh/p_align3/

Cheers,
mwh


> > Cheers,
> > mwh
> >
> >>
> >> .../elf/tst-p_alignmod3.so: ELF load command address/offset not
> page-aligned
> >>
> >> instead of
> >>
> >> .../elf/tst-p_alignmod3.so: cannot change memory protections
> >> ---
> >>  elf/Makefile | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/elf/Makefile b/elf/Makefile
> >> index daafb5cf12..6229add1fc 100644
> >> --- a/elf/Makefile
> >> +++ b/elf/Makefile
> >> @@ -2619,7 +2619,7 @@ $(objpfx)tst-p_alignmod2.so:
> $(objpfx)tst-p_alignmod-base.so
> >>         cp $(objpfx)tst-p_alignmod-base.so $@
> >>         $(PYTHON) $(..)scripts/tst-elf-edit.py -a 1 $@
> >>
> >> -LDFLAGS-tst-p_alignmod3.so +=
> -Wl,-z,max-page-size=0x100,-z,common-page-size=0x100
> >> +LDFLAGS-tst-p_alignmod3.so +=
> -Wl,-z,max-page-size=0x100,-z,common-page-size=0x100,-z,norelro
> >>
> >>  $(objpfx)tst-p_align3: $(objpfx)tst-p_alignmod3.so
> >>  $(objpfx)tst-p_align3.out: tst-p_align3.sh $(objpfx)tst-p_align3
> >> --
> >> 2.34.1
> >>
>
>
> --
> H.J.
>
H.J. Lu Jan. 31, 2022, 3:26 p.m. UTC | #4 
On Sun, Jan 30, 2022 at 11:49 PM Michael Hudson-Doyle
<michael.hudson@canonical.com> wrote:
>
>
>
> On Mon, 31 Jan 2022 at 17:49, H.J. Lu <hjl.tools@gmail.com> wrote:
>>
>> On Sun, Jan 30, 2022 at 6:36 PM Michael Hudson-Doyle
>> <michael.hudson@canonical.com> wrote:
>> >
>> >
>> >
>> > On Thu, 27 Jan 2022 at 10:41, H.J. Lu via Libc-alpha <libc-alpha@sourceware.org> wrote:
>> >>
>> >> tst-p_alignmod3.so has invalid p_align on LOAD segments which can't work
>> >> with GNU_RELRO.  Pass -z norelro to linker to disable GNU_RELRO segment
>> >> to trigger
>> >
>> >
>> > This helps for me on most Ubuntu architectures (s390x, arm64, ppc64el, probably armhf although that build hasn't finished yet) but I still see a failure on amd64 which still seems to hit the "cannot change memory protections" case (full log here: https://launchpad.net/~mwhudson/+archive/ubuntu/devirt/+build/23110381) and i386 (full log here: https://launchpad.net/~mwhudson/+archive/ubuntu/devirt/+build/23110384) where the loader seems to be segfaulting:
>> >
>> > (gdb) r
>> > Starting program: /build/glibc-xBQSrs/glibc-2.34.9000-596-g4556b6edae/build-tree/i386-libc/elf/ld-linux.so.2 --library-path ../build-tree/i386-libc:../build-tree/i386-libc/math:../build-tree/i386-libc/elf:../build-tree/i386-libc/dlfcn:../build-tree/i386-libc/nss:../build-tree/i386-libc/nis:../build-tree/i386-libc/rt:../build-tree/i386-libc/resolv:../build-tree/i386-libc/mathvec:../build-tree/i386-libc/support:../build-tree/i386-libc/nptl ../build-tree/i386-libc/elf/tst-p_align3
>> >
>> > Program received signal SIGSEGV, Segmentation fault.
>> > 0xf7fe9f08 in mprotect () at ../sysdeps/unix/syscall-template.S:120
>> > 120 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
>> > (gdb) bt
>> > #0  0xf7fe9f08 in mprotect () at ../sysdeps/unix/syscall-template.S:120
>> > #1  0xf7fcd299 in _dl_map_segments (loader=<optimized out>, has_holes=true, maplength=2044, nloadcmds=<optimized out>, loadcmds=0xffffc650, type=3,
>> >     header=<optimized out>, fd=3, l=0xf7fb7a70) at ./dl-map-segments.h:116
>> > #2  _dl_map_object_from_fd (name=name@entry=0xf7fb9b03 "/build/glibc-xBQSrs/glibc-2.34.9000-596-g4556b6edae/build-tree/i386-libc/elf/tst-p_alignmod3.so",
>> >     origname=origname@entry=0x0, fd=<optimized out>, fbp=<optimized out>, realname=<optimized out>, loader=<optimized out>, l_type=<optimized out>, mode=<optimized out>,
>> >     stack_endp=<optimized out>, nsid=<optimized out>) at dl-load.c:1258
>> > #3  0xf7fcebcd in _dl_map_object (loader=0xf7ffda70, name=0xf7fb9b03 "/build/glibc-xBQSrs/glibc-2.34.9000-596-g4556b6edae/build-tree/i386-libc/elf/tst-p_alignmod3.so",
>> >     type=1, trace_mode=0, mode=0, nsid=<optimized out>) at dl-load.c:2327
>> > #4  0xf7fc8378 in openaux (a=0xffffcc98) at dl-deps.c:64
>> > #5  0xf7fdf8c4 in _dl_catch_exception (exception=0xffffcc8c, operate=0xf7fc8340 <openaux>, args=0xffffcc98) at dl-error-skeleton.c:208
>> > #6  0xf7fc87f0 in _dl_map_object_deps (map=<optimized out>, preloads=<optimized out>, npreloads=<optimized out>, trace_mode=<optimized out>, open_mode=<optimized out>)
>> >     at dl-deps.c:248
>> > #7  0xf7fe5bcf in dl_main (phdr=<optimized out>, phnum=<optimized out>, user_entry=<optimized out>, auxv=<optimized out>) at rtld.c:1969
>> > #8  0xf7fe1c66 in _dl_sysdep_start (start_argptr=0xffffd440, dl_main=0xf7fe3ba0 <dl_main>) at ../elf/dl-sysdep.c:256
>> > #9  0xf7fe393f in _dl_start_final (arg=0xffffd440) at rtld.c:506
>> > #10 _dl_start (arg=<optimized out>) at rtld.c:595
>> > #11 0xf7fe273b in _start () from /build/glibc-xBQSrs/glibc-2.34.9000-596-g4556b6edae/build-tree/i386-libc/elf/ld-linux.so.2
>> >
>> > I think but am not sure that "loadcmds[nloadcmds - 1].mapstart" is 0 and "c->mapend" is 4096 so mprotect is getting called with an insane len in this code:
>> >
>> >           if (__glibc_unlikely
>> >               (__mprotect ((caddr_t) (l->l_addr + c->mapend),
>> >                            loadcmds[nloadcmds - 1].mapstart - c->mapend,
>> >                            PROT_NONE) < 0))
>> >             return DL_MAP_SEGMENTS_ERROR_MPROTECT;
>> >         }
>> >
>> > but it's all pretty new to me. It's also possible that this is something about how Ubuntu's binutils is configured, I suppose.
>>
>> tst-p_alignmod3.so is invalid and is very sensitive to how it is built.
>> But the loader shouldn't crash in any case.  Please provide i386 and
>> x86-64 tst-p_alignmod3.so so that I can fix it.
>
>
> I've uploaded them to https://people.canonical.com/~mwh/p_align3/
>

A patch is posted at

https://sourceware.org/pipermail/libc-alpha/2022-January/135905.html
diff mbox series

Patch

diff --git a/elf/Makefile b/elf/Makefile
index daafb5cf12..6229add1fc 100644
--- a/elf/Makefile
+++ b/elf/Makefile
@@ -2619,7 +2619,7 @@  $(objpfx)tst-p_alignmod2.so: $(objpfx)tst-p_alignmod-base.so
 	cp $(objpfx)tst-p_alignmod-base.so $@
 	$(PYTHON) $(..)scripts/tst-elf-edit.py -a 1 $@
 
-LDFLAGS-tst-p_alignmod3.so += -Wl,-z,max-page-size=0x100,-z,common-page-size=0x100
+LDFLAGS-tst-p_alignmod3.so += -Wl,-z,max-page-size=0x100,-z,common-page-size=0x100,-z,norelro
 
 $(objpfx)tst-p_align3: $(objpfx)tst-p_alignmod3.so
 $(objpfx)tst-p_align3.out: tst-p_align3.sh $(objpfx)tst-p_align3