CVE-2022-50100 Affecting kernel package, versions *
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-RHEL10-KERNEL-10494433
- published24 Jun 2025
- disclosed1 Jan 2022
Introduced: 1 Jan 2022
CVE-2022-50100 (opens in a new tab)How to fix?
There is no fixed version for RHEL:10 kernel.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel package and not the kernel package as distributed by RHEL.
See How to fix? for RHEL:10 relevant fixed versions and status.
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.
References
- https://bugzilla.redhat.com/show_bug.cgi?id=2373679
- https://access.redhat.com/security/cve/CVE-2022-50100
- https://git.kernel.org/stable/c/302f7b0fc337746f41c69eb08522907f6a90c643
- https://git.kernel.org/stable/c/748d2e9585ae53cb6be48e84f93d2f082ae1d135
- https://git.kernel.org/stable/c/751d4cbc43879229dbc124afefe240b70fd29a85
- https://git.kernel.org/stable/c/fde45283f4c8a91c367ea5f20f87036468755121