kernel/linux.git/fs/binfmt_flat.c, branch v6.12.80

binfmt_flat: Fix integer overflow bug on 32 bit systems

2025-02-17T09:05:04+00:00

commit 55cf2f4b945f6a6416cc2524ba740b83cc9af25a upstream. Most of these sizes and counts are capped at 256MB so the math doesn't result in an integer overflow. The "relocs" count needs to be checked as well. Otherwise on 32bit systems the calculation of "full_data" could be wrong. full_data = data_len + relocs * sizeof(unsigned long); Fixes: c995ee28d29d ("binfmt_flat: prevent kernel dammage from corrupted executable headers") Cc: stable@vger.kernel.org Signed-off-by: Dan Carpenter Acked-by: Nicolas Pitre Link: https://lore.kernel.org/r/5be17f6c-5338-43be-91ef-650153b975cb@stanley.mountain Signed-off-by: Kees Cook Signed-off-by: Greg Kroah-Hartman

move asm/unaligned.h to linux/unaligned.h

2024-10-02T21:23:23+00:00

asm/unaligned.h is always an include of asm-generic/unaligned.h; might as well move that thing to linux/unaligned.h and include that - there's nothing arch-specific in that header. auto-generated by the following: for i in `git grep -l -w asm/unaligned.h`; do sed -i -e "s/asm\/unaligned.h/linux\/unaligned.h/" $i done for i in `git grep -l -w asm-generic/unaligned.h`; do sed -i -e "s/asm-generic\/unaligned.h/linux\/unaligned.h/" $i done git mv include/asm-generic/unaligned.h include/linux/unaligned.h git mv tools/include/asm-generic/unaligned.h tools/include/linux/unaligned.h sed -i -e "/unaligned.h/d" include/asm-generic/Kbuild sed -i -e "s/__ASM_GENERIC/__LINUX/" include/linux/unaligned.h tools/include/linux/unaligned.h

binfmt_flat: Fix corruption when not offsetting data start

2024-08-10T03:19:00+00:00

Commit 04d82a6d0881 ("binfmt_flat: allow not offsetting data start") introduced a RISC-V specific variant of the FLAT format which does not allocate any space for the (obsolete) array of shared library pointers. However, it did not disable the code which initializes the array, resulting in the corruption of sizeof(long) bytes before the DATA segment, generally the end of the TEXT segment. Introduce MAX_SHARED_LIBS_UPDATE which depends on the state of CONFIG_BINFMT_FLAT_NO_DATA_START_OFFSET to guard the initialization of the shared library pointer region so that it will only be initialized if space is reserved for it. Fixes: 04d82a6d0881 ("binfmt_flat: allow not offsetting data start") Co-developed-by: Stefan O'Rear Signed-off-by: Stefan O'Rear Reviewed-by: Damien Le Moal Acked-by: Greg Ungerer Link: https://lore.kernel.org/r/20240807195119.it.782-kees@kernel.org Signed-off-by: Kees Cook

binfmt_flat: Remove shared library support

2022-04-22T17:57:18+00:00

In a recent discussion[1] it was reported that the binfmt_flat library support was only ever used on m68k and even on m68k has not been used in a very long time. The structure of binfmt_flat is different from all of the other binfmt implementations because of this shared library support and it made life and code review more effort when I refactored the code in fs/exec.c. Since in practice the code is dead remove the binfmt_flat shared library support and make maintenance of the code easier. [1] https://lkml.kernel.org/r/81788b56-5b15-7308-38c7-c7f2502c4e15@linux-m68k.org Signed-off-by: "Eric W. Biederman" Reviewed-by: Damien Le Moal Acked-by: Vladimir Murzin # ARM Tested-by: Patrice Chotard Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/87levzzts4.fsf_-_@email.froward.int.ebiederm.org

binfmt_flat: Drop vestiges of coredump support

2022-04-20T02:31:43+00:00

There is the briefest start of coredump support in binfmt_flat. It is actually a pain to maintain as binfmt_flat is not built on most architectures so it is easy to overlook. Since the support does not do anything remove it. Signed-off-by: "Eric W. Biederman" Reviewed-by: Niklas Cassel Acked-by: Greg Ungerer Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/87mtgh17li.fsf_-_@email.froward.int.ebiederm.org

binfmt_flat: do not stop relocating GOT entries prematurely on riscv

2022-04-18T22:02:50+00:00

bFLT binaries are usually created using elf2flt. The linker script used by elf2flt has defined the .data section like the following for the last 19 years: .data : { _sdata = . ; __data_start = . ; data_start = . ; *(.got.plt) *(.got) FILL(0) ; . = ALIGN(0x20) ; LONG(-1) . = ALIGN(0x20) ; ... } It places the .got.plt input section before the .got input section. The same is true for the default linker script (ld --verbose) on most architectures except x86/x86-64. The binfmt_flat loader should relocate all GOT entries until it encounters a -1 (the LONG(-1) in the linker script). The problem is that the .got.plt input section starts with a GOTPLT header (which has size 16 bytes on elf64-riscv and 8 bytes on elf32-riscv), where the first word is set to -1. See the binutils implementation for riscv [1]. This causes the binfmt_flat loader to stop relocating GOT entries prematurely and thus causes the application to crash when running. Fix this by skipping the whole GOTPLT header, since the whole GOTPLT header is reserved for the dynamic linker. The GOTPLT header will only be skipped for bFLT binaries with flag FLAT_FLAG_GOTPIC set. This flag is unconditionally set by elf2flt if the supplied ELF binary has the symbol _GLOBAL_OFFSET_TABLE_ defined. ELF binaries without a .got input section should thus remain unaffected. Tested on RISC-V Canaan Kendryte K210 and RISC-V QEMU nommu_virt_defconfig. [1] https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=bfd/elfnn-riscv.c;hb=binutils-2_38#l3275 Cc: Signed-off-by: Niklas Cassel Reviewed-by: Damien Le Moal Link: https://lore.kernel.org/r/20220414091018.896737-1-niklas.cassel@wdc.com Fixed-by: kernel test robot Link: https://lore.kernel.org/lkml/202204182333.OIUOotK8-lkp@intel.com Signed-off-by: Kees Cook

coredump: Don't compile flat_core_dump when coredumps are disabled

2022-03-09T16:37:07+00:00

Recently the kernel test robot reported: > In file included from include/linux/kernel.h:29, > from fs/binfmt_flat.c:21: > fs/binfmt_flat.c: In function 'flat_core_dump': > >> fs/binfmt_flat.c:121:50: error: invalid use of undefined type 'struct coredump_params' > 121 | current->comm, current->pid, cprm->siginfo->si_signo); > | ^~ > include/linux/printk.h:418:33: note: in definition of macro 'printk_index_wrap' > 418 | _p_func(_fmt, ##__VA_ARGS__); \ > | ^~~~~~~~~~~ > include/linux/printk.h:499:9: note: in expansion of macro 'printk' > 499 | printk(KERN_WARNING pr_fmt(fmt), ##__VA_ARGS__) > | ^~~~~~ > fs/binfmt_flat.c:120:9: note: in expansion of macro 'pr_warn' > 120 | pr_warn("Process %s:%d received signr %d and should have core dumped\n", > | ^~~~~~~ > At top level: > fs/binfmt_flat.c:118:12: warning: 'flat_core_dump' defined but not used [-Wunused-function] > 118 | static int flat_core_dump(struct coredump_params *cprm) > | ^~~~~~~~~~~~~~ The little dinky do nothing function flat_core_dump has always been compiled unconditionally. With my change to move coredump_params into coredump.h coredump_params reasonably becomes unavailable when coredump support is not compiled in. Fix this old issue by simply not compiling flat_core_dump when coredump support is not supported. Fixes: a99a3e2efaf1 ("coredump: Move definition of struct coredump_params into coredump.h") Reported-by: kernel test robot Signed-off-by: "Eric W. Biederman"

coredump: Move definition of struct coredump_params into coredump.h

2022-03-08T18:50:58+00:00

Move the definition of struct coredump_params into coredump.h where it belongs. Remove the slightly errorneous comment explaining why struct coredump_params was declared in binfmts.h. Signed-off-by: "Eric W. Biederman"

binfmt: move more stuff undef CONFIG_COREDUMP

2022-03-02T00:16:27+00:00

struct linux_binfmt::core_dump and struct min_coredump::min_coredump are used under CONFIG_COREDUMP only. Shrink those embedded configs a bit. Signed-off-by: Alexey Dobriyan Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/YglbIFyN+OtwVyjW@localhost.localdomain

binfmt: remove in-tree usage of MAP_EXECUTABLE

2021-06-29T17:53:50+00:00

Ever since commit e9714acf8c43 ("mm: kill vma flag VM_EXECUTABLE and mm->num_exe_file_vmas"), VM_EXECUTABLE is gone and MAP_EXECUTABLE is essentially completely ignored. Let's remove all usage of MAP_EXECUTABLE. [akpm@linux-foundation.org: fix blooper in fs/binfmt_aout.c. per David] Link: https://lkml.kernel.org/r/20210421093453.6904-3-david@redhat.com Signed-off-by: David Hildenbrand Acked-by: "Eric W. Biederman" Reviewed-by: Kees Cook Cc: Alexander Shishkin Cc: Alexander Viro Cc: Arnaldo Carvalho de Melo Cc: Borislav Petkov Cc: Catalin Marinas Cc: Don Zickus Cc: Feng Tang Cc: Greg Ungerer Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Jiri Olsa Cc: Kevin Brodsky Cc: Mark Rutland Cc: Michal Hocko Cc: Mike Rapoport Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Thomas Gleixner Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds