libvirt: race in the RPC client event loop gives a stack use-after-free reachable through virtproxyd

CVSS 6.2CVE-2024-4418Kernel, userspace & hypervisorcurated

Impact

A bad assumption in virNetClientIOEventLoop() leaves the virNetClientIOEventFD callback using a pointer to a stack-allocated structure whose frame is concurrently being unwound. Red Hat's analysis is that the practical impact is availability - crashing the daemon - and notes that where fine-grained access control is configured this could in theory let a user escape their otherwise limited access. Because virtproxyd can be driven without authentication by a local user, any local account on a virtualized GPU host can trigger the requests; remote users must authenticate first. The operator consequence is the same as other libvirt daemon crashes: the node's VM management plane goes away while guests keep running, so migration and drain automation stalls.

Who can reach it

A local, unprivileged user on the host, through virtproxyd, with no authentication. Remote exploitation requires authenticating to libvirt first.

What to do

Update libvirt through the vendor errata (RHSA-2024:4351, 4432, 4757) and restart the libvirt daemons, including virtproxyd. Running domains survive a daemon restart, so no node drain or reboot is needed. If you do not use virtproxyd, disabling it removes the unauthenticated local path pending the update.

References

https://nvd.nist.gov/vuln/detail/CVE-2024-4418 https://access.redhat.com/security/cve/CVE-2024-4418 https://access.redhat.com/errata/RHSA-2024:4351 https://bugzilla.redhat.com/show_bug.cgi?id=2278616

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.