CVE-2026-43171

What it actually does

This Linux kernel flaw is an improper bounds check in EFI Common Platform Error Record (CPER) handling. When firmware supplies a malformed CPER record whose section offset is larger than the actual record length, the kernel subtracts the offset from the length without first validating that the offset is in range. That subtraction can underflow, causing the CPER error-printing path to attempt a very large hex dump of kernel memory. Depending on the memory range involved, the result can be prolonged CPU and I/O consumption while dumping memory, exposure of memory contents into kernel logs, or a kernel OOPS/panic if the dump path touches unmapped memory. The issue requires local privileges and a path to trigger or influence malformed firmware error records, so it is not a remote network attack by itself.

Why it matters to the business

Successful exploitation can destabilize Linux systems, generate large volumes of kernel log output, and potentially expose sensitive memory contents to anyone able to read those logs. The most likely operational consequence is local denial of service through kernel crash, hang, or severe log/CPU exhaustion. EPSS is very low and no public exploit or known exploited status is reported, but because this is kernel-level code, affected systems should still be patched during normal kernel maintenance cycles, with higher priority for systems where untrusted local users, shared compute workloads, or privileged hardware/firmware error interfaces are present.

How an attack unfolds

An attacker first needs local access with enough privilege to trigger or interact with a code path that causes the kernel to process an EFI CPER firmware error record. The attacker then causes or supplies a malformed CPER record with an invalid section offset greater than the available record length. On vulnerable kernels, the CPER printing routine fails to reject the invalid offset and computes a wrapped length. The kernel then attempts to hex dump far more memory than intended. This may flood logs and consume system resources, leak kernel memory contents into logs, or fault while reading an invalid address, producing an OOPS or panic. There is currently no indication of public exploit maturity or known exploitation in ransomware or CISA KEV campaigns.

How to fix it

Upgrade to a Linux kernel version that includes the EFI/CPER fix which validates CPER section length before performing the hex dump. No exact fixed package versions were provided in the input, so use the fixed kernel packages from the relevant Linux distribution, vendor advisory, or upstream stable kernel branch. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted users and workloads, protecting kernel log access, disabling unnecessary firmware error-reporting or debug/fault-injection interfaces where operationally safe, and ensuring kernel panic/reboot behavior is configured to support availability requirements.

How to confirm the fix worked

Confirm that deployed kernel packages include the vendor backport for the EFI/CPER bounds-check fix. Validate by checking the running kernel version with standard OS inventory tooling and comparing it against the distribution advisory or package changelog for the CPER fix. On source-based or custom kernels, confirm that the CPER printing path rejects records where the section length is smaller than the requested offset before calculating the dump length. After patching, reboot into the fixed kernel and verify that no older vulnerable kernel remains the default boot entry. Also confirm that kernel logs are not showing repeated CPER dumps, OOPS events, or panic traces related to firmware error records.

Typical attack path

1. Obtain local access to a Linux system running a vulnerable kernel.
2. Identify a way to trigger EFI/CPER firmware error-record processing, such as through hardware error reporting, firmware interfaces, or controlled fault-injection mechanisms available on the system.
3. Cause the kernel to parse a malformed CPER record whose section offset exceeds the actual record length.
4. Trigger the vulnerable CPER error-printing path.
5. Abuse the resulting oversized memory dump attempt to cause resource exhaustion, kernel log flooding, memory disclosure into logs, or a kernel OOPS/panic.

How to detect it

Look for evidence that the system recently processed malformed EFI/CPER firmware error records followed by excessive hex dumps, kernel OOPS messages, soft lockups, panics, or rapid growth in kernel logs. Useful sources include journald, /var/log/kern.log, /var/log/messages, /var/log/syslog, dmesg output, crash dumps, kdump/vmcore artifacts, and log-volume telemetry from centralized logging platforms. Search around CPER, EFI, firmware error, and hardware error messages for unusually large contiguous hex dumps or repeated records preceding instability. Also review authentication and process accounting logs to identify local users active immediately before the event, especially commands or tools associated with hardware error injection, firmware testing, debugfs, tracefs, or privileged kernel testing. Because no public exploit-specific payload is known, detection should focus on behavioral artifacts: CPER log flooding, unexpected kernel crashes, and unusually large kernel log entries containing memory-like hex output.

• cper_print_fw_err
• CPER
• Common Platform Error Record
• Firmware Error Record
• EFI Error Record
• Hardware Error Source
• APEI
• GHES
• Oops:
• kernel BUG
• BUG: kernel NULL pointer dereference
• Unable to handle kernel paging request
• general protection fault
• Kernel panic - not syncing
• soft lockup
• hard LOCKUP
• watchdog: BUG: soft lockup
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog
• /var/crash/
• /proc/vmcore
• /sys/kernel/debug/apei/einj

What your security team should do

• Inventory Linux systems that use EFI firmware and run affected kernel versions, prioritizing shared servers, multi-user systems, virtualization hosts, and systems running untrusted local workloads.
• Apply vendor-provided fixed kernel updates and reboot systems into the patched kernel during the next maintenance window; accelerate patching where untrusted local users have access.
• Restrict read access to kernel logs because exploitation may write memory contents into logs on vulnerable systems.
• Monitor for unusual CPER-related kernel log volume, kernel OOPS/panic events, and sudden growth in system journal or /var/log storage.
• Limit access to hardware error injection, firmware debugging, and other privileged interfaces that could be used to trigger malformed firmware error records.
• For custom kernels, backport the upstream EFI/CPER bounds-check change and regression-test firmware error handling before deployment.