CVE-2023-54019

What it actually does

Use-after-free in PSI trigger polling: cgroup removal via cgroup_file_release calls psi_trigger_destroy which frees the event_wait waitqueue while a concurrent vfs_poll/do_select from a polling process still holds a reference, causing UAF on poll_freewait after wake_up_pollfree and synchronize_rcu.

Why it matters to the business

Linux systems using cgroups for container or workload isolation face kernel crashes or memory corruption; patching requires kernel upgrades that may cause reboots and brief service disruption across fleets with high cgroup usage.

How an attack unfolds

An attacker with local cgroup write access (common in container runtimes) sets up a PSI trigger poll, then removes the cgroup; the race between cgroup_rmdir/kernfs_drain_open_files and the poll path triggers the UAF on the freed waitqueue head.

How to fix it

Upgrade affected kernels to commit 92cc0153324b6ae8577a39f5bf2cd83c9a34ea6a or later; for packaged distributions use neuvector-sigstore-interface 0_git20250606-r0 or newer. Revert any local backports of the earlier epoll-only fix.

How to confirm the fix worked

Confirm kernel contains 92cc0153324b6ae8577a39f5bf2cd83c9a34ea6a; exercise cgroup creation, PSI trigger polling, and concurrent rmdir while monitoring for UAF warnings or panics in dmesg.

Typical attack path

1. Obtain local access allowing cgroup creation and removal
2. Open a PSI pressure trigger file and begin synchronous poll
3. Trigger cgroup removal (rmdir or equivalent) under the polling file
4. Race the poll path against psi_trigger_destroy to hit freed waitqueue

How to detect it

Search kernel logs for oops/panic traces mentioning psi_trigger_destroy, wake_up_pollfree, cgroup_pressure_release, or poll_freewait; inspect audit logs for rapid cgroup creation/removal sequences around crash times.

• psi_trigger_destroy
• cgroup_pressure_release
• wake_up_pollfree

What your security team should do

• Prioritize kernel updates on all systems exposing cgroups to untrusted workloads
• Apply updates before the next scheduled maintenance window given 309 days since disclosure
• Audit container runtime configurations that allow unprivileged cgroup removal