Linux EFI development
 help / color / mirror / Atom feed
* [PATCH v1] efi/runtime-wrappers: Avoid crashing on early PRM code invocations
@ 2026-05-15 17:10 Rafael J. Wysocki
  2026-05-15 17:29 ` Ard Biesheuvel
  0 siblings, 1 reply; 2+ messages in thread
From: Rafael J. Wysocki @ 2026-05-15 17:10 UTC (permalink / raw)
  To: Ard Biesheuvel; +Cc: Ilias Apalodimas, linux-efi, Linux ACPI, LKML

From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>

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@intel.com>
Cc: 6.6+ <stable@vger.kernel.org> # 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.

---
 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;
 	status = efi_queue_work(ACPI_PRM_HANDLER, handler_addr,
 				param_buffer_addr, context);
 	up(&efi_runtime_lock);




^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [PATCH v1] efi/runtime-wrappers: Avoid crashing on early PRM code invocations
  2026-05-15 17:10 [PATCH v1] efi/runtime-wrappers: Avoid crashing on early PRM code invocations Rafael J. Wysocki
@ 2026-05-15 17:29 ` Ard Biesheuvel
  0 siblings, 0 replies; 2+ messages in thread
From: Ard Biesheuvel @ 2026-05-15 17:29 UTC (permalink / raw)
  To: Rafael J . Wysocki; +Cc: Ilias Apalodimas, linux-efi, Linux ACPI, LKML

Hi Rafael,

On Fri, 15 May 2026, at 19:10, Rafael J. Wysocki wrote:
> From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
>
> 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@intel.com>
> Cc: 6.6+ <stable@vger.kernel.org> # 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);

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2026-05-15 17:29 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-05-15 17:10 [PATCH v1] efi/runtime-wrappers: Avoid crashing on early PRM code invocations Rafael J. Wysocki
2026-05-15 17:29 ` Ard Biesheuvel

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox