Re: [PATCH v5 03/10] ACPI: APEI: GHES: move GHESv2 ack and alloc helpers

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] The EDAC driver (`ghes_edac.c`) iterates over the global `ghes_devs` list without holding `ghes_devs_mutex`, allowing concurrent modifications by `ghes_probe` or `ghes_remove` to trigger a use-after-free or list corruption.
--

commit ad8109c2f93ccdccb9336458af1f3ae8d0777528
Author: Ahmed Tiba <ahmed.tiba@arm.com>

ACPI: APEI: GHES: move GHESv2 ack and alloc helpers

Move the GHESv2 acknowledgment and error-source allocation helpers from
ghes.c into ghes_cper.c. This is a mechanical refactor that keeps the
logic unchanged while making the helpers reusable.

> diff --git a/drivers/acpi/apei/ghes_cper.c b/drivers/acpi/apei/ghes_cper.c
> index 7bb72fe578384..8080e0f76dac4 100644
> --- a/drivers/acpi/apei/ghes_cper.c
> +++ b/drivers/acpi/apei/ghes_cper.c

[ ... ]

> +void ghes_fini(struct ghes *ghes)
> +{
> +	kfree(ghes->estatus);
> +	apei_unmap_generic_address(&ghes->generic->error_status_address);
> +	if (is_hest_type_generic_v2(ghes))
> +		unmap_gen_v2(ghes);
> +}

[Severity: High]
This is a pre-existing issue, but since we are refactoring the GHES allocation
and cleanup helpers here, I wanted to ask about the synchronization around the
global ghes_devs list when a device is removed and freed.

The EDAC driver (ghes_edac.c) iterates over the global ghes_devs list without
holding ghes_devs_mutex. The function ghes_get_devices() returns a pointer to
this list without acquiring the mutex or exporting it, and ghes_edac_init() and
ghes_edac_exit() iterate over it using list_for_each_entry_safe() without
locking.

If a user concurrently unbinds a GHES device via sysfs or hot-adds one while
the ghes_edac module is loading or unloading, ghes_remove() will acquire the
mutex, remove the device from ghes_devs, and eventually trigger the free path.

Since list_for_each_entry_safe() does not protect against concurrent list
modifications by other threads, could this lead to a race condition resulting
in list corruption or a use-after-free when the GHES object is destroyed?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260529-topics-ahmtib01-ras_ffh_arm_internal_review-v5-0-2e0500d42642@arm.com?part=3