Answer in brief
CVE-2024-4418 records a Medium severity (CVSS 6.2) vulnerability in Libvirt: stack use-after-free in virnetclientioeventloop(). The current sources do not mark it as known exploited. The current feed maps libvirt (generic), Red Hat/virt:av/libvirt (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 6.2. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps libvirt (generic), Red Hat/virt:av/libvirt (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| libvirtgeneric | >=0 <10.4.0 | 10.4.0 |
| Red Hat/virt:av/libvirtgeneric | * | Not reported |
Published upstream
May 8, 2024
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Nov 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Nov 5, 2026
A race condition leading to a stack use-after-free flaw was found in libvirt. Due to a bad assumption in the virNetClientIOEventLoop() method, the `data` pointer to a stack-allocated virNetClientIOEventData structure ended up being used in the virNetClientIOEventFD callback while the data pointer's stack frame was concurrently being "freed" when returning from virNetClientIOEventLoop(). The 'virtproxyd' daemon can be used to trigger requests. If libvirt is configured with fine-grained access control, this issue, in theory, allows a user to escape their otherwise limited access. This flaw allows a local, unprivileged user to access virtproxyd without authenticating. Remote users would need to authenticate before they could access it.
Quoted source text, attributed separately from HOL analysis.