CVE-2024-8235

What it actually does

A NULL-pointer dereference in the refactored interface listing code path causes virtinterfaced to crash when an API request results in a zero-byte allocation on affected platforms.

Why it matters to the business

Management of virtual machines becomes unavailable until the daemon is restarted, interrupting administrative operations and potentially affecting dependent infrastructure services.

How an attack unfolds

An unauthenticated or low-privileged client connects to the read-only libvirt socket and invokes one of the affected list-interface APIs; on platforms where the allocation returns NULL, the subsequent dereference crashes the daemon.

How to fix it

Upgrade libvirt to the commit 7d72b18017a8173b7d359025d7aeff4f4e527099 or later; rebuild and redeploy affected packages. Restart virtinterfaced after the update.

How to confirm the fix worked

Confirm the running libvirt binary contains commit 7d72b18017a8173b7d359025d7aeff4f4e527099, then verify that interface-listing calls no longer cause daemon crashes under the zero-allocation condition.

Typical attack path

1. Locate and connect to the libvirt read-only UNIX socket
2. Issue an API call that enumerates network interfaces
3. Trigger the zero-allocation corner case in the refactored listing logic
4. Cause virtinterfaced to dereference NULL and terminate

How to detect it

Search system and libvirt logs for unexpected virtinterfaced process terminations or segmentation faults occurring shortly after interface enumeration requests on the read-only socket.

• virtinterfaced: segfault at
• libvirt: unexpected NULL pointer in interface listing

What your security team should do

• Apply the fixed commit or packaged update to all libvirt hosts
• Restrict access to the read-only socket to trusted management clients only
• Monitor virtinterfaced process health and implement automatic restart on crash
• Review socket permissions and consider disabling unused libvirt APIs