CVE-2022-50100
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-06-18

Last updated on: 2025-11-19

Assigner: kernel.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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-06-18
Last Modified
2025-11-19
Generated
2026-05-07
AI Q&A
2025-06-18
EPSS Evaluated
2026-05-05
NVD
CVE-2022-50100
Affected Vendors & Products
Showing 3 associated CPEs
Vendor Product Version / Range
linux linux_kernel From 5.15.160 (inc) to 5.16 (inc)
linux linux_kernel From 5.15.160 (inc) to 5.16 (inc)
linux linux_kernel From 5.15.160 (inc) to 5.16 (inc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-NVD-CWE-noinfo
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability in the Linux kernel involves a scheduling issue where a task is requeued on a CPU that it is not allowed to run on. Specifically, an optimization in the scheduler's ttwu() function queues a task that is descheduling on the wakelist without verifying if the task can still run on that CPU. This can cause warnings and improper task handling, especially on large machines during early boot or under certain conditions involving workqueue rescue threads and parallel wakeups from other CPUs.


How can this vulnerability impact me? :

The vulnerability can lead to warnings and potential instability in the Linux kernel's task scheduling, particularly on large machines. Tasks may be incorrectly queued on CPUs they are not allowed to run on, which could cause performance issues or unexpected behavior during system boot or under heavy load involving workqueue rescue threads.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability manifests as a kernel warning related to CPU task requeueing, specifically a warning message like: "WARNING: CPU: <cpu_id> PID: <pid> at ../kernel/workqueue.c:2231 process_one_work+0x4d/0x440" during early boot or under load on large machines. Detection involves monitoring kernel logs (e.g., using 'dmesg' or 'journalctl -k') for such warnings. Example commands: 'dmesg | grep "WARNING: CPU"' or 'journalctl -k | grep "process_one_work"'.


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation involves updating the Linux kernel to a version that includes the fix for this issue, which ensures that tasks are not requeued on CPUs excluded from their allowed CPU mask. Until an update is applied, monitoring for the warning messages and avoiding workloads that trigger frequent rescue thread usage on large machines may reduce exposure.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart