CVE-2021-47134 in Linux
Summary
by MITRE • 03/15/2024
In the Linux kernel, the following vulnerability has been resolved:
efi/fdt: fix panic when no valid fdt found
setup_arch() would invoke efi_init()->efi_get_fdt_params(). If no valid fdt found then initial_boot_params will be null. So we should stop further fdt processing here. I encountered this issue on risc-v.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 02/27/2025
The vulnerability described in CVE-2021-47134 represents a critical kernel panic condition within the Linux kernel's EFI firmware device tree handling mechanism on risc-v architectures. This flaw occurs during the system initialization phase when the kernel attempts to process firmware device tree (fdt) information through the efi_init() function. The issue manifests specifically when the kernel cannot locate or validate a proper device tree blob, leading to a null pointer dereference that results in immediate system panic and termination of the boot process. The vulnerability affects systems utilizing the risc-v architecture where EFI firmware is employed to manage system initialization and hardware configuration discovery.
The technical root cause of this vulnerability lies in the improper handling of null pointer conditions within the device tree processing pipeline. During the setup_arch() initialization sequence, the kernel calls efi_init() which subsequently invokes efi_get_fdt_params() to retrieve firmware device tree parameters. When the system fails to locate a valid device tree blob, the function returns a null value for initial_boot_params, but the subsequent code does not properly check for this null condition before proceeding with further device tree processing operations. This lack of null pointer validation creates a direct path to kernel panic, as the system attempts to operate on a null pointer reference rather than gracefully handling the absence of valid firmware device tree information. The vulnerability demonstrates a classic failure in defensive programming practices where proper error handling and null pointer validation are omitted.
The operational impact of this vulnerability extends beyond simple system instability to encompass complete boot failure scenarios on affected risc-v systems. When a system encounters this condition during boot, it will experience an immediate kernel panic that prevents normal system operation and renders the device unusable until the underlying firmware or kernel is updated. This affects not only individual systems but also deployment scenarios where automated boot processes or embedded systems relying on risc-v architecture may fail to initialize properly. The vulnerability is particularly concerning in production environments where system reliability is paramount, as it can lead to unexpected downtime and service disruption. The issue affects systems that depend on EFI firmware for boot management and device tree configuration, particularly in server and embedded computing environments where risc-v processors are increasingly deployed.
Mitigation strategies for this vulnerability require kernel updates that implement proper null pointer validation within the EFI device tree processing code. The fix involves adding explicit checks for null initial_boot_params before proceeding with further device tree processing operations, ensuring that the system gracefully handles cases where valid firmware device tree information is unavailable. System administrators should prioritize applying kernel patches that address this specific null pointer dereference issue, particularly on risc-v systems that utilize EFI firmware for boot management. Organizations should also consider implementing firmware update procedures that ensure all system components are running compatible versions that include the necessary security patches. This vulnerability highlights the importance of robust error handling in kernel space code and demonstrates how seemingly minor oversight in null pointer validation can lead to complete system failure, aligning with CWE-476 which addresses null pointer dereference issues in software development. The fix also aligns with ATT&CK technique T1547.001 which involves system service modifications and kernel-level integrity protection that should prevent such conditions from causing system instability during boot processes.