CVE-2026-15059

A flaw was found in systemd-oomd. Local unprivileged users can exploit a missing path traversal validation in the systemd-oomd Inter-Process Communication (IPC) Application Programming Interface (API). This vulnerability allows them to terminate arbitrary local processes, leading to a denial of service.

systemd-oomd is vulnerable to a path traversal in its Varlink ManagedOOM IPC handler: an unprivileged local user can supply a crafted cgroup path containing ../ sequences that, after path_simplify(), escapes the /sys/fs/cgroup hierarchy, allowing the daemon to act on — and terminate the processes of — an arbitrary cgroup the caller does not own (CWE-22).

Red Hat rates this Moderate (CVSS 5.5, AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H), consistent with the upstream advisory (GHSA-652q-wxr6-h5j6). Exploitation is bounded by significant runtime preconditions: it requires a local unprivileged account, the systemd-oomd service must be actively running (it is not enabled by default on Red Hat Enterprise Linux server installations), the attacker must reach the ManagedOOM Varlink socket, and must know the target PID/cgroup. Impact is limited to availability (process termination); there is no confidentiality or integrity impact.

Affected Red Hat products ship systemd >= 250 (RHEL 9 / 10, RHIVOS). Releases shipping systemd < 250 (RHEL 7 with systemd 219, RHEL 8 with systemd 239) are not affected — the vulnerable oomd cgroup-path handling was introduced in systemd 250 and the code is not present in those versions.

The CVSS score(s) listed for this vulnerability do not reflect the associated product's status, and are included for informational purposes to better understand the severity of this vulnerability.

On systems that do not require memory-pressure-based OOM management, disable the systemd-oomd service to remove the attack surface entirely:

systemctl disable --now systemd-oomd.service

Where systemd-oomd must remain enabled, restrict local access to untrusted users. Note that on Red Hat Enterprise Linux server profiles systemd-oomd is not enabled by default, so default server installations are not exposed until the service is explicitly started.