CVE-2022-48892: sched/core: Fix use-after-free bug in dup_user_cpus_ptr()
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.
Security readout for executives and security teams
Plain-English summary
This is a Linux kernel race condition that can corrupt kernel memory when CPU affinity changes overlap with process fork handling. The source describes use-after-free and possible double-free behavior. No CVSS score, public exploitation evidence, or CISA KEV listing is provided in the bundle.
Executive priority
Treat as a kernel maintenance priority, not an emergency from the supplied evidence. Patch through normal accelerated Linux update processes, with higher priority for shared infrastructure and custom kernels.
Technical view
dup_user_cpus_ptr() read user_cpus_ptr without lock protection while sched_setaffinity() or do_set_cpus_allowed() could clear it. The fix clears the cloned task pointer before copying and checks the source task state under pi_lock. The CVE data identifies Linux kernel 5.15, 5.15.89, 6.1.7, and 6.2 entries as affected.
Likely exposure
Exposure is most relevant to Linux systems running affected kernel lines, especially multi-user, container, or workload-dense hosts where local processes can change CPU affinity while processes fork. Distribution backports may alter exposure, so package-level vendor status matters more than upstream version strings alone.
Exploitation context
The source bundle does not show active exploitation, exploit availability, or a KEV listing. The described condition requires a race involving CPU affinity changes and fork behavior. Impact is kernel memory safety corruption, but the bundle does not prove privilege escalation or remote reachability.
Researcher notes
The version data in the bundle is incomplete and oddly shaped, including commit hashes and discrete versions. Do not infer broader affected ranges without vendor or kernel stable evidence. The patch note says stable releases may need the new dup_user_cpus_ptr() function copied over.
Mitigation direction
Apply distribution kernel updates that include the referenced upstream stable fixes.
Check vendor advisories for exact affected package versions and backport status.
Prioritize shared Linux hosts, container platforms, and systems allowing untrusted local users.
Track kernel.org stable references if maintaining custom kernels.
Validation and detection
Inventory running kernel versions across Linux fleets.
Compare kernel packages against vendor CVE guidance for CVE-2022-48892.
For custom kernels, verify the dup_user_cpus_ptr() fix is present.
Confirm CISA KEV remains negative before claiming active exploitation.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2022-48892 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.