systemd-oomd: unprivileged local users can kill arbitrary processes via unvalidated IPC path

CVE-2026-15059Kernel, userspace & hypervisorcurated

Impact

systemd-oomd exposes an IPC method that accepts a cgroup path without validating that the caller owns it, so any unprivileged local account can direct the OOM killer at processes outside its own slice. On a shared GPU node that means one tenant with a host shell can terminate another tenant's training job, the container runtime, or node agents such as kubelet or the DCGM exporter. Killing a multi-day training run is expensive in GPU-hours and leaves no obvious attacker trace; killing node agents can leave a node that still looks healthy to the scheduler but no longer runs work. Confidentiality and integrity are untouched - this is purely an availability bug, but on a fleet where oomd is enabled by default it applies to every node at once.

Who can reach it

A local unprivileged user on the host who can reach the systemd-oomd IPC interface. No elevated privileges and no user interaction are needed. A container reaches this only if the host D-Bus socket is deliberately exposed into it, which is not the case for a default GPU pod.

What to do

Update the distribution's systemd package and restart systemd-oomd; the daemon is separate from PID 1, so systemctl restart systemd-oomd applies the fix without draining or rebooting the node. Hosts that do not rely on userspace OOM management can mask systemd-oomd.service as a mitigation. The record carries the systemd GHSA but no fixed version - track your distro's systemd advisory for the exact build.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-15059 https://github.com/systemd/systemd/security/advisories/GHSA-652q-wxr6-h5j6

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.