In commit b212921b13bd ("elf: don't use MAP_FIXED_NOREPLACE for elf executable mappings")
we still leave MAP_FIXED_NOREPLACE in place for load_elf_interp.
Unfortunately, this will cause kernel to fail to start with
[ 2.384321] 1 (init): Uhuuh, elf segment at 00003ffff7ffd000 requested but the memory is mapped already
[ 2.386240] Failed to execute /init (error -17)
The reason is that the elf interpreter (ld.so) has overlapping segments.
readelf -l ld-2.31.so
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x000000000002c94c 0x000000000002c94c R E 0x10000
LOAD 0x000000000002dae0 0x000000000003dae0 0x000000000003dae0
0x00000000000021e8 0x0000000000002320 RW 0x10000
LOAD 0x000000000002fe00 0x000000000003fe00 0x000000000003fe00
0x00000000000011ac 0x0000000000001328 RW 0x10000
The reason for this problem is the same as described in
commit ad55eac74f20 ("elf: enforce MAP_FIXED on overlaying elf segments").
Not only executable binaries, elf interpreters (e.g. ld.so) can have
overlapping elf segments, so we better drop MAP_FIXED_NOREPLACE and go
back to MAP_FIXED in load_elf_interp.
Fixes: 4ed28639519c ("fs, elf: drop MAP_FIXED usage from elf_map")
Cc: <[email protected]> # v4.19
Signed-off-by: Chen Jingwen <[email protected]>
---
fs/binfmt_elf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 69d900a8473d..a813b70f594e 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -630,7 +630,7 @@ static unsigned long load_elf_interp(struct elfhdr *interp_elf_ex,
vaddr = eppnt->p_vaddr;
if (interp_elf_ex->e_type == ET_EXEC || load_addr_set)
- elf_type |= MAP_FIXED_NOREPLACE;
+ elf_type |= MAP_FIXED;
else if (no_base && interp_elf_ex->e_type == ET_DYN)
load_addr = -vaddr;
--
2.12.3
(cc Linus)
On Tue, 28 Sep 2021 20:56:57 +0800 Chen Jingwen <[email protected]> wrote:
> In commit b212921b13bd ("elf: don't use MAP_FIXED_NOREPLACE for elf executable mappings")
> we still leave MAP_FIXED_NOREPLACE in place for load_elf_interp.
> Unfortunately, this will cause kernel to fail to start with
>
> [ 2.384321] 1 (init): Uhuuh, elf segment at 00003ffff7ffd000 requested but the memory is mapped already
> [ 2.386240] Failed to execute /init (error -17)
>
> The reason is that the elf interpreter (ld.so) has overlapping segments.
>
> readelf -l ld-2.31.so
> Program Headers:
> Type Offset VirtAddr PhysAddr
> FileSiz MemSiz Flags Align
> LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
> 0x000000000002c94c 0x000000000002c94c R E 0x10000
> LOAD 0x000000000002dae0 0x000000000003dae0 0x000000000003dae0
> 0x00000000000021e8 0x0000000000002320 RW 0x10000
> LOAD 0x000000000002fe00 0x000000000003fe00 0x000000000003fe00
> 0x00000000000011ac 0x0000000000001328 RW 0x10000
>
> The reason for this problem is the same as described in
> commit ad55eac74f20 ("elf: enforce MAP_FIXED on overlaying elf segments").
> Not only executable binaries, elf interpreters (e.g. ld.so) can have
> overlapping elf segments, so we better drop MAP_FIXED_NOREPLACE and go
> back to MAP_FIXED in load_elf_interp.
>
> Fixes: 4ed28639519c ("fs, elf: drop MAP_FIXED usage from elf_map")
> Cc: <[email protected]> # v4.19
> Signed-off-by: Chen Jingwen <[email protected]>
> ---
> fs/binfmt_elf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
> index 69d900a8473d..a813b70f594e 100644
> --- a/fs/binfmt_elf.c
> +++ b/fs/binfmt_elf.c
> @@ -630,7 +630,7 @@ static unsigned long load_elf_interp(struct elfhdr *interp_elf_ex,
>
> vaddr = eppnt->p_vaddr;
> if (interp_elf_ex->e_type == ET_EXEC || load_addr_set)
> - elf_type |= MAP_FIXED_NOREPLACE;
> + elf_type |= MAP_FIXED;
> else if (no_base && interp_elf_ex->e_type == ET_DYN)
> load_addr = -vaddr;
>
> --
> 2.12.3
On Tue, Sep 28, 2021 at 08:56:57PM +0800, Chen Jingwen wrote:
> In commit b212921b13bd ("elf: don't use MAP_FIXED_NOREPLACE for elf executable mappings")
> we still leave MAP_FIXED_NOREPLACE in place for load_elf_interp.
> Unfortunately, this will cause kernel to fail to start with
>
> [ 2.384321] 1 (init): Uhuuh, elf segment at 00003ffff7ffd000 requested but the memory is mapped already
> [ 2.386240] Failed to execute /init (error -17)
>
I guess you mean "init" fails to start (but yes, same result).
> The reason is that the elf interpreter (ld.so) has overlapping segments.
Ewww. What toolchain generated this (and what caused it to just start
happening)? (This was added in v4.17; it's been 3 years.)
>
> readelf -l ld-2.31.so
> Program Headers:
> Type Offset VirtAddr PhysAddr
> FileSiz MemSiz Flags Align
> LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
> 0x000000000002c94c 0x000000000002c94c R E 0x10000
> LOAD 0x000000000002dae0 0x000000000003dae0 0x000000000003dae0
> 0x00000000000021e8 0x0000000000002320 RW 0x10000
> LOAD 0x000000000002fe00 0x000000000003fe00 0x000000000003fe00
> 0x00000000000011ac 0x0000000000001328 RW 0x10000
>
> The reason for this problem is the same as described in
> commit ad55eac74f20 ("elf: enforce MAP_FIXED on overlaying elf segments").
> Not only executable binaries, elf interpreters (e.g. ld.so) can have
> overlapping elf segments, so we better drop MAP_FIXED_NOREPLACE and go
> back to MAP_FIXED in load_elf_interp.
We could also just expand the logic that fixed[1] this for ELF, yes?
Andrew, are you able to pick up [1], BTW? It seems to have fallen
through the cracks.
[1] https://lore.kernel.org/all/[email protected]/T/#u
>
> Fixes: 4ed28639519c ("fs, elf: drop MAP_FIXED usage from elf_map")
> Cc: <[email protected]> # v4.19
> Signed-off-by: Chen Jingwen <[email protected]>
> ---
> fs/binfmt_elf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
> index 69d900a8473d..a813b70f594e 100644
> --- a/fs/binfmt_elf.c
> +++ b/fs/binfmt_elf.c
> @@ -630,7 +630,7 @@ static unsigned long load_elf_interp(struct elfhdr *interp_elf_ex,
>
> vaddr = eppnt->p_vaddr;
> if (interp_elf_ex->e_type == ET_EXEC || load_addr_set)
> - elf_type |= MAP_FIXED_NOREPLACE;
> + elf_type |= MAP_FIXED;
> else if (no_base && interp_elf_ex->e_type == ET_DYN)
> load_addr = -vaddr;
--
Kees Cook
On Mon, 4 Oct 2021 13:00:07 -0700 Kees Cook <[email protected]> wrote:
> Andrew, are you able to pick up [1], BTW? It seems to have fallen
> through the cracks.
>
> [1] https://lore.kernel.org/all/[email protected]/T/#u
I added that to -mm on 19 September.:
https://ozlabs.org/~akpm/mmotm/broken-out/binfmt_elf-reintroduce-using-map_fixed_noreplace.patch
On Tue, Oct 05, 2021 at 04:12:12PM -0700, Andrew Morton wrote:
> On Mon, 4 Oct 2021 13:00:07 -0700 Kees Cook <[email protected]> wrote:
>
> > Andrew, are you able to pick up [1], BTW? It seems to have fallen
> > through the cracks.
> >
> > [1] https://lore.kernel.org/all/[email protected]/T/#u
>
> I added that to -mm on 19 September.:
> https://ozlabs.org/~akpm/mmotm/broken-out/binfmt_elf-reintroduce-using-map_fixed_noreplace.patch
Ah! Thank you. :)
--
Kees Cook
> > The reason is that the elf interpreter (ld.so) has overlapping segments.
> >
> Ewww. What toolchain generated this (and what caused it to just start
> happening)? (This was added in v4.17; it's been 3 years.)
gcc 7.3.0 for powerpc Book3E (e5500).
I wonder if there are some linker options related to the overlapping segments.
I tried to find it out why but I failed. And I also didn't see the answer in the
previous discussion yet (Maybe I missed it).
What confuses me is why the other reports only have overlapping sections for
executable binaries or dynamic libraries, but not for their ld.so.
I can keep looking for the reason but it may take a longe time for me.
> > readelf -l ld-2.31.so
> > Program Headers:
> > Type Offset VirtAddr PhysAddr
> > FileSiz MemSiz Flags Align
> > LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
> > 0x000000000002c94c 0x000000000002c94c R E 0x10000
> > LOAD 0x000000000002dae0 0x000000000003dae0 0x000000000003dae0
> > 0x00000000000021e8 0x0000000000002320 RW 0x10000
> > LOAD 0x000000000002fe00 0x000000000003fe00 0x000000000003fe00
> > 0x00000000000011ac 0x0000000000001328 RW 0x10000
> >
> > The reason for this problem is the same as described in
> > commit ad55eac74f20 ("elf: enforce MAP_FIXED on overlaying elf segments").
> > Not only executable binaries, elf interpreters (e.g. ld.so) can have
> > overlapping elf segments, so we better drop MAP_FIXED_NOREPLACE and go
> > back to MAP_FIXED in load_elf_interp.
>
> We could also just expand the logic that fixed[1] this for ELF, yes?
>
> Andrew, are you able to pick up [1], BTW? It seems to have fallen
> through the cracks.
>
> [1] https://lore.kernel.org/all/[email protected]/T/#u
Yes, I expand the logic[1] to load_elf_interp and "init" succeeds to start.
Should I submit another patch?