[<prev] [next>] [day] [month] [year] [list]
Message-ID: <2025061803-CVE-2022-50100-bcf0@gregkh>
Date: Wed, 18 Jun 2025 13:02:45 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...nel.org>
Subject: CVE-2022-50100: sched/core: Do not requeue task on CPU excluded from cpus_mask
From: Greg Kroah-Hartman <gregkh@...nel.org>
Description
===========
In the Linux kernel, the following vulnerability has been resolved:
sched/core: Do not requeue task on CPU excluded from cpus_mask
The following warning was triggered on a large machine early in boot on
a distribution kernel but the same problem should also affect mainline.
WARNING: CPU: 439 PID: 10 at ../kernel/workqueue.c:2231 process_one_work+0x4d/0x440
Call Trace:
<TASK>
rescuer_thread+0x1f6/0x360
kthread+0x156/0x180
ret_from_fork+0x22/0x30
</TASK>
Commit c6e7bd7afaeb ("sched/core: Optimize ttwu() spinning on p->on_cpu")
optimises ttwu by queueing a task that is descheduling on the wakelist,
but does not check if the task descheduling is still allowed to run on that CPU.
In this warning, the problematic task is a workqueue rescue thread which
checks if the rescue is for a per-cpu workqueue and running on the wrong CPU.
While this is early in boot and it should be possible to create workers,
the rescue thread may still used if the MAYDAY_INITIAL_TIMEOUT is reached
or MAYDAY_INTERVAL and on a sufficiently large machine, the rescue
thread is being used frequently.
Tracing confirmed that the task should have migrated properly using the
stopper thread to handle the migration. However, a parallel wakeup from udev
running on another CPU that does not share CPU cache observes p->on_cpu and
uses task_cpu(p), queues the task on the old CPU and triggers the warning.
Check that the wakee task that is descheduling is still allowed to run
on its current CPU and if not, wait for the descheduling to complete
and select an allowed CPU.
The Linux kernel CVE team has assigned CVE-2022-50100 to this issue.
Affected and fixed versions
===========================
Issue introduced in 5.8 with commit c6e7bd7afaeb3af55ffac122828035f1c01d1d7b and fixed in 5.15.61 with commit 748d2e9585ae53cb6be48e84f93d2f082ae1d135
Issue introduced in 5.8 with commit c6e7bd7afaeb3af55ffac122828035f1c01d1d7b and fixed in 5.18.18 with commit fde45283f4c8a91c367ea5f20f87036468755121
Issue introduced in 5.8 with commit c6e7bd7afaeb3af55ffac122828035f1c01d1d7b and fixed in 5.19.2 with commit 302f7b0fc337746f41c69eb08522907f6a90c643
Issue introduced in 5.8 with commit c6e7bd7afaeb3af55ffac122828035f1c01d1d7b and fixed in 6.0 with commit 751d4cbc43879229dbc124afefe240b70fd29a85
Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.
Unaffected versions might change over time as fixes are backported to
older supported kernel versions. The official CVE entry at
https://cve.org/CVERecord/?id=CVE-2022-50100
will be updated if fixes are backported, please check that for the most
up to date information about this issue.
Affected files
==============
The file(s) affected by this issue are:
kernel/sched/core.c
Mitigation
==========
The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes. Individual
changes are never tested alone, but rather are part of a larger kernel
release. Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all. If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
https://git.kernel.org/stable/c/748d2e9585ae53cb6be48e84f93d2f082ae1d135
https://git.kernel.org/stable/c/fde45283f4c8a91c367ea5f20f87036468755121
https://git.kernel.org/stable/c/302f7b0fc337746f41c69eb08522907f6a90c643
https://git.kernel.org/stable/c/751d4cbc43879229dbc124afefe240b70fd29a85
Powered by blists - more mailing lists