CVEvulnerability
CVE-2022-48921
4.7 MEDIUM
Official page ↗
- Status
- Analyzed
- Published
- 2024-08-22
- Last modified
- 2026-06-17
- Assigner
- 416baaa9-dc9f-4396-8d5f-8c081fb06d67
- CVSS 3.1 ([email protected])
- 4.7 MEDIUM — CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
- Weaknesses
- CWE-362
Description
In the Linux kernel, the following vulnerability has been resolved:
sched/fair: Fix fault in reweight_entity
Syzbot found a GPF in reweight_entity. This has been bisected to
commit 4ef0c5c6b5ba ("kernel/sched: Fix sched_fork() access an invalid
sched_task_group")
There is a race between sched_post_fork() and setpriority(PRIO_PGRP)
within a thread group that causes a null-ptr-deref in
reweight_entity() in CFS. The scenario is that the main process spawns
number of new threads, which then call setpriority(PRIO_PGRP, 0, -20),
wait, and exit. For each of the new threads the copy_process() gets
invoked, which adds the new task_struct and calls sched_post_fork()
for it.
In the above scenario there is a possibility that
setpriority(PRIO_PGRP) and set_one_prio() will be called for a thread
in the group that is just being created by copy_process(), and for
which the sched_post_fork() has not been executed yet. This will
trigger a null pointer dereference in reweight_entity(), as it will
try to access the run queue pointer, which hasn't been set.
Before the mentioned change the cfs_rq pointer for the task has been
set in sched_fork(), which is called much earlier in copy_process(),
before the new task is added to the thread_group. Now it is done in
the sched_post_fork(), which is called after that. To fix the issue
the remove the update_load param from the update_load param() function
and call reweight_task() only if the task flag doesn't have the
TASK_NEW flag set.
Affected configurations
• linux linux kernel (>= 5.10.80 < 5.10.137)
• linux linux kernel (>= 5.14.19 < 5.15)
• linux linux kernel (>= 5.15.3 < 5.15.27)
• linux linux kernel (>= 5.16 < 5.16.13)
• linux linux kernel 5.17
Related
Weakness · CWE (1)
- CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization weakness
References
- https://git.kernel.org/stable/c/13765de8148f71fa795e0a6607de37c49ea5915a Patch
- https://git.kernel.org/stable/c/589a954daab5e18399860b6c8ffaeaf79844eb20 Patch
- https://git.kernel.org/stable/c/8f317cd888059c59e2fa924bf4b0957cfa53f78e Patch
- https://git.kernel.org/stable/c/e0bcd6b5779352aed88f2e538a82a39f1a7715bb Patch