linux-stable.git/fs/binfmt_elf.c, branch linux-5.17.y

revert "fs/binfmt_elf: use PT_LOAD p_align values for static PIE"

2022-04-20T07:36:24+00:00

commit aeb7923733d100b86c6bc68e7ae32913b0cec9d8 upstream.

Despite Mike's attempted fix (925346c129da117122), regressions reports
continue:

  https://lore.kernel.org/lkml/cb5b81bd-9882-e5dc-cd22-54bdbaaefbbc@leemhuis.info/
  https://bugzilla.kernel.org/show_bug.cgi?id=215720
  https://lkml.kernel.org/r/b685f3d0-da34-531d-1aa9-479accd3e21b@leemhuis.info

So revert this patch.

Fixes: 9630f0d60fec ("fs/binfmt_elf: use PT_LOAD p_align values for static PIE")
Cc: Alexey Dobriyan 
Cc: Al Viro 
Cc: Chris Kennelly 
Cc: David Rientjes 
Cc: Fangrui Song 
Cc: H.J. Lu 
Cc: Hugh Dickins 
Cc: Ian Rogers 
Cc: Kirill A. Shutemov 
Cc: Mike Kravetz 
Cc: Mike Rapoport 
Cc: Nick Desaulniers 
Cc: Sandeep Patil 
Cc: Shuah Khan 
Cc: Song Liu 
Cc: Suren Baghdasaryan 
Cc: Thorsten Leemhuis 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

revert "fs/binfmt_elf: fix PT_LOAD p_align values for loaders"

2022-04-20T07:36:24+00:00

commit 354e923df042a11d1ab8ca06b3ebfab3a018a4ec upstream.

Commit 925346c129da11 ("fs/binfmt_elf: fix PT_LOAD p_align values for
loaders") was an attempt to fix regressions due to 9630f0d60fec5f
("fs/binfmt_elf: use PT_LOAD p_align values for static PIE").

But regressionss continue to be reported:

  https://lore.kernel.org/lkml/cb5b81bd-9882-e5dc-cd22-54bdbaaefbbc@leemhuis.info/
  https://bugzilla.kernel.org/show_bug.cgi?id=215720
  https://lkml.kernel.org/r/b685f3d0-da34-531d-1aa9-479accd3e21b@leemhuis.info

This patch reverts the fix, so the original can also be reverted.

Fixes: 925346c129da11 ("fs/binfmt_elf: fix PT_LOAD p_align values for loaders")
Cc: H.J. Lu 
Cc: Chris Kennelly 
Cc: Al Viro 
Cc: Alexey Dobriyan 
Cc: Song Liu 
Cc: David Rientjes 
Cc: Ian Rogers 
Cc: Hugh Dickins 
Cc: Suren Baghdasaryan 
Cc: Sandeep Patil 
Cc: Fangrui Song 
Cc: Nick Desaulniers 
Cc: Kirill A. Shutemov 
Cc: Mike Kravetz 
Cc: Shuah Khan 
Cc: Thorsten Leemhuis 
Cc: Mike Rapoport 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

coredump: Use the vma snapshot in fill_files_note

2022-04-08T11:59:04+00:00

commit 390031c942116d4733310f0684beb8db19885fe6 upstream.

Matthew Wilcox reported that there is a missing mmap_lock in
file_files_note that could possibly lead to a user after free.

Solve this by using the existing vma snapshot for consistency
and to avoid the need to take the mmap_lock anywhere in the
coredump code except for dump_vma_snapshot.

Update the dump_vma_snapshot to capture vm_pgoff and vm_file
that are neeeded by fill_files_note.

Add free_vma_snapshot to free the captured values of vm_file.

Reported-by: Matthew Wilcox 
Link: https://lkml.kernel.org/r/20220131153740.2396974-1-willy@infradead.org
Cc: stable@vger.kernel.org
Fixes: a07279c9a8cd ("binfmt_elf, binfmt_elf_fdpic: use a VMA list snapshot")
Fixes: 2aa362c49c31 ("coredump: extend core dump note section to contain file names of mapped files")
Reviewed-by: Kees Cook 
Signed-off-by: "Eric W. Biederman" 
Signed-off-by: Greg Kroah-Hartman

coredump/elf: Pass coredump_params into fill_note_info

2022-04-08T11:59:04+00:00

commit 9ec7d3230717b4fe9b6c7afeb4811909c23fa1d7 upstream.

Instead of individually passing cprm->siginfo and cprm->regs
into fill_note_info pass all of struct coredump_params.

This is preparation to allow fill_files_note to use the existing
vma snapshot.

Reviewed-by: Jann Horn 
Reviewed-by: Kees Cook 
Signed-off-by: "Eric W. Biederman" 
Signed-off-by: Greg Kroah-Hartman

coredump: Snapshot the vmas in do_coredump

2022-04-08T11:59:04+00:00

commit 95c5436a4883841588dae86fb0b9325f47ba5ad3 upstream.

Move the call of dump_vma_snapshot and kvfree(vma_meta) out of the
individual coredump routines into do_coredump itself.  This makes
the code less error prone and easier to maintain.

Make the vma snapshot available to the coredump routines
in struct coredump_params.  This makes it easier to
change and update what is captures in the vma snapshot
and will be needed for fixing fill_file_notes.

Reviewed-by: Jann Horn 
Reviewed-by: Kees Cook 
Signed-off-by: "Eric W. Biederman" 
Signed-off-by: Greg Kroah-Hartman

fs/binfmt_elf: Fix AT_PHDR for unusual ELF files

2022-04-08T11:58:37+00:00

[ Upstream commit 0da1d5002745cdc721bc018b582a8a9704d56c42 ]

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=197921

As pointed out in the discussion of buglink, we cannot calculate AT_PHDR
as the sum of load_addr and exec->e_phoff.

: The AT_PHDR of ELF auxiliary vectors should point to the memory address
: of program header. But binfmt_elf.c calculates this address as follows:
:
: NEW_AUX_ENT(AT_PHDR, load_addr + exec->e_phoff);
:
: which is wrong since e_phoff is the file offset of program header and
: load_addr is the memory base address from PT_LOAD entry.
:
: The ld.so uses AT_PHDR as the memory address of program header. In normal
: case, since the e_phoff is usually 64 and in the first PT_LOAD region, it
: is the correct program header address.
:
: But if the address of program header isn't equal to the first PT_LOAD
: address + e_phoff (e.g.  Put the program header in other non-consecutive
: PT_LOAD region), ld.so will try to read program header from wrong address
: then crash or use incorrect program header.

This is because exec->e_phoff
is the offset of PHDRs in the file and the address of PHDRs in the
memory may differ from it. This patch fixes the bug by calculating the
address of program headers from PT_LOADs directly.

Signed-off-by: Akira Kawata 
Reported-by: kernel test robot 
Acked-by: Kees Cook 
Signed-off-by: Kees Cook 
Link: https://lore.kernel.org/r/20220127124014.338760-2-akirakawata1@gmail.com
Signed-off-by: Sasha Levin

Merge tag 'binfmt_elf-v5.17-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux

2022-03-01T19:31:37+00:00

Pull binfmt_elf fix from Kees Cook:
 "This addresses a regression[1] under ia64 where some ET_EXEC binaries
  were not loading"

Link: https://linux-regtracking.leemhuis.info/regzbot/regression/a3edd529-c42d-3b09-135c-7e98a15b150f@leemhuis.info/ [1]

- Fix ia64 ET_EXEC loading

* tag 'binfmt_elf-v5.17-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux:
  binfmt_elf: Avoid total_mapping_size for ET_EXEC

binfmt_elf: Avoid total_mapping_size for ET_EXEC

2022-03-01T18:29:20+00:00

Partially revert commit 5f501d555653 ("binfmt_elf: reintroduce using
MAP_FIXED_NOREPLACE"), which applied the ET_DYN "total_mapping_size"
logic also to ET_EXEC.

At least ia64 has ET_EXEC PT_LOAD segments that are not virtual-address
contiguous (but _are_ file-offset contiguous). This would result in a
giant mapping attempting to cover the entire span, including the virtual
address range hole, and well beyond the size of the ELF file itself,
causing the kernel to refuse to load it. For example:

$ readelf -lW /usr/bin/gcc
...
Program Headers:
  Type Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   ...
...
  LOAD 0x000000 0x4000000000000000 0x4000000000000000 0x00b5a0 0x00b5a0 ...
  LOAD 0x00b5a0 0x600000000000b5a0 0x600000000000b5a0 0x0005ac 0x000710 ...
...
       ^^^^^^^^ ^^^^^^^^^^^^^^^^^^                    ^^^^^^^^ ^^^^^^^^

File offset range     : 0x000000-0x00bb4c
			0x00bb4c bytes

Virtual address range : 0x4000000000000000-0x600000000000bcb0
			0x200000000000bcb0 bytes

Remove the total_mapping_size logic for ET_EXEC, which reduces the
ET_EXEC MAP_FIXED_NOREPLACE coverage to only the first PT_LOAD (better
than nothing), and retains it for ET_DYN.

Ironically, this is the reverse of the problem that originally caused
problems with MAP_FIXED_NOREPLACE: overlapping PT_LOAD segments. Future
work could restore full coverage if load_elf_binary() were to perform
mappings in a separate phase from the loading (where it could resolve
both overlaps and holes).

Cc: Eric Biederman 
Cc: Alexander Viro 
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-mm@kvack.org
Reported-by: matoro 
Fixes: 5f501d555653 ("binfmt_elf: reintroduce using MAP_FIXED_NOREPLACE")
Link: https://lore.kernel.org/r/a3edd529-c42d-3b09-135c-7e98a15b150f@leemhuis.info
Tested-by: matoro 
Link: https://lore.kernel.org/lkml/ce8af9c13bcea9230c7689f3c1e0e2cd@matoro.tk
Tested-By: John Paul Adrian Glaubitz 
Link: https://lore.kernel.org/lkml/49182d0d-708b-4029-da5f-bc18603440a6@physik.fu-berlin.de
Cc: stable@vger.kernel.org
Signed-off-by: Kees Cook

fs/binfmt_elf: fix PT_LOAD p_align values for loaders

2022-02-12T01:55:00+00:00

Rui Salvaterra reported that Aisleroit solitaire crashes with "Wrong
__data_start/_end pair" assertion from libgc after update to v5.17-rc1.

Bisection pointed to commit 9630f0d60fec ("fs/binfmt_elf: use PT_LOAD
p_align values for static PIE") that fixed handling of static PIEs, but
made the condition that guards load_bias calculation to exclude loader
binaries.

Restoring the check for presence of interpreter fixes the problem.

Link: https://lkml.kernel.org/r/20220202121433.3697146-1-rppt@kernel.org
Fixes: 9630f0d60fec ("fs/binfmt_elf: use PT_LOAD p_align values for static PIE")
Signed-off-by: Mike Rapoport 
Reported-by: Rui Salvaterra 
Tested-by: Rui Salvaterra 
Cc: Alexander Viro 
Cc: Eric Biederman 
Cc: "H.J. Lu" 
Cc: Kees Cook 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

fs/binfmt_elf: use PT_LOAD p_align values for static PIE

2022-01-20T06:52:54+00:00

Extend commit ce81bb256a22 ("fs/binfmt_elf: use PT_LOAD p_align values
for suitable start address") which fixed PIE binaries built with
-Wl,-z,max-page-size=0x200000, to cover static PIE binaries.  This
fixes:

    https://bugzilla.kernel.org/show_bug.cgi?id=215275

Tested by verifying static PIE binaries with -Wl,-z,max-page-size=0x200000 loading.

Link: https://lkml.kernel.org/r/20211209174052.370537-1-hjl.tools@gmail.com
Signed-off-by: H.J. Lu 
Cc: Chris Kennelly 
Cc: Al Viro 
Cc: Alexey Dobriyan 
Cc: Song Liu 
Cc: David Rientjes 
Cc: Ian Rogers 
Cc: Hugh Dickins 
Cc: Suren Baghdasaryan 
Cc: Sandeep Patil 
Cc: Fangrui Song 
Cc: Nick Desaulniers 
Cc: Kirill A. Shutemov 
Cc: Mike Kravetz 
Cc: Shuah Khan 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds