CVE-2022-48950

/// Technical description

In the Linux kernel, the following vulnerability has been resolved:

perf: Fix perf_pending_task() UaF

Per syzbot it is possible for perf_pending_task() to run after the

event is free()'d. There are two related but distinct cases:

- the task_work was already queued before destroying the event;

- destroying the event itself queues the task_work.

The first cannot be solved using task_work_cancel() since

perf_release() itself might be called from a task_work (____fput),

which means the current->task_works list is already empty and

task_work_cancel() won't be able to find the perf_pending_task()

entry.

The simplest alternative is extending the perf_event lifetime to cover

the task_work.

The second is just silly, queueing a task_work while you know the

event is going away makes no sense and is easily avoided by

re-arranging how the event is marked STATE_DEAD and ensuring it goes

through STATE_OFF on the way down.

/// Remediation

Check the references section for vendor advisories, patches, and mitigation guidance. If immediate patching is not possible, review the CVSS vector to understand the attack surface and apply compensating controls such as network segmentation or access restrictions.

/// References