Security Fixes

CVE-2011-3588

Kdump used the Secure Shell (SSH) StrictHostKeyChecking=no option when dumping to SSH targets, causing the target kdump server's SSH host key not to be checked. This could make it easier for a man-in-the-middle attacker on the local network to impersonate the kdump SSH target server and possibly gain access to sensitive information in the vmcore dumps.

CVE-2011-3589

mkdumprd created initial RAM disk (initrd) files with world-readable permissions. A local user could possibly use this flaw to gain access to sensitive information, such as the private SSH key used to authenticate to a remote server when kdump was configured to dump to an SSH target.

CVE-2011-3590

mkdumprd included unneeded sensitive files (such as all files from the /root/.ssh/ directory and the host's private SSH keys) in the resulting initrd. This could lead to an information leak when initrd files were previously created with world-readable permissions.

Note

With this update, only the SSH client configuration, known hosts files, and the SSH key configured via the newly introduced sshkey option in /etc/kdump.conf are included in the initrd. The default is the key generated when running the service kdump propagate command, /root/.ssh/kdump_id_rsa.

Bug Fixes

BZ#681796

Kdump is a kexec based crash dumping mechanism for Linux. Root System Description Pointer (RSDP) is a data structure used in the ACPI programming interface. Kdump uses kexec to boot to a second kernel, the "dump-capture" or "crash kernel", when a dump of the system kernel's memory needs to be taken. On systems using Extensible Firmware Interface (EFI), attempting to boot a second kernel using kdump failed, the dump-capture kernel became unresponsive and the following error message was logged.

ACPI Error: A valid RSDP was not found

With this update, a new parameter, acpi_rsdp, has been added to the noefi kernel command. Now, if EFI is detected, a command is given to the second kernel, in the format, noefi acpi_rsdp=X, not to use EFI and simultaneously passes the address of RSDP to the second kernel. The second kernel now boots successfully on EFI machines.

BZ#693025

To reduce the size of the vmcore dump file, kdump allows you to specify an external application (that is, a core collector) to compress the data. The core collector was not enabled by default when dumping to a secure location via SSH. Consequently, if users had not specified an argument for core_collector in kdump.conf, when kdump was configured to dump kernel data to a secure location using SSH, it generated a complete vmcore, without removing free pages. With this update, the default core collector will be makedumpfile when kdump is configured to use SSH. As a result, the vmcore dump file is now compressed by default.

BZ#707805

Previously, the mkdumprd utility failed to parse the /etc/mdadm.conf configuration file. As a consequence, mkdumprd failed to create an initial RAM disk file system (initrd) for kdump crash recovery and the kdump service failed to start. With this update, mkdumprd has been modified so that it now parses the configuration file and builds initrd correctly. The kdump service now starts as expected.

BZ#708503

In order for Coverity to scan defects in downstream patches separately, it is necessary to make a clean raw build of the source code without patches. However, kexec-tools would not build without downstream patches. With this update, by adding a specified patch in kexec-tools spec file, kexec-tools can now be built from source in the scenario described.

BZ#709441

On 64-bit PowerPC-based systems with more than 1 TB of RAM, the kexec-tools utility terminated unexpectedly with a segmentation fault when kdump was started, thus preventing crash kernel capture. With this update, the problem has been fixed, kexec-tools no longer crashes, and kdump can now be used on a system with greater than 1 TB of physical memory.

BZ#719105

The mkdumprd utility creates an initial RAM disk file system (initrd) for use in conjunction with the booting of a second kernel within the kdump framework for crash recovery. Prior to this update, mkdumprd became unresponsive when the running kernel was not the same as the target kernel. With this update the problem has been fixed and mkdumprd no longer hangs in the scenario described.

BZ#731236

A regression caused the following erroneous error message to be displayed when kdump was setting up Ethernet network connections in order to reach a remote dump target:

sed: /etc/cluster_iface: No such file or directory

A patch has been applied to correct the problem and the error no longer occurs in the scenario described.

BZ#731394

During kdump start up, a check was made to see if the amount of RAM the currently running kernel was using was more than 70% of the amount of RAM reserved for kdump. If the memory in use was greater than 70% of the memory reserved, the following error message was displayed.

Your running kernel is using more than 70% of the amount of space you reserved for kdump, you should consider increasing your crashkernel reservation

Due to improvements in conserving memory in the kexec kernel the warning is no longer considered valid. This update removes the warning.

BZ#739050

Previously, if kexec-tools was installed and kdump was not running, installing the fence-agents package caused the following erroneous error message:

Non-fatal <unknown> scriptlet failure in rpm package

This update corrects the kexec-tools spec file and the erroneous error message no longer appears.

BZ#746207

Removing kexec-tools on IBM System z resulted in the following error, even though the package was successfully removed.

error reading information on service kdump: No such file or directory

With this update, changes have been made to the kexec-tools spec file and the erroneous error message no longer appears.

BZ#747233

When providing firmware at operating system install time, supplied as part of the Driver Update program (DUP), the installation completed successfully but the operating system would fail on reboot. An error message in the following format was displayed:

cp: cannot stat `/lib/firmware/*': No such file or directory

With this update, a check for the directory containing the DUP supplied firmware is made and the problem no longer occurs.

Enhancements

BZ#585332

With large memory configurations, some machines take a long time to dump state information when a kernel panic occurs. The cluster software sometimes forced a reboot before the dump completed. With this update, co-ordination between kdump and cluster fencing for long kernel panic dumps is added.

BZ#598067

A new configuration option in kdump.conf, force_rebuild, has been added. When enabled, this option forces the kdump init script to rebuild initrd every time the system starts, thus ensuring kdump has enough storage space on each system start-up.

BZ#725484

On x86, AMD64 & Intel 64 platforms kexec-tools now uses nr_cpus=1 rather than maxcpus=1 to save memory required by the second kernel. PowerPC platforms currently cannot handle this feature.

BZ#727892

A warning was added to use maxcpus=1 instead of nr_cpus=1 for older kernels (see the enhancement above).

BZ#734528

Kdump has been provided with an option so that memory usage can be logged in the second kernel at various stages for debugging memory consumption issues. The second kernel memory usage debugging capability can be enabled via the new kdump.conf debug_mem_level option.

BZ#740275, BZ#740277

With this update, kdump support for dumping core to ext4 file systems, and also to XFS file systems on data disks (but not the root disk) has been added.

Note

For XFS, the XFS layer product needs to be installed. Layered products are those not included by default in the base Red Hat Enterprise Linux operating system.

BZ#740278

With this update, kdump support for dumping core to Btrfs file systems has been added.

Note

BusyBox's "findfs" utility does not yet support Btrfs, so UUID/LABEL resolving does not work. Avoid using UUID/LABEL syntax when dumping core to Btrfs file systems. Btrfs itself is still considered experimental; refer to Red Hat Technical Notes.

BZ#748748

Kdump did not check the return code of the mount command. Consequently, when the command mount -t debugfs debug /sys/kernel/debug was issued in the kdump service script, if the file system was already mounted, the message returned was erroneously logged as an error message. With this update, the logic in the kdump service script has been improved and the kdump service script now functions as expected.

BZ#719917

Previously, the mkdumprd utility failed to parse the /etc/mdadm.cof configuration file. As a consequence, mkdumprd failed to create an initial ramdisk for kdump crash recovery and the kdump service failed to start. With this update, mkdumprd has been modified so that it now parses the configuration file and builds initrd correctly. The kdump service now starts as expected.

BZ#726603

On the PowerPC 64 architecture, the kexec utiliity experienced a segmentation fault when the kdump service was started on a system containing more than 1 TB of RAM. As a result, it was not possible to capture a crash kernel on such a system. This has been fixed with this update so that kexec no longer crashes when kdump starts on a system with greater than 1 TB of physical memory, and kdump can now works as expected.