CVE-2021-47134

What it actually does

Null pointer dereference in efi/fdt handling when initial_boot_params remains unset after efi_get_fdt_params finds no valid FDT, causing kernel panic during setup_arch on affected architectures.

Why it matters to the business

Boot-time system crashes on platforms such as RISC-V can interrupt deployments, extend maintenance windows, and reduce availability of affected Linux systems.

How an attack unfolds

During early boot an attacker-supplied or missing FDT leads efi_init to call efi_get_fdt_params; the resulting null initial_boot_params is dereferenced in subsequent FDT processing, triggering the panic before userspace starts.

How to fix it

Upgrade python3-simpleline on AlmaLinux 8 to version 1.1.1-2.el8 or later; apply the upstream kernel commit that adds the early return when no valid FDT is present.

How to confirm the fix worked

Confirm the fixed package version is installed, then attempt boot on RISC-V hardware or QEMU without a valid FDT and verify the kernel no longer panics.

Typical attack path

1. Boot the system with an absent or invalid FDT passed via EFI parameters
2. efi_init invokes efi_get_fdt_params which leaves initial_boot_params null
3. Further FDT processing dereferences the null pointer and panics the kernel

How to detect it

Review early boot logs for kernel panics referencing efi_get_fdt_params or initial_boot_params; correlate with RISC-V or EFI boot attempts that lack an FDT blob.

What your security team should do

• Prioritize patching systems that boot via EFI on RISC-V or similar architectures
• Monitor EPSS and KEV status for any future increase in exploit activity
• Include the fixed package version in standard image builds and update pipelines