CVE-2022-48892 in Linux
Summary
by MITRE • 08/21/2024
In the Linux kernel, the following vulnerability has been resolved:
sched/core: Fix use-after-free bug in dup_user_cpus_ptr()
Since commit 07ec77a1d4e8 ("sched: Allow task CPU affinity to be restricted on asymmetric systems"), the setting and clearing of user_cpus_ptr are done under pi_lock for arm64 architecture. However, dup_user_cpus_ptr() accesses user_cpus_ptr without any lock protection. Since sched_setaffinity() can be invoked from another process, the process being modified may be undergoing fork() at the same time. When racing with the clearing of user_cpus_ptr in __set_cpus_allowed_ptr_locked(), it can lead to user-after-free and possibly double-free in arm64 kernel.
Commit 8f9ea86fdf99 ("sched: Always preserve the user requested cpumask") fixes this problem as user_cpus_ptr, once set, will never be cleared in a task's lifetime. However, this bug was re-introduced in commit 851a723e45d1 ("sched: Always clear user_cpus_ptr in do_set_cpus_allowed()") which allows the clearing of user_cpus_ptr in do_set_cpus_allowed(). This time, it will affect all arches.
Fix this bug by always clearing the user_cpus_ptr of the newly cloned/forked task before the copying process starts and check the user_cpus_ptr state of the source task under pi_lock.
Note to stable, this patch won't be applicable to stable releases. Just copy the new dup_user_cpus_ptr() function over.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 02/17/2026
The vulnerability described in CVE-2022-48892 represents a critical use-after-free condition within the Linux kernel's scheduling subsystem, specifically affecting the dup_user_cpus_ptr() function. This flaw manifests in the arm64 architecture but has broader implications due to its potential to affect all architectures following the problematic commit. The vulnerability stems from improper synchronization mechanisms during task CPU affinity management, creating a race condition that can lead to memory corruption and system instability.
The technical root cause involves a mismatch in locking semantics between different kernel functions handling CPU affinity settings. While the sched_setaffinity() function properly acquires the pi_lock for arm64 architecture when setting and clearing user_cpus_ptr, the dup_user_cpus_ptr() function accesses this pointer without any protective locking mechanism. This discrepancy creates a window where concurrent operations can corrupt memory references, particularly when a process undergoing fork() simultaneously interacts with sched_setaffinity() calls. The race condition occurs between the clearing of user_cpus_ptr in __set_cpus_allowed_ptr_locked() and the access pattern in dup_user_cpus_ptr(), potentially resulting in use-after-free scenarios that could escalate to double-free conditions.
The operational impact of this vulnerability extends beyond simple memory corruption, potentially enabling privilege escalation and system compromise. Attackers could exploit this condition to execute arbitrary code within kernel space, leveraging the corrupted memory references to manipulate kernel data structures. The vulnerability affects the core scheduling functionality, making it particularly dangerous as it can disrupt normal system operations and potentially provide attackers with persistent access to system resources. The flaw's presence in the kernel's task management subsystem means that any process manipulation could trigger the race condition, making it difficult to predict and prevent.
The fix implemented addresses the synchronization gap by ensuring that user_cpus_ptr is cleared from newly cloned or forked tasks before the copying process begins, while also verifying the source task's user_cpus_ptr state under the appropriate pi_lock protection. This approach aligns with established security practices for concurrent access control and memory safety. The solution specifically targets the architectural vulnerability introduced by commit 851a723e45d1, which inadvertently reintroduced the problematic clearing behavior across all architectures. The patch demonstrates the importance of maintaining consistent locking patterns throughout kernel subsystems and highlights the risks of seemingly minor architectural changes that can have cascading security implications.
This vulnerability type maps directly to CWE-416, which addresses use-after-free conditions in software systems. The issue also relates to the ATT&CK technique T1068, which involves exploiting local privileges to gain system access through kernel vulnerabilities. The complexity of this flaw underscores the challenges in maintaining memory safety in complex kernel subsystems where multiple concurrent operations must be carefully synchronized to prevent race conditions. The fix's recommendation for stable releases to simply copy the new function rather than apply the full patch demonstrates the practical considerations in kernel security maintenance, where minimal, targeted fixes are often preferred for production stability while maintaining security integrity.