Re: [PATCH 1/4] ACPI: APEI: GHES: Use spin_lock_irqsave() for CXL CPER work locks

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Missing bounds check on CPER record length and `dvsec_len` allows an out-of-bounds memory read that can be leaked to userspace via trace events.
--

--- Patch [1]: [PATCH 1/4] ACPI: APEI: GHES: Use spin_lock_irqsave() for CXL CPER work locks ---
commit 92925c77a9085c947d2733f2a851c54ec53288f8
Author: Dave Jiang <dave.jiang@intel.com>

ACPI: APEI: GHES: Use spin_lock_irqsave() for CXL CPER work locks

This patch switches the cxl_cper_work_lock and cxl_cper_prot_err_work_lock
from plain spinlocks to spin_lock_irqsave(). This prevents a potential deadlock
when a GHES error interrupt interrupts a thread holding the lock in process
context.

Link: https://sashiko.dev/#/patchset/20260617-topics-ahmtib01-ras_ffh_arm_internal_review-v6-0-91f725174aa0@arm.com?part=6

> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
> index 3236a3ce79d6b..9b6917698ed24 100644
> --- a/drivers/acpi/apei/ghes.c
> +++ b/drivers/acpi/apei/ghes.c
[ ... ]
> @@ -863,7 +863,7 @@ int cxl_cper_unregister_work(struct work_struct *work)
>  	if (cxl_cper_work != work)
>  		return -EINVAL;
>  
> -	guard(spinlock)(&cxl_cper_work_lock);
> +	guard(spinlock_irqsave)(&cxl_cper_work_lock);
>  	cxl_cper_work = NULL;
>  	return 0;
>  }

[Severity: High]
This is a pre-existing issue, but looking at the CXL CPER work queue
handling, is there a potential out-of-bounds read when processing
malformed CPER records?

In drivers/acpi/apei/ghes_helpers.c:cxl_cper_setup_prot_err_work_data(),
the cap_start pointer is computed using an untrusted dvsec_len from the
firmware:

    dvsec_start = (u8 *)(prot_err + 1);
    cap_start = dvsec_start + prot_err->dvsec_len;

    memcpy(&wd->ras_cap, cap_start, sizeof(wd->ras_cap));

Since dvsec_len is provided by firmware, could a maliciously large value
cause cap_start to point outside the mapped CPER record bounds?

Similarly, in drivers/acpi/apei/ghes.c:cxl_cper_post_event(), the code
copies the event record:

    memcpy(&wd.rec, rec, sizeof(wd.rec));

If a hardware device provides a malformed record with a small
error_data_length or an unusually large dvsec_len, could this unconditional
memcpy() read unmapped memory or leak kernel memory contents to userspace
via the kfifo trace events?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260709162807.1957783-1-dave.jiang@intel.com?part=1