CVE-2022-48892

What it actually does

Use-after-free in dup_user_cpus_ptr() allows concurrent sched_setaffinity() from another process to race with fork() and clear user_cpus_ptr under pi_lock, resulting in dangling pointer access and possible double-free.

Why it matters to the business

Kernel memory corruption can cause system crashes, denial of service, or local privilege escalation on Linux-based systems and Android devices using affected Qualcomm WLAN drivers; organizations running unpatched kernels face elevated risk of downtime and full host compromise.

How an attack unfolds

An attacker with local access invokes sched_setaffinity() on a target process while that process concurrently executes fork(); the race between clearing user_cpus_ptr in do_set_cpus_allowed() and the unlocked read in dup_user_cpus_ptr() triggers the use-after-free, enabling memory manipulation that may lead to kernel code execution.

How to fix it

Update the Linux kernel to commit b22faa21b6230d5eccd233e1b7e0026a5002b287 or later; for affected Qualcomm WLAN components apply the SoCVersion dated 2021-10-05 or newer; on stable branches manually replace the dup_user_cpus_ptr() implementation with the corrected version that clears the pointer before copying and protects the source check under pi_lock.

How to confirm the fix worked

Verify the running kernel contains commit b22faa21b6230d5eccd233e1b7e0026a5002b287; inspect source for the updated dup_user_cpus_ptr() that initializes the destination pointer to NULL and acquires pi_lock before reading the source user_cpus_ptr; confirm no crash or memory corruption occurs under concurrent fork and affinity change workloads.

Typical attack path

1. Obtain local user access on the target system
2. Trigger concurrent fork() and sched_setaffinity() calls against the same task
3. Exploit the resulting use-after-free to corrupt kernel memory structures
4. Escalate privileges or execute arbitrary kernel code

How to detect it

Review kernel logs for use-after-free or double-free warnings in the scheduler path; look for unusual concurrent fork and sched_setaffinity activity in process traces; examine crash dumps for corruption involving task_struct user_cpus_ptr.

What your security team should do

• Prioritize kernel upgrades on all exposed Linux and Android systems within the next 30 days
• Restrict untrusted local code execution where possible until patches are applied
• Monitor for kernel oops or panic logs indicating scheduler-related memory errors