Commit Graph

1 Commits

Author SHA1 Message Date
Philipp Rudo 7620d676de print error when reading with unsupported compression
Resolves: bz2069200
Upstream: github.com/makedumpfile/makedumpfile.git
Conflicts: goto out_error --> return FALSE
	   due to missing 64b5b29 ("[PATCH 03/15] remove variable length
	   array in readpage_kdump_compressed()")

commit 5035c0821f07da3badda645cd0064d4b80e1667d
Author: Philipp Rudo <prudo@redhat.com>
Date:   Mon Mar 14 17:04:32 2022 +0100

    [PATCH] print error when reading with unsupported compression

    Currently makedumpfile only checks if the required compression algorithm
    was enabled during build when compressing a dump but not when reading
    from one. This can lead to situations where, one version of makedumpfile
    creates the dump using a compression algorithm an other version of
    makedumpfile doesn't support. When the second version now tries to, e.g.
    extract the dmesg from the dump it will fail with an error similar to

      # makedumpfile --dump-dmesg vmcore dmesg.txt
      __vtop4_x86_64: Can't get a valid pgd.
      readmem: Can't convert a virtual address(ffffffff92e18284) to physical address.
      readmem: type_addr: 0, addr:ffffffff92e18284, size:390
      check_release: Can't get the address of system_utsname.

      makedumpfile Failed.

    That's because readpage_kdump_compressed{_parallel} does not return
    with an error if the page it is trying to read is compressed with an
    unsupported compression algorithm. Thus readmem copies random data from
    the (uninitialized) cachebuf to its caller and thus causing the error
    above.

    Fix this by checking if the required compression algorithm is supported
    in readpage_kdump_compressed{_parallel} and print a proper error message
    if it isn't.

    Reported-by: Dave Wysochanski <dwysocha@redhat.com>
    Signed-off-by: Philipp Rudo <prudo@redhat.com>
    Reviewed-and-tested-by: Dave Wysochanski <dwysocha@redhat.com>
    Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>

Signed-off-by: Philipp Rudo <prudo@redhat.com>
2022-03-28 19:19:43 +02:00