CVE-2022-48950

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() wont 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.

Weakness

The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory “belongs” to the code that operates on the new pointer.

Affected Software

Potential Mitigations

References

• https://git.kernel.org/stable/c/517e6a301f34613bff24a8e35b5455884f2d83d8
• https://git.kernel.org/stable/c/78e1317a174edbfd1182599bf76c092a2877672c
• https://git.kernel.org/stable/c/8bffa95ac19ff27c8261904f89d36c7fcf215d59