CVE-2024-50141: ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context
In the Linux kernel, the following vulnerability has been resolved:
ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context
PRMT needs to find the correct type of block to translate the PA-VA
mapping for EFI runtime services.
The issue arises because the PRMT is finding a block of type
EFI_CONVENTIONAL_MEMORY, which is not appropriate for runtime services
as described in Section 2.2.2 (Runtime Services) of the UEFI
Specification [1]. Since the PRM handler is a type of runtime service,
this causes an exception when the PRM handler is called.
[Firmware Bug]: Unable to handle paging request in EFI runtime service
WARNING: CPU: 22 PID: 4330 at drivers/firmware/efi/runtime-wrappers.c:341
__efi_queue_work+0x11c/0x170
Call trace:
Let PRMT find a block with EFI_MEMORY_RUNTIME for PRM handler and PRM
context.
If no suitable block is found, a warning message will be printed, but
the procedure continues to manage the next PRM handler.
However, if the PRM handler is actually called without proper allocation,
it would result in a failure during error handling.
By using the correct memory types for runtime services, ensure that the
PRM handler and the context are properly mapped in the virtual address
space during runtime, preventing the paging request error.
The issue is really that only memory that has been remapped for runtime
by the firmware can be used by the PRM handler, and so the region needs
to have the EFI_MEMORY_RUNTIME attribute.
[ rjw: Subject and changelog edits ]
Security readout for executives and security teams
Plain-English summary
A Linux kernel flaw can mishandle firmware-provided Platform Runtime Mechanism handlers. On systems using this feature, calling an incorrectly mapped handler may trigger a kernel paging exception, potentially disrupting the host. The supplied CVSS score is 7.8, reflecting serious local impact rather than remote exposure.
Executive priority
Treat this as a high-priority kernel maintenance issue for affected physical infrastructure, particularly systems reporting EFI runtime faults. It is not supported as an internet-exploitable emergency. Apply vendor updates through normal accelerated patching and validate firmware-dependent exposure before escalating broadly.
Technical view
The ACPI PRM code could select EFI_CONVENTIONAL_MEMORY when translating physical-to-virtual mappings for a PRM handler or context. Runtime handlers require memory carrying EFI_MEMORY_RUNTIME because firmware remaps only those regions for runtime use. Invoking an improperly mapped handler can cause an EFI runtime-service paging fault and failure during error handling.
Likely exposure
Exposure is limited to Linux systems whose firmware supplies ACPI PRM handlers and where an affected kernel invokes them. The bundled version data names affected Linux releases but does not provide sufficient range semantics for reliable fleet-wide matching. Confirm applicability through the operating-system vendor and kernel build provenance.
Exploitation context
The supplied vector describes local access, low complexity, low privileges, and no user interaction. However, the bundle contains no demonstrated attack path, exploit report, or evidence of active exploitation. The CVE is not listed as KEV in the supplied data.
Researcher notes
The correction requires PRM handler and context regions to carry EFI_MEMORY_RUNTIME. If no suitable block is found, processing continues with a warning; actual invocation without proper allocation may still fail during error handling. The sources do not establish confidentiality or integrity exploitation beyond the supplied CVSS assessment.
Mitigation direction
Upgrade to a vendor-supported kernel containing the applicable upstream stable correction.
Consult the Linux distribution or appliance vendor for exact affected and fixed package versions.
Prioritize systems exposing ACPI PRM firmware functionality or showing related EFI runtime faults.
Avoid treating upstream commit identifiers alone as package-version evidence.
Validation and detection
Inventory running kernel versions and distribution package revisions across physical systems.
Confirm each kernel contains the applicable stable fix or vendor backport.
Review kernel logs for PRM warnings, EFI runtime-service paging requests, or related call traces.
Verify firmware exposes ACPI PRM functionality before classifying a host as exposed.
Recheck vendor advisories because the bundled version boundaries are ambiguous.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2024-50141 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.