f15e32cdb1
zdump/dfi: Fix illegal memory access in dfi_cpu_add_from_lc()
...
Check that a CPU's lowcore address falls within a valid memory region
before accessing it. This prevents potential illegal memory accesses
in case a dump contains invalid CPU lowcore addresses.
This bug was found with AFL fuzzing and ASAN.
Starting program: /root/s390-tools/zdump/zgetdump -iVVVVV /root/zgetdump-fuzzing/findings/crashes/id:000004,sig:06,src:000005,op:flip32,pos:3055
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
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
INFO: DFI S390 version 5
DEBUG: DFI S390 mem_size 0x00000000000dbba0
DEBUG: DFI add vol mem chunk start 0x0000000000000000 size 0x00000000000dbba0 volnr 0
[snip]
TRACE: DFI virt mem read addr 0x0000000000000000 size 0x0000000000002000
TRACE: DFI virt mem read addr 0x0000000000000000 size 0x0000000000002000
TRACE: DFI virt mem read addr 0x0000000000000000 size 0x0000000000002000
TRACE: DFI virt mem read addr 0x0000000000000000 size 0x0000000000002000
TRACE: DFI virt mem read addr 0x0000000000000000 size 0x0000000000002000
TRACE: DFI virt mem read addr 0x0000000000000000 size 0x0000000000002000
TRACE: DFI virt mem read addr 0x0000000000000000 size 0x0000000000002000
TRACE: DFI virt mem read addr 0x0000000000000000 size 0x0000000000002000
TRACE: DFI virt mem read addr 0x0000000000000000 size 0x0000000000002000
TRACE: DFI virt mem read addr 0x0000000000000000 size 0x0000000000002000
TRACE: DFI virt mem read addr 0x0000000000000000 size 0x0000000000002000
TRACE: DFI virt mem read addr 0x0000000000000000 size 0x0000000000002000
TRACE: DFI virt mem read addr 0x0000000000000000 size 0x0000000000002000
TRACE: DFI virt mem read addr 0x0000000000000000 size 0x0000000000002000
TRACE: DFI virt mem read addr 0x00000000000000ff size 0x0000000000002000
TRACE: DFI virt mem read addr 0x00000000ffffff00 size 0x0000000000002000
Program received signal SIGSEGV, Segmentation fault.
0x000000000100fbb0 in mem_read (cnt=<optimized out>, buf=0x3ffffffc7d0, addr=4294967040, mem=0x104b218 <l+152>) at dfi.c:339
339 size = MIN(cnt - copied, mem_chunk->end - addr + 1);
Missing separate debuginfos, use: dnf debuginfo-install fuse-libs-2.9.9-11.fc34.s390x glibc-2.33-20.1.ibm.fc34.s390x libasan-11.0.1-0.3.1.ibm.fc34.s390x libgcc-11.0.1-0.3.1.ibm.fc34.s390x libstdc++-11.0.1-0.3.1.ibm.fc34.s390x zlib-1.2.11-26.fc34.s390x
(gdb) bt
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com >
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com >
2021-10-01 14:59:56 +02:00
025a2198a4
zdump/dfi_s390: Fix use of uninitialized stack value in mem_chunks_add_ext()
...
If the while loop in mem_chunks_add_ext() is never executed, then
the stack variable containing the dump segment header will never be
initialized.
clang's static code analyzer reports the following problem:
$ make CC="clang --analyze" -C zdump
dfi_s390.c:157:6: warning: Branch condition evaluates to a garbage value [core.uninitialized.Branch]
if (!dump_segm.stop_marker)
^~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com >
Reported-by: Marc Hartmayer <mhartmay@linux.ibm.com >
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com >
2021-10-01 14:53:14 +02:00
2b938b78aa
zdump: Introduce multi-level message logging
...
Use util_log from libutil to output various log messages that can be helpful
during problem analysis.
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com >
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com >
2021-10-01 14:53:14 +02:00
e3e5b6422a
zdump/dfi_s390: Fix out-of-bounds array access in df_s390_cpu_info_add()
...
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 >
2021-10-01 14:53:14 +02:00
0e2c5907e0
zdump/dfi_s390: Fix memory leaks in mem_chunks_add_ext()
...
The function mem_chunks_add_ext() allocates but does not release memory
if it encounters unexpected errors during dump segment reading.
Allocate memory passed to dfi_mem_chunk_add() right before calling
the function. This way there is no need for a cleanup anymore.
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com >
Reviewed-by: Marc Hartmayer <mhartmay@linux.ibm.com >
Reported-by: Marc Hartmayer <mhartmay@linux.ibm.com >
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com >
2021-10-01 14:53:13 +02:00
cf99ea019e
zgetdump: Add 'Dump file size' field for zgetdump -i output
...
Add 'Dump file size' field for zgetdump -i output to show the actual size
of dump file in s390 extended format on disk in megabytes.
Signed-off-by: Mikhail Zaslonko <zaslonko@linux.ibm.com >
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com >
2018-05-07 13:42:03 +02:00
4a223c70f2
zgetdump: Update zgetdump to process the new dump format
...
Update zgetdump tool to process dumps of the new s390 extended format.
Signed-off-by: Mikhail Zaslonko <zaslonko@linux.ibm.com >
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com >
2018-05-07 13:42:03 +02:00
b627b8d8e1
Initial s390-tools-2.0.0 import
...
This commit is based on the s390-tools-1.39.0 version.
Changes on top of s390-tools-1.39.0:
- Add MIT license to all source files
- Add LICENSE file
- Transform REAMDE to README.md (markdown)
- Add AUTHORS.md file
- Add CONTRIBUTING.md file
- Move changelog from README to CHANGELOG.md file
Reviewed-by: Stefan Haberland <sth@linux.vnet.ibm.com >
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com >
2017-08-21 10:55:40 +02:00
Alexander Egorenkov