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>
Verify the given ELF header before adding any memory chunks otherwise
a memory chunk might be added even if the given ELF header is invalid.
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>
When using zgetdump on a multi-volume device dump, the sysfs path to
determine the device node is incomplete, resulting in the following
error:
$ zgetdump -i /dev/dasdb1
zgetdump: Could not open "/sys/bus/ccw/devices/0.0.9300/dasdb/dev" (No
such file or directory)
A simple fix would be to add the missing "block" part in the sysfs path.
However, the logic still assumes sysfs links like "block:" that have
been deprecated a decade ago and are no longer present on modern
systems anyway.
Therefore, the logic can greatly be improved. Create a separate function
to determine whether a device is online, remove the logic for "block:"
entries, and use libutil functions to reduce the complexity even further.
Fixes: 70a79fab3c ("zgetdump: Avoid using PATH_MAX")
Reviewed-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Consolidate `ALIGN, __ALIGN_MASK, ARRAY_SIZE` macros and add them to
lib/zt_common.h. While at it, adapt coding style.
Reviewed-by: Philipp Rudo <prudo@linux.ibm.com>
Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
We can safely replace strncpy() with memcpy() here and get rid of the
following compile warnings:
dfi_s390mv.c: In function ‘set_magic_numbers’:
dfi_s390mv.c:570:3: warning: ‘strncpy’ output truncated before
terminating nul copying 7 bytes fr om a string of the same length
[-Wstringop-truncation]
strncpy(l.dumper_magic, DF_S390_DUMPER_MAGIC_MV_EXT, 7);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
dfi_s390mv.c:573:3: warning: ‘strncpy’ output truncated before
terminating nul copying 7 bytes fr om a string of the same length
[-Wstringop-truncation]
strncpy(l.dumper_magic, DF_S390_DUMPER_MAGIC_MV, 7);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Using inappropriate sizes for snprintf() leads to the following compile
warnings:
dfi_s390mv.c: In function ‘dev_from_busid’:
dfi_s390mv.c:116:34: warning: ‘/online’ directive output may be
truncated writing 7 bytes into a region of size between 1 and 4096
[-Wformat-truncation=]
snprintf(tmp_file, PATH_MAX, "%s/online", dev_file);
^~~~~~~
dfi_s390mv.c:116:2: note: ‘snprintf’ output between 8 and 4103 bytes
into a destination of size 4096
snprintf(tmp_file, PATH_MAX, "%s/online", dev_file);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
dfi_s390mv.c:143:35: warning: ‘%s’ directive output may be truncated
writing up to 255 bytes into a region of size between 0 and 4095
[-Wformat-truncation=]
snprintf(tmp_file, PATH_MAX, "%s/%s/dev", dev_file, direntp->d_name);
^~
dfi_s390mv.c:143:2: note: ‘snprintf’ output between 6 and 4356 bytes
into a destination of size 4096
snprintf(tmp_file, PATH_MAX, "%s/%s/dev", dev_file, direntp->d_name);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A simple fix would be to use different suitable fixed sizes for tmp_file
and dev_file. However, the code can be improved here a little.
Use the libutil function util_path_sysfs() to build the sysfs path
string. This is more robust, as the function will figure out the correct
mount point of the sysfs. util_path_sysfs() will also terminate
execution, if no sysfs mount point could be found. That means, we can
get rid of check_sysfs().
Furthermore, the two variables (tmp_file, dev_file) can be combined to
one. Also, check the return value of open() and act accordingly.
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
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>
Add verbose option for zgetdump to display the detailed layout of memory
map when printing dump info for s390_ext or ELF dump format.
Signed-off-by: Mikhail Zaslonko <zaslonko@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Adjust ELF formatted dump processing by zgetdump tool in order to handle
so-called zero loads using zero memory chunks introduced with s390
extended dump format.
Signed-off-by: Mikhail Zaslonko <zaslonko@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
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>
Update 'zgetdump -d' to process the new DASD dump tool installed (single
volume or multi-volume).
Signed-off-by: Mikhail Zaslonko <zaslonko@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Update df_s390_dumper structure and dumper reading functions to read
certain dumper fields instead of the entire dump tool.
Update other s390 dump common functions in preparation for the new dumper
and the new s390 extended dump format.
Signed-off-by: Mikhail Zaslonko <zaslonko@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
When dump is not complete or dump memory limit is set, zgetdump might end up
with the Segfault on reading Vector Registers. That might take place when
the Vector Registers save area is beyond the dump memory limit.
Signed-off-by: Mikhail Zaslonko <zaslonko@linux.vnet.ibm.com>
Reviewed-by: Philipp Rudo <prudo@linux.vnet.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
When calculating partition start offset during multi-volume dump processing,
the result of multiplication is truncated to 32-bits thus resulting in
invalid behavior in case the real offset is beyond 4Gig boundary.
Signed-off-by: Mikhail Zaslonko <zaslonko@linux.vnet.ibm.com>
Reviewed-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
With gcc 7 we get warnings like the following:
fdasd.c: In function 'main':
fdasd.c:3055:4: warning: this statement may fall through
[-Wimplicit-fallthrough=]
fdasd_exit(&anchor, 0);
^~~~~~~~~~~~~~~~~~~~~~
fdasd.c:3056:3: note: here
default:
^~~~~~~
Fix this by marking functions with "__noreturn" to help gcc.
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
With gcc 7 the compiler checks for sprintf() the maxium possible resulting
string based on the used datatypes.
Example:
struct vol {
...
char bus_id[9];
...
}
sprintf(vol->bus_id, "0.%x.%04x", ssid, vol_parm->devno);
The compiler can prove that "ssid" comes from "u8" and "vol_parm->devno"
from "u16". Therefore the resulting maximum string can be 0.ff.ffff which
requires 10 bytes.
This leads to the following warning:
dfi_s390mv.c: In function 'volumes_init':
dfi_s390mv.c:243:45: warning: '__builtin___snprintf_chk' output may be
truncated before the last format character [-Wformat-truncation=]
snprintf(vol->bus_id, sizeof(vol->bus_id), "0.%x.%04x", ssid,
^~~~~~~~~~~
In file included from /usr/include/stdio.h:936:0,
from dfi_s390mv.c:15:
/usr/include/bits/stdio2.h:64:10: note: '__builtin___snprintf_chk' output
between 9 and 10 bytes into a destination of size 9
return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
__bos (__s), __fmt, __va_arg_pack ());
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To get rid of the warning use 10 instead of 9 bytes for the bus_id.
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
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>
