Linux kernel PSI: use-after-free racing a cgroup pressure write against cgroup removal

Impact

Writing a cgroup's memory.pressure/cpu.pressure trigger while the same cgroup is being removed can free the kernfs open-file private context and then dereference it. NVD rates the outcome 7.8 local with full confidentiality, integrity and availability loss, i.e. a kernel memory-corruption primitive that lands in the hands of whoever can write that file. On a GPU node this matters because cgroup delegation is normal - container runtimes and systemd user slices hand tenants writable subtrees, and PSI trigger files are part of what they get. A successful escalation is a container-to-host escape on a box that is also holding other tenants' GPUs.

Who can reach it

Local user with write access to a PSI pressure file in a cgroup that can be removed concurrently - typically a delegated cgroup subtree inside a container or user slice. No remote path, no extra capability beyond that file handle.

What to do

Take the stable kernel fix and reboot each node; there is no runtime knob that closes the race. Red Hat has shipped errata RHSA-2026:57251 and RHSA-2026:57252 for RHEL. Plan it as a rolling drain-and-reboot across the fleet - on GPU nodes this means draining long-running training jobs, so batch it with your next kernel window rather than a one-off.

References