CMT: [SRU][F][PATCH v2 0/5] CVE-2023-52498

[Ian Whitfield]

On Thu, 17 Oct 2024 at 20:15, Guoqing Jiang <guoqing.jiang at canonical.com> wrote:
>
>
>
> On 10/17/24 14:57, Guoqing Jiang wrote:
> > Acked-by: Guoqing Jiang <guoqing.jiang at canonical.com>
> >
> > On 10/16/24 07:30, Ian Whitfield wrote:
> >> [Impact]
> >>
> >> This patchset resolves multiple deadlock conditions in
> >> drivers/base/power/main.c
> >>
> >> The primary CVE fix addresses a deadlock that happened on system resume
> >> on low-memory hardware configurations. The second deadlock fixed by
> >> this patchset occurs when a device handling a resume or suspend
> >> attempts to unlock a particular mutex while the base calling code has
> >> not yet dropped it.
> >>
> >> [Backport]
> >>
> >> The top-level fix patch for this CVE had two dependency patches and
> >> conflicts due to missing two other patches. Dependency patches were
> >> applied cleanly. Of the two conflict patches, one was not relevant and
> >> easily resolved with context adjustment. The other conflicting patch
> >> resolved further deadlock conditions which led me to include it in this
> >> patchset. This secondary patch had one conflict, but this was resolved
> >> by adjusting the patch context.
> >>
> >> This patchset therefore includes a fix for the original deadlock CVE,
> >> its two dependency patches, and a second deadlock patch.
> >>
> >> [Fix]
> >>
> >> Noble:  not affected
> >> Jammy:  fixed via stable updates
> >> Focal:  backport
> >> Bionic: not affected
> >> Xenial: not affected
> >> Trusty: not affected
> >>
> >> [Test Case]
> >>
> >> Compile and boot tested
>
> After a second thought, I would suggest to run PM test against real
> hardware to avoid potential
> issue.
>
> Thanks,
> Guoqing
>
> >>
> >> [Where problems could occur]
> >>
> >> This fix affects the majority of users, because it addresses a bug in
> >> the base driver code for managing power. An issue with this fix would
> >> be visible to the user as a system freeze due to deadlock, or possibly
> >> a logged warning of a circular locking dependency.
> >>
> >> v2: This version includes a fix patch for a bug introduced in
> >>      2aa36604e824. This is the 2nd patch in the numbered series and adds
> >>      a missing error check.
> >>
> >> Rafael J. Wysocki (5):
> >>    PM: sleep: Avoid calling put_device() under dpm_list_mtx
> >>    PM: sleep: Fix error handling in dpm_prepare()
> >>    async: Split async_schedule_node_domain()
> >>    async: Introduce async_schedule_dev_nocall()
> >>    PM: sleep: Fix possible deadlocks in core system-wide PM code
> >>
> >>   drivers/base/power/main.c | 229 ++++++++++++++++++++------------------
> >>   include/linux/async.h     |   2 +
> >>   kernel/async.c            |  85 ++++++++++----
> >>   3 files changed, 188 insertions(+), 128 deletions(-)
> >>
> >
>

I've just run a PM test on an AWS EC2 m5.metal instance with the
following commands:
$ echo core > /sys/power/pm_test
$ echo reboot > /sys/power/disk
$ echo disk > /sys/power/state

It appears to have succeeded: after a pause of about 5 seconds, the
system returned to normal responsiveness, dmesg shows logs of a
successful hibernation. Is this sufficient testing or is there more to
do?

-Ian