CVE-2022-48950
published 2024-10-21CVE-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…
PriorityP337high7.8CVSS 3.1
AVLACLPRLUINSUCHIHAH
EPSS
0.25%
16.7th percentile
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.
Affected
12 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.1.4-1 (bookworm) | linux 6.1.4-1 (bookworm) |
| linux | linux | >= 078c12ccf1fb943cc18c84894c76113dc89e5975 < 78e1317a174edbfd1182599bf76c092a2877672c | 78e1317a174edbfd1182599bf76c092a2877672c |
| linux | linux | >= 5.15.77 < 5.15.84 | 5.15.84 |
| linux | linux | >= 6.0.7 < 6.0.14 | 6.0.14 |
| linux | linux | >= ca6c21327c6af02b7eec31ce4b9a740a18c6c13f < 517e6a301f34613bff24a8e35b5455884f2d83d8 | 517e6a301f34613bff24a8e35b5455884f2d83d8 |
| linux | linux | >= ca7b0a10287e2733bdafb01ef0d4038536625fe3 < 8bffa95ac19ff27c8261904f89d36c7fcf215d59 | 8bffa95ac19ff27c8261904f89d36c7fcf215d59 |
| linux | linux_kernel | < 5.15.84 | 5.15.84 |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 6.1.4-1 | 6.1.4-1 |
| linux | linux_kernel | >= 0 < 6.1.4-1 | 6.1.4-1 |
| linux | linux_kernel | >= 0 < 6.1.4-1 | 6.1.4-1 |
| linux | linux_kernel | >= 5.16 < 6.0.14 | 6.0.14 |
CVSS provenance
nvdv3.17.8HIGHCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
osv7.8HIGH
vendor_debian7.8HIGH
vendor_redhat7.8HIGH
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
GHSA
GHSA-qw38-ppmm-fjpw: In the Linux kernel, the following vulnerability has been resolved:
perf: Fix perf_pending_task() UaF
Per syzbot it is possible for perf_pending_tas
ghsa_unreviewed·2024-10-21
CVE-2022-48950 [HIGH] CWE-416 GHSA-qw38-ppmm-fjpw: In the Linux kernel, the following vulnerability has been resolved:
perf: Fix perf_pending_task() UaF
Per syzbot it is possible for perf_pending_tas
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 an
OSV
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(
osv·2024-10-21·CVSS 7.8
CVE-2022-48950 [HIGH] 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(
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 e
Red Hat
kernel: perf: Fix perf_pending_task() UaF
vendor_redhat·2024-10-21·CVSS 7.8
CVE-2022-48950 [HIGH] CWE-416 kernel: perf: Fix perf_pending_task() UaF
kernel: perf: Fix perf_pending_task() UaF
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
Debian
CVE-2022-48950: linux - In the Linux kernel, the following vulnerability has been resolved: perf: Fix p...
vendor_debian·2022·CVSS 7.8
CVE-2022-48950 [HIGH] CVE-2022-48950: linux - In the Linux kernel, the following vulnerability has been resolved: perf: Fix p...
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 e
No detection rules found.
No public exploits indexed.
No writeups or analysis indexed.
2024-10-21
Published