use TOOLS_LIBDIR in definition of ZFCPDUMP_DIR #6
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@sharkcz : The patch looks good, but please include your "Signed-off-by". |
Signed-off-by: Dan Horák <dan@danny.cz>
|
updated, not sure one gets notified if the commit changes with "git push --force" |
|
Applied, thanks! |
At least I did not get a mail for that - but at least "git push -f" was correct :-) |
hoeppnerj
pushed a commit
that referenced
this pull request
May 7, 2018
double free or corruption (out) Program received signal SIGABRT, Aborted. 0x000003fffdd40404 in raise () from /lib64/libc.so.6 (gdb) bt #0 0x000003fffdd40404 in raise () from /lib64/libc.so.6 #1 0x000003fffdd41ec2 in abort () from /lib64/libc.so.6 #2 0x000003fffdd88d8e in __libc_message () from /lib64/libc.so.6 #3 0x000003fffdd905c8 in malloc_printerr () from /lib64/libc.so.6 #4 0x000003fffdd98dfa in free () from /lib64/libc.so.6 #5 0x0000000001005994 in util_ptr_vec_free (count=<optimized out>, ptr_vec=0x101de90) at ../include/lib/util_base.h:46 #6 util_scandir_free (de_vec=0x101de90, count=<optimized out>) at util_scandir.c:174 #7 0x00000000010043ce in print_defunct_devices (rec=rec@entry=0x10114f0, path=path@entry=0x101cc80 "/sys/devices/css0/defunct") at lscss.c:678 #8 0x0000000001004cfe in print_subchannels_of_type (type_requested=type_requested@entry=SUBCHANNEL_TYPE_IO, rec=rec@entry=0x10114f0) at lscss.c:726 #9 0x0000000001003888 in cmd_lscss () at lscss.c:761 #10 main (argc=<optimized out>, argv=<optimized out>) at lscss.c:932 Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com> Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
hoeppnerj
pushed a commit
that referenced
this pull request
Jan 25, 2021
If a memory chunk is added to mem_phys as well as mem_virt
in dfi_mem_chunk_add_vol() then an illegal memory access might occur
when accessing mem_chunk->data e.g. in dfi_elf_mem_chunk_read_fn()
because the data block pointed to by the data field is now being referenced
by two memory chunks, one in mem_phys and one in mem_virt. If it happens
that the memory chunk from mem_virt is freed in mem_unmap() then
the memory chunk in mem_phys still points to the common data block
which has been already freed. This leads to all sort of bad behavior
in dfi_elf_mem_chunk_read_fn() and other places where mem_chunk->data
might be accessed.
Fixes the following bug:
zgetdump: Unexpected end of file for "dump.all.elf"
And this was found by AddressSanitizer:
=================================================================
==81170==ERROR: AddressSanitizer: heap-use-after-free on address 0x602000000570 at pc 0x00000101ac10 bp 0x03ffd897e250 sp 0x03ffd897e248
READ of size 8 at 0x602000000570 thread T0
#0 0x101ac0f in dfi_elf_mem_chunk_read_fn s390-tools/zdump/dfi_elf.c:27
#1 0x100d8a5 in mem_read s390-tools/zdump/dfi.c:339
#2 0x100d8a5 in dfi_mem_phys_read s390-tools/zdump/dfi.c:616
#3 0x100d8a5 in mem_chunk_map_read_fn s390-tools/zdump/dfi.c:353
#4 0x100fd29 in mem_read s390-tools/zdump/dfi.c:339
#5 0x100fd29 in dfi_mem_read s390-tools/zdump/dfi.c:608
#6 0x1018e89 in os_info_get s390-tools/zdump/dfi_vmcoreinfo.c:65
#7 0x1018e89 in dfi_vmcoreinfo_init s390-tools/zdump/dfi_vmcoreinfo.c:86
#8 0x10175b3 in dfi_init s390-tools/zdump/dfi.c:1215
#9 0x1006e71 in do_stdout s390-tools/zdump/zgetdump.c:161
#10 0x1006e71 in main s390-tools/zdump/zgetdump.c:180
#11 0x3ffb07abb89 in __libc_start_main (/lib64/libc.so.6+0x2bb89)
#12 0x1007e8d (s390-tools/zdump/zgetdump+0x1007e8d)
0x602000000570 is located 0 bytes inside of 8-byte region [0x602000000570,0x602000000578)
freed by thread T0 here:
#0 0x3ffb0bc961b in free (/lib64/libasan.so.6+0xc961b)
#1 0x100d2d9 in mem_unmap s390-tools/zdump/dfi.c:1050
previously allocated by thread T0 here:
#0 0x3ffb0bc9aa9 in calloc (/lib64/libasan.so.6+0xc9aa9)
#1 0x100a271 in zg_alloc s390-tools/zdump/zg.c:93
SUMMARY: AddressSanitizer: heap-use-after-free s390-tools/zdump/dfi_elf.c:27 in dfi_elf_mem_chunk_read_fn
Shadow bytes around the buggy address:
0x100c0400000050: fa fa 00 fa fa fa 00 fa fa fa 00 fa fa fa 00 fa
0x100c0400000060: fa fa 00 fa fa fa 00 fa fa fa 00 fa fa fa 00 fa
0x100c0400000070: fa fa 00 fa fa fa 00 fa fa fa 00 fa fa fa 00 fa
0x100c0400000080: fa fa 00 fa fa fa 00 fa fa fa 00 fa fa fa 00 fa
0x100c0400000090: fa fa 00 fa fa fa 00 fa fa fa 00 fa fa fa 00 fa
=>0x100c04000000a0: fa fa 00 fa fa fa 00 fa fa fa 00 fa fa fa[fd]fa
0x100c04000000b0: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
0x100c04000000c0: fa fa fd fa fa fa fd fa fa fa fd fa fa fa 04 fa
0x100c04000000d0: fa fa 00 fa fa fa 00 fa fa fa 00 fa fa fa 00 fa
0x100c04000000e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x100c04000000f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Shadow gap: cc
==81170==ABORTING
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Reviewed-by: Philipp Rudo <prudo@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
hoeppnerj
pushed a commit
that referenced
this pull request
Oct 1, 2021
Verify that a s390 dump header contains a valid CPU count value.
This bug was found with an input file produced by AFL + ASAN.
$ ./zdump/zgetdump -i ~/input.bin
=================================================================
==3928488==ERROR: AddressSanitizer: global-buffer-overflow on address 0x000001043e90 at pc 0x000001025dca bp 0x03ffe96fe128 sp 0x03ffe96fe120
READ of size 4 at 0x000001043e90 thread T0
#0 0x1025dc9 in df_s390_cpu_info_add /root/s390-tools/zdump/df_s390.c:57
#1 0x101bb59 in dfi_s390_init_gen /root/s390-tools/zdump/dfi_s390.c:169
#2 0x101bb59 in dfi_s390_init_gen /root/s390-tools/zdump/dfi_s390.c:156
#3 0x1015d23 in dfi_init /root/s390-tools/zdump/dfi.c:1216
#4 0x1006a0d in do_dump_info /root/s390-tools/zdump/zgetdump.c:127
#5 0x1006a0d in main /root/s390-tools/zdump/zgetdump.c:182
#6 0x3ffb93abe03 in __libc_start_main (/lib64/libc.so.6+0x2be03)
#7 0x10077bd (/root/s390-tools/zdump/zgetdump+0x10077bd)
0x000001043e91 is located 0 bytes to the right of global variable 'l' defined in 'dfi_s390.c:30:3' (0x1042e80) of size 4113
SUMMARY: AddressSanitizer: global-buffer-overflow /root/s390-tools/zdump/df_s390.c:57 in df_s390_cpu_info_add
Shadow bytes around the buggy address:
0x10000000208780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10000000208790: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100000002087a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100000002087b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100000002087c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x100000002087d0: 00 00[01]f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
0x100000002087e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100000002087f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10000000208800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10000000208810: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10000000208820: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Shadow gap: cc
==3928488==ABORTING
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
hoeppnerj
pushed a commit
that referenced
this pull request
Oct 1, 2021
Verify that the mem chunk_cache pointer is valid before using it.
This prevents potential illegal memory accesses.
This problem was found with AFL fuzzing and ASAN.
./zdump/zgetdump -iVVVVV ~/zgetdump-fuzzing/findings/crashes/id\:000007\,sig\:06\,src\:000007\,op\:flip1\,pos\:37
TRACE: DFI initialization
DEBUG: DFI trying s390tape
DEBUG: DFI s390tape returned with rc -19
DEBUG: DFI trying devmem
DEBUG: DFI devmem returned with rc -19
DEBUG: DFI trying s390mv_ext
DEBUG: DFI s390mv_ext returned with rc -19
DEBUG: DFI trying s390mv
DEBUG: DFI s390mv returned with rc -19
DEBUG: DFI trying s390_ext
DEBUG: DFI S390 extended initialization
DEBUG: DFI s390_ext returned with rc -19
DEBUG: DFI trying s390
DEBUG: DFI S390 initialization
DEBUG: DFI s390 returned with rc -19
DEBUG: DFI trying lkcd
DEBUG: DFI lkcd returned with rc -19
DEBUG: DFI trying elf
DEBUG: DFI ELF initialization
DEBUG: DFI ELF e_phnum 11
DEBUG: DFI ELF p_type[0] 0x6060606
DEBUG: DFI ELF p_type[1] 0x6060606
DEBUG: DFI ELF p_type[2] 0x6060606
DEBUG: DFI ELF p_type[3] 0x6060606
DEBUG: DFI ELF p_type[4] 0x6060606
DEBUG: DFI ELF p_type[5] 0x6060606
DEBUG: DFI ELF p_type[6] 0x6060606
DEBUG: DFI ELF p_type[7] 0x6060606
DEBUG: DFI ELF p_type[8] 0x6060606
DEBUG: DFI ELF p_type[9] 0x6060606
DEBUG: DFI ELF p_type[10] 0x6060606
TRACE: DFI kdump initialization
AddressSanitizer:DEADLYSIGNAL
=================================================================
==206692==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x000001016a12 bp 0x03ffcc57eae0 sp 0x03ffcc57eae0 T0)
==206692==The signal is caused by a UNKNOWN memory access.
==206692==Hint: address points to the zero page.
#0 0x1016a12 in mem_chunk_has_addr /root/s390-tools/zdump/dfi.c:308
#1 0x1016a12 in mem_chunk_find /root/s390-tools/zdump/dfi.c:318
#2 0x1016a12 in dfi_mem_chunk_find /root/s390-tools/zdump/dfi.c:513
#3 0x1016a12 in dfi_mem_range_valid /root/s390-tools/zdump/dfi.c:208
#4 0x1016a12 in kdump_init /root/s390-tools/zdump/dfi.c:1100
#5 0x1016a12 in dfi_init /root/s390-tools/zdump/dfi.c:1253
#6 0x1006d3d in do_dump_info /root/s390-tools/zdump/zgetdump.c:127
#7 0x1006d3d in main /root/s390-tools/zdump/zgetdump.c:182
#8 0x3ff9e0abe03 in __libc_start_main (/lib64/libc.so.6+0x2be03)
#9 0x1007d7d (/root/s390-tools/zdump/zgetdump+0x1007d7d)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /root/s390-tools/zdump/dfi.c:308 in mem_chunk_has_addr
==206692==ABORTING
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
hoeppnerj
pushed a commit
that referenced
this pull request
Oct 1, 2021
Validate that the addition of the parameters @addr and @len given to `dfi_mem_range_valid()` does not overflow 64bit unsigned integer type. This fixes the following segmentation fault: [#0] 0x2aa000084fc → mem_read(mem=0x2aa00021b68 <l+152>, addr=0xffffffffffffffff, buf=0x3ffffffec64, cnt=0xc) [#1] 0x2aa00009964 → dfi_mem_read(addr=0xfffffffffffffffa, buf=0x3ffffffec64, cnt=0xc) [#2] 0x2aa00009c86 → dfi_mem_read_rc(addr=0xfffffffffffffffa, buf=0x3ffffffec64, cnt=0xc) [#3] 0x2aa0000ba42 → dfi_vmcoreinfo_init() [#4] 0x2aa0000b496 → dfi_init() [#5] 0x2aa00005aa6 → do_dump_info() [#6] 0x2aa00005c82 → main(argc=<optimized out>, argv=0x3fffffff118) Reviewed-by: Alexander Egorenkov <egorenar@linux.ibm.com> Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com> Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It will allow a single override of the TOOLS_LIBDIR value in Fedora to accommodate the UsrMove changes.