In the Linux kernel, the following vulnerability has been resolved: PM: sleep: Fix possible deadlocks in core system-wide PM code The Linux kernel CVE team has assigned CVE-2023-52498 to this issue. Upstream advisory: https://lore.kernel.org/linux-cve-announce/20240229155245.1571576-39-lee@kernel.org/T/#u
Created kernel tracking bugs for this issue: Affects: fedora-all [bug 2269064]
This was fixed for Fedora with the 6.7.3 stable kernel updates.
Hi Alex, It seems to me, based on the commit message that this should be marked as Minor Impact. It's a resume issue which could result in a deadlock in a low memory situation (see below): commit 7839d0078e0d5e6cc2fa0b0dfbee71de74f1e557 Author: Rafael J. Wysocki <rafael.j.wysocki> Date: Wed Dec 27 21:41:06 2023 +0100 PM: sleep: Fix possible deadlocks in core system-wide PM code It is reported that in low-memory situations the system-wide resume core code deadlocks, because async_schedule_dev() executes its argument function synchronously if it cannot allocate memory (and not only in that case) and that function attempts to acquire a mutex that is already held. Executing the argument function synchronously from within dpm_async_fn() may also be problematic for ordering reasons (it may cause a consumer device's resume callback to be invoked before a requisite supplier device's one, for example). Address this by changing the code in question to use async_schedule_dev_nocall() for scheduling the asynchronous execution of device suspend and resume functions and to directly run them synchronously if async_schedule_dev_nocall() returns false. Link: https://lore.kernel.org/linux-pm/ZYvjiqX6EsL15moe@perf/ Reported-by: Youngmin Nam <youngmin.nam> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki> Reviewed-by: Stanislaw Gruszka <stanislaw.gruszka.com> Tested-by: Youngmin Nam <youngmin.nam> Reviewed-by: Ulf Hansson <ulf.hansson> Cc: 5.7+ <stable.org> # 5.7+: 6aa09a5bccd8 async: Split async_schedule_node_domain() Cc: 5.7+ <stable.org> # 5.7+: 7d4b5d7a37bd async: Introduce async_schedule_dev_nocall() Cc: 5.7+ <stable.org> # 5.7+
In reply to comment #15: > Hi Alex, > > It seems to me, based on the commit message that this should be marked as > Minor Impact. It's a resume issue which could result in a deadlock in a low > memory situation (see below): > > commit 7839d0078e0d5e6cc2fa0b0dfbee71de74f1e557 > Author: Rafael J. Wysocki <rafael.j.wysocki> > Date: Wed Dec 27 21:41:06 2023 +0100 > > PM: sleep: Fix possible deadlocks in core system-wide PM code > > It is reported that in low-memory situations the system-wide resume core > code deadlocks, because async_schedule_dev() executes its argument > function synchronously if it cannot allocate memory (and not only in > that case) and that function attempts to acquire a mutex that is already > held. Executing the argument function synchronously from within > dpm_async_fn() may also be problematic for ordering reasons (it may > cause a consumer device's resume callback to be invoked before a > requisite supplier device's one, for example). > > Address this by changing the code in question to use > async_schedule_dev_nocall() for scheduling the asynchronous > execution of device suspend and resume functions and to directly > run them synchronously if async_schedule_dev_nocall() returns false. > > Link: https://lore.kernel.org/linux-pm/ZYvjiqX6EsL15moe@perf/ > Reported-by: Youngmin Nam <youngmin.nam> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki> > Reviewed-by: Stanislaw Gruszka <stanislaw.gruszka.com> > Tested-by: Youngmin Nam <youngmin.nam> > Reviewed-by: Ulf Hansson <ulf.hansson> > Cc: 5.7+ <stable.org> # 5.7+: 6aa09a5bccd8 async: Split > async_schedule_node_domain() > Cc: 5.7+ <stable.org> # 5.7+: 7d4b5d7a37bd async: Introduce > async_schedule_dev_nocall() > Cc: 5.7+ <stable.org> # 5.7+ Agree. Decreased to Low. Thank you for notification about this. It was selected as Moderate before by default (with fast prior check) based on "LOCK DEADLOCK" info and missed info about low-memory situation.
This issue has been addressed in the following products: Red Hat Enterprise Linux 9 Via RHSA-2024:9315 https://access.redhat.com/errata/RHSA-2024:9315