Re: [PATCH v1] efi/runtime-wrappers: Avoid crashing on early PRM code invocations

From: Ard Biesheuvel

Date: Fri May 15 2026 - 13:31:27 EST


Hi Rafael,

On Fri, 15 May 2026, at 19:10, Rafael J. Wysocki wrote:
> From: "Rafael J. Wysocki" <rafael.j.wysocki@xxxxxxxxx>
>
> There is a dependency between EFI and ACPI PRM that the latter cannot
> run until the former is ready and PRM can be invoked from AML early
> through acpi_platformrt_space_handler(). If that happens before
> initializing efi_rts_wq, it leads to a NULL pointer dereference.
>
> Avoid that by adding an efi_rts_wq check against NULL to
> efi_call_acpi_prm_handler().
>
> Fixes: 5894cf571e14 ("acpi/prmt: Use EFI runtime sandbox to invoke PRM
> handlers")
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx>
> Cc: 6.6+ <stable@xxxxxxxxxxxxxxx> # 6.6+
> ---
>
> An alternative would be to somehow ensure that efisubsys_init() will always
> run before acpi_init(), but moving any of them to another initcall level is
> not an option AFAICS.
>

Given that they both run as subsys_initcall() currently, changing acpi_init()
to subsys_initcall_sync() is probably fine (famous last words :-))

But if the PRM code can deal with EFI_NOT_READY than this is also fine,
modulo the comment below.


> ---
> drivers/firmware/efi/runtime-wrappers.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> --- a/drivers/firmware/efi/runtime-wrappers.c
> +++ b/drivers/firmware/efi/runtime-wrappers.c
> @@ -590,6 +590,8 @@ efi_call_acpi_prm_handler(efi_status_t (
>
> if (down_interruptible(&efi_runtime_lock))
> return EFI_ABORTED;
> + if (!efi_rts_wq)
> + return EFI_NOT_READY;

This should occur before taking the semaphore

> status = efi_queue_work(ACPI_PRM_HANDLER, handler_addr,
> param_buffer_addr, context);
> up(&efi_runtime_lock);