* [PATCH v3] RAS/AMD/FMPM: Fix spurious BUG when ERST record enumeration fails
@ 2026-09-25 3:09 Rui Qi
2026-09-25 14:31 ` Yazen Ghannam
0 siblings, 1 reply; 2+ messages in thread
From: Rui Qi @ 2026-09-25 3:09 UTC (permalink / raw)
To: Yazen Ghannam, Borislav Petkov, Tony Luck
Cc: Kees Cook, Guilherme G . Piccoli, muralidhara.mk,
naveenkrishna.chatradhi, linux-edac, linux-kernel, Rui Qi
When erst_get_record_id_begin() returns an error, get_saved_records()
jumps to the out_end label and unconditionally calls
erst_get_record_id_end(). But begin() only bumps the
erst_record_id_cache refcount on success, so calling end() after a
failed begin() underflows it.
This is reachable when fmpm is built as a module: if the cache lock
is contended (by pstore, erst-dbg, or apei_read_mce) and a signal
arrives, mutex_lock_interruptible() in begin() returns -EINTR without
incrementing the refcount. end() then takes the lock, decrements the
refcount below zero, and BUG_ON() fires while still holding it. The
loader dies with the mutex held, so every later ERST user blocks
indefinitely.
Built-in fmpm is not affected, since its initcall runs before
userspace and mutex_lock_interruptible() can never see a signal.
Fix it by jumping to the out label on begin() failure, skipping
erst_get_record_id_end(). kfree(old) moves to that shared label so
it still runs on every path.
Fixes: 6f15e617cc99 ("RAS: Introduce a FRU memory poison manager")
Signed-off-by: Rui Qi <qirui.001@bytedance.com>
---
Changes in v3:
- Reword the commit message per review feedback from Yazen Ghannam.
- No code changes.
Patches 1-3 of the series are unchanged and already carry Reviewed-by
on v2; they are not resent.
Link: https://lore.kernel.org/r/20260924161746.GI1080284@yaz-khff2.amd.com
drivers/ras/amd/fmpm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/ras/amd/fmpm.c b/drivers/ras/amd/fmpm.c
index c13db1f743e5..48a437042953 100644
--- a/drivers/ras/amd/fmpm.c
+++ b/drivers/ras/amd/fmpm.c
@@ -673,7 +673,7 @@ static int get_saved_records(void)
ret = erst_get_record_id_begin(&pos);
if (ret < 0)
- goto out_end;
+ goto out;
while (!erst_get_record_id_next(&pos, &record_id)) {
if (record_id == APEI_ERST_INVALID_RECORD_ID)
@@ -714,8 +714,8 @@ static int get_saved_records(void)
out_end:
erst_get_record_id_end();
- kfree(old);
out:
+ kfree(old);
return ret;
}
--
2.20.1
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [PATCH v3] RAS/AMD/FMPM: Fix spurious BUG when ERST record enumeration fails
2026-09-25 3:09 [PATCH v3] RAS/AMD/FMPM: Fix spurious BUG when ERST record enumeration fails Rui Qi
@ 2026-09-25 14:31 ` Yazen Ghannam
0 siblings, 0 replies; 2+ messages in thread
From: Yazen Ghannam @ 2026-09-25 14:31 UTC (permalink / raw)
To: Rui Qi
Cc: Borislav Petkov, Tony Luck, Kees Cook, Guilherme G . Piccoli,
muralidhara.mk, naveenkrishna.chatradhi, linux-edac,
linux-kernel
On Fri, Sep 25, 2026 at 11:09:18AM +0800, Rui Qi wrote:
> When erst_get_record_id_begin() returns an error, get_saved_records()
> jumps to the out_end label and unconditionally calls
> erst_get_record_id_end(). But begin() only bumps the
> erst_record_id_cache refcount on success, so calling end() after a
> failed begin() underflows it.
>
> This is reachable when fmpm is built as a module: if the cache lock
> is contended (by pstore, erst-dbg, or apei_read_mce) and a signal
> arrives, mutex_lock_interruptible() in begin() returns -EINTR without
> incrementing the refcount. end() then takes the lock, decrements the
> refcount below zero, and BUG_ON() fires while still holding it. The
> loader dies with the mutex held, so every later ERST user blocks
> indefinitely.
>
> Built-in fmpm is not affected, since its initcall runs before
> userspace and mutex_lock_interruptible() can never see a signal.
>
> Fix it by jumping to the out label on begin() failure, skipping
> erst_get_record_id_end(). kfree(old) moves to that shared label so
> it still runs on every path.
>
> Fixes: 6f15e617cc99 ("RAS: Introduce a FRU memory poison manager")
> Signed-off-by: Rui Qi <qirui.001@bytedance.com>
> ---
> Changes in v3:
> - Reword the commit message per review feedback from Yazen Ghannam.
> - No code changes.
>
> Patches 1-3 of the series are unchanged and already carry Reviewed-by
> on v2; they are not resent.
>
> Link: https://lore.kernel.org/r/20260924161746.GI1080284@yaz-khff2.amd.com
>
> drivers/ras/amd/fmpm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/ras/amd/fmpm.c b/drivers/ras/amd/fmpm.c
> index c13db1f743e5..48a437042953 100644
> --- a/drivers/ras/amd/fmpm.c
> +++ b/drivers/ras/amd/fmpm.c
> @@ -673,7 +673,7 @@ static int get_saved_records(void)
>
> ret = erst_get_record_id_begin(&pos);
> if (ret < 0)
> - goto out_end;
> + goto out;
>
> while (!erst_get_record_id_next(&pos, &record_id)) {
> if (record_id == APEI_ERST_INVALID_RECORD_ID)
> @@ -714,8 +714,8 @@ static int get_saved_records(void)
>
> out_end:
> erst_get_record_id_end();
> - kfree(old);
> out:
> + kfree(old);
> return ret;
> }
>
> --
Looks good to me.
Reviewed-by: Yazen Ghannam <yazen.ghannam@amd.com>
Thanks,
Yazen
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2026-09-25 14:31 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-09-25 3:09 [PATCH v3] RAS/AMD/FMPM: Fix spurious BUG when ERST record enumeration fails Rui Qi
2026-09-25 14:31 ` Yazen Ghannam
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®