CVE-2026-53047

What it actually does

This vulnerability is an incorrect allocation-size bug in the Linux kernel EFI capsule loader. During EFI capsule handling, the kernel reallocates an array intended to store physical addresses using the size of a pointer rather than the size of phys_addr_t. On most 64-bit systems those sizes are equal, so the bug is not observable. On affected 32-bit systems with PAE, phys_addr_t can be 64 bits while pointers are 32 bits, causing the kernel to allocate too little memory. Subsequent writes of physical addresses can overflow the heap allocation, potentially corrupting adjacent kernel memory. Practical impact is most likely local denial of service through kernel crash or memory corruption, with possible local privilege escalation depending on allocator layout, kernel hardening, and exploitability conditions.

Why it matters to the business

Organizations running affected Linux kernels on 32-bit PAE EFI-capable systems may be exposed to a kernel memory corruption flaw reachable through the EFI capsule loader interface. If exploited, the most likely operational impact is system instability, crashes, or failed firmware-update workflows; in a worst case, a local attacker with sufficient access to the capsule loader device could attempt to gain elevated privileges. The issue is not currently listed in CISA KEV, has very low EPSS, and has no known public exploit maturity, so urgency is lower than for actively exploited remote flaws, but it should still be remediated through normal kernel patching because kernel memory corruption issues can have high consequence on exposed systems.

How an attack unfolds

An attacker first needs local access to a vulnerable Linux system where the EFI capsule loader is enabled and reachable, typically via the EFI capsule device used for firmware update delivery. The attacker then writes crafted capsule data in a pattern that causes the kernel to expand the internal physical-address array in __efi_capsule_setup_info(). On vulnerable 32-bit PAE systems, the reallocation reserves space as though each entry were pointer-sized rather than phys_addr_t-sized, producing an undersized heap buffer. As additional capsule pages are processed, efi_capsule_write() stores physical addresses into that undersized array and can write past the end of the allocation. The resulting heap corruption may crash the kernel immediately, trigger allocator/KASAN diagnostics, or, under favorable conditions, corrupt adjacent kernel objects in a way that could be shaped toward privilege escalation. Exploitation is constrained by local access requirements, architecture-specific impact, kernel configuration, device permissions, and modern kernel hardening.

How to fix it

Apply a vendor-provided kernel update that includes the upstream fix for the EFI capsule loader allocation-size bug. Where exact package fixed versions are not available, remediate by moving to the latest stable kernel or distribution security kernel that references the fix for the EFI capsule loader phys_addr_t allocation issue. Prioritize affected 32-bit PAE EFI systems and systems where untrusted local users can access firmware update mechanisms. If immediate patching is not possible, reduce exposure by restricting permissions on /dev/efi_capsule_loader to trusted administrative users only, disabling or unloading EFI capsule loader functionality where operationally acceptable, disabling unused firmware-update workflows, and ensuring local users cannot invoke fwupd or direct capsule writes without authorization. Systems running 64-bit kernels are less likely to be affected by the undersized allocation condition described, but should still receive vendor kernel updates because fixes are generally shipped as part of broader kernel maintenance.

How to confirm the fix worked

Confirm remediation by checking that the running kernel version matches a vendor release containing the EFI capsule loader fix, not just that an updated package is installed. Validate with uname -a, distribution package tools, and vendor advisories. Confirm whether EFI capsule loader support is present by checking for /dev/efi_capsule_loader, relevant kernel configuration such as CONFIG_EFI_CAPSULE_LOADER, and loaded firmware-update components. On 32-bit systems, confirm whether PAE is enabled and whether phys_addr_t is 64-bit according to the vendor architecture configuration. After patching, reboot into the fixed kernel and verify the previous vulnerable kernel is not still selected by the bootloader. For mitigation validation, confirm that /dev/efi_capsule_loader is absent, inaccessible to non-administrative users, or protected by expected device permissions and access-control policy.

Typical attack path

1. Identify a Linux host running an affected kernel with EFI capsule loader support enabled.
2. Confirm the system is in the vulnerable architecture class, especially 32-bit with PAE where phys_addr_t is larger than a pointer.
3. Obtain local access with permission to write to the EFI capsule loader device, commonly /dev/efi_capsule_loader.
4. Submit crafted or oversized EFI capsule data that causes the kernel to reallocate the internal physical-address array.
5. Trigger efi_capsule_write() to store additional physical addresses into the undersized allocation.
6. Cause kernel heap corruption, resulting in a crash, panic, or potentially controlled corruption for local privilege escalation.

How to detect it

To determine whether exploitation may already have occurred, review host kernel logs and centralized log aggregation for evidence of kernel memory corruption during EFI capsule operations. Relevant log sources include dmesg, journald, /var/log/kern.log, /var/log/messages, auditd, endpoint telemetry, crash dump repositories, and firmware-update service logs such as fwupd logs. Look for kernel oops, panic, slab corruption, KASAN, UBSAN, or page-allocation diagnostics that include efi_capsule_open, efi_capsule_write, __efi_capsule_setup_info, efi_capsule_setup_info, or efi_capsule_loader. Correlate these events with file access or writes to /dev/efi_capsule_loader and process execution by fwupd, fwupdmgr, custom firmware-update utilities, shells, scripting runtimes, or unknown binaries. Investigate unexpected capsule loader access outside approved maintenance windows, repeated kernel crashes around firmware update attempts, or capsule writes performed by non-administrative or non-update processes. Where auditd is enabled, search for PATH or SYSCALL records referencing /dev/efi_capsule_loader with write access. If crash dumps are available, inspect stack traces for EFI capsule loader functions and heap corruption near the phys array allocation path. Absence of these artifacts does not prove non-exploitation because successful memory corruption may leave limited logs, but crashes and KASAN traces are the most likely observable evidence.

• /dev/efi_capsule_loader
• efi_capsule_loader
• efi_capsule_write
• efi_capsule_open
• __efi_capsule_setup_info
• efi_capsule_setup_info
• BUG: KASAN
• slab-out-of-bounds
• heap buffer overflow
• kernel BUG
• Oops:
• general protection fault
• Kernel panic
• fwupd
• fwupdmgr
• CONFIG_EFI_CAPSULE_LOADER

What your security team should do

• Inventory Linux systems for EFI capsule loader exposure, especially 32-bit PAE EFI systems and legacy appliances.
• Patch affected systems using vendor kernel updates and reboot to ensure the fixed kernel is active.
• Restrict access to /dev/efi_capsule_loader to trusted administrative update workflows only.
• Review firmware update tooling such as fwupd for appropriate authorization controls and audit logging.
• Monitor kernel logs for crashes, allocator corruption, KASAN reports, or oops traces involving EFI capsule loader functions.
• Treat unexpected writes to /dev/efi_capsule_loader by non-update processes as suspicious and investigate promptly.
• Because the flaw is not KEV-listed, has low EPSS, and has no known exploit maturity, handle through standard kernel vulnerability remediation timelines unless local multi-user exposure or untrusted shell access increases risk.