GPU VulnDB

Database/Kernel, userspace & hypervisor

zbus_polkit: caller-supplied UID is silently discarded, leaving polkit authorization open to a PID-reuse race

CVE-2026-78422Kernel, userspace & hypervisorcurated

Impact

Rust system daemons that gate privileged operations behind polkit commonly pass the peer UID they obtained from SO_PEERCRED into Subject::new_for_owner() precisely so that a PID-reuse race cannot decide the outcome. Because the crate encodes that UID as D-Bus type u instead of the signed i the PolicyKit1 Authority interface expects, polkit discards it and falls back to looking the PID up in /proc - the exact time-of-check/time-of-use lookup the caller was trying to avoid. A local unprivileged user on the node who can get an authorized process to exit and then win the PID race is authorized as that process and performs actions they are not entitled to. On a shared build host, login node, or any GPU node where untrusted users get local shells, this is a local privilege escalation against whatever the affected daemon controls.

Who can reach it

Local unprivileged user on the same host, able to talk to a daemon that uses zbus_polkit for authorization and to win a PID-reuse race after an authorized process exits. No remote path.

What to do

Update zbus_polkit to 5.1.0 or later, rebuild every Rust daemon that vendors it, and restart those daemons - Cargo pins the version per binary, so a distro package bump does not help until each consumer is rebuilt. Inventory first: only services that actually call Subject::new_for_owner() are affected, and many polkit callers do not. SUSE bug 1277659 and the upstream PR are the references for tracking distro rebuilds.

References

Related entries

All Kernel, userspace & hypervisor entries

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.