systemd-homed: local homed-managed user can gain membership in arbitrary system groups

CVE-2026-16742Kernel, userspace & hypervisorcurated

Impact

A local, logged-in user whose account is managed by systemd-homed can have arbitrary system groups added to their record, which is a privilege escalation path on any host where group membership is the access control. Group membership is exactly what gates the interesting device nodes and sockets on a GPU host - render and video for /dev/dri and /dev/kfd, disk, and the container runtime socket - so an unprivileged tenant account can convert this into control of the node. CVSS rates confidentiality, integrity and availability all high, tempered by high attack complexity and required user interaction. The practical exposure is narrow: most server images do not enable systemd-homed, and a fleet whose accounts come from /etc/passwd, LDAP or SSSD is not affected at all - check whether homed manages any accounts before scheduling work.

Who can reach it

A local user with an existing low-privileged, homed-managed account and an active login session on the host. Authentication as that user is required, plus some user interaction per the CVSS vector (AV:L/AC:H/PR:L/UI:R).

What to do

Update the distribution's systemd package and restart systemd-homed. On hosts that do not use homed-managed accounts - the normal case for datacenter images - disabling or masking systemd-homed.service removes the exposure entirely and is the cheaper action. The record carries only the systemd GHSA and states no fixed version; wait for your distro's systemd erratum for the exact build.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-16742 https://github.com/systemd/systemd/security/advisories/GHSA-jm29-p7hh-vjhv

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.