CVE-2022-48950

What it actually does

Use-after-free in perf_pending_task() where the perf event can be freed while task_work is still queued or queued during destruction, allowing access to freed memory in two distinct scenarios involving task_work and event state transitions.

Why it matters to the business

Potential kernel instability or arbitrary code execution in performance monitoring paths could lead to system crashes, data corruption, or privilege escalation on affected Linux systems; low exploit likelihood reduces immediate urgency but requires patching in perf-dependent environments.

How an attack unfolds

An attacker triggers conditions where perf_release queues or leaves perf_pending_task() active after the event object is freed, either by racing destruction with queued work or by marking the event dead while still scheduling task_work; this leads to use of dangling pointers in the kernel's task_work handling.

How to fix it

Update to a kernel containing the fix that extends perf_event lifetime across task_work and reorders STATE_DEAD/STATE_OFF transitions to avoid queuing work on dying events; apply the referenced LibreNMS commit d3b51560a8e2343e520d16e9adc72c6951aa91ee if the environment uses the listed package.

How to confirm the fix worked

Confirm the kernel source includes the lifetime extension for perf_event around task_work and the reordering of event state flags; test that perf event destruction no longer leaves pending task_work entries; verify package version matches the fixed commit hash.

Typical attack path

1. Identify or create a perf event that will trigger task_work
2. Arrange for perf_release or event destruction to occur while task_work remains pending
3. Trigger the race or state transition that queues or retains the pending task after free
4. perf_pending_task executes on the freed event object

How to detect it

Search kernel logs for use-after-free warnings or oops involving perf_pending_task or perf_event; look for crashes during perf event teardown or task_work processing; examine audit or syscall logs for unusual perf_event_open sequences followed by rapid event destruction.

What your security team should do

• Prioritize patching systems with heavy perf or monitoring workloads
• Monitor for any public exploit code given the 726-day publication window
• Apply the exact fixed commit in LibreNMS deployments if applicable
• Review perf-related code paths in custom kernels for similar lifetime issues