CVE-2024-45818
published 2024-12-19CVE-2024-45818: The hypervisor contains code to accelerate VGA memory accesses for HVM guests, when the (virtual) VGA is in "standard" mode. Locking involved there has an…
PriorityP429medium6.5CVSS 3.1
AVLACLPRLUINSCCHINAN
EPSS
0.27%
18.7th percentile
The hypervisor contains code to accelerate VGA memory accesses for HVM
guests, when the (virtual) VGA is in "standard" mode. Locking involved
there has an unusual discipline, leaving a lock acquired past the
return from the function that acquired it. This behavior results in a
problem when emulating an instruction with two memory accesses, both of
which touch VGA memory (plus some further constraints which aren't
relevant here). When emulating the 2nd access, the lock that is already
being held would be attempted to be re-acquired, resulting in a
deadlock.
This deadlock was already found when the code was first introduced, but
was analysed incorrectly and the fix was incomplete. Analysis in light
of the new finding cannot find a way to make the existing locking
discipline work.
In staging, this logic has all been removed because it was discovered
to be accidentally disabled since Xen 4.7. Therefore, we are fixing the
locking problem by backporting the removal of most of the feature. Note
that even with the feature disabled, the lock would still be acquired
for any accesses to the VGA MMIO region.
Affected
12 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | xen | < xen 4.17.5+23-ga4e5191dc0-1 (bookworm) | xen 4.17.5+23-ga4e5191dc0-1 (bookworm) |
| xen | xen | >= 0 < 4.16.6-r3 | 4.16.6-r3 |
| xen | xen | >= 0 < 4.17.5-r2 | 4.17.5-r2 |
| xen | xen | >= 0 < 4.18.3-r2 | 4.18.3-r2 |
| xen | xen | >= 0 < 4.18.3-r2 | 4.18.3-r2 |
| xen | xen | >= 0 < 4.19.0-r1 | 4.19.0-r1 |
| xen | xen | >= 0 < 4.19.0-r1 | 4.19.0-r1 |
| xen | xen | >= 0 < 4.19.0-r1 | 4.19.0-r1 |
| xen | xen | >= 0 < 4.17.5+23-ga4e5191dc0-1 | 4.17.5+23-ga4e5191dc0-1 |
| xen | xen | >= 0 < 4.19.1-1 | 4.19.1-1 |
| xen | xen | >= 0 < 4.19.1-1 | 4.19.1-1 |
| xen | xen | >= 4.6.0 < 4.20.0 | 4.20.0 |
CVSS provenance
nvdv3.16.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N
osv6.5MEDIUM
vendor_debian6.5MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
OSV
CVE-2024-45818: The hypervisor contains code to accelerate VGA memory accesses for HVM guests, when the (virtual) VGA is in "standard" mode
osv·2024-12-19·CVSS 6.5
CVE-2024-45818 [MEDIUM] CVE-2024-45818: The hypervisor contains code to accelerate VGA memory accesses for HVM guests, when the (virtual) VGA is in "standard" mode
The hypervisor contains code to accelerate VGA memory accesses for HVM guests, when the (virtual) VGA is in "standard" mode. Locking involved there has an unusual discipline, leaving a lock acquired past the return from the function that acquired it. This behavior results in a problem when emulating an instruction with two memory accesses, both of which touch VGA memory (plus some further constraints which aren't relevant here). When emulating the 2nd access, the lock that is already being held would be attempted to be re-acquired, resulting in a deadlock. This deadlock was already found when the code was first introduced, but was analysed incorrectly and the fix was incomplete. Analysis in light of the new finding cannot find a way to make the existing locking discipline work. In staging,
OSV
CVE-2024-45818: The hypervisor contains code to accelerate VGA memory accesses for HVM
guests, when the (virtual) VGA is in "standard" mode
osv·2024-12-19·CVSS 6.5
CVE-2024-45818 [MEDIUM] CVE-2024-45818: The hypervisor contains code to accelerate VGA memory accesses for HVM
guests, when the (virtual) VGA is in "standard" mode
The hypervisor contains code to accelerate VGA memory accesses for HVM
guests, when the (virtual) VGA is in "standard" mode. Locking involved
there has an unusual discipline, leaving a lock acquired past the
return from the function that acquired it. This behavior results in a
problem when emulating an instruction with two memory accesses, both of
which touch VGA memory (plus some further constraints which aren't
relevant here). When emulating the 2nd access, the lock that is already
being held would be attempted to be re-acquired, resulting in a
deadlock.
This deadlock was already found when the code was first introduced, but
was analysed incorrectly and the fix was incomplete. Analysis in light
of the new finding cannot find a way to make the existing locking
discipline work.
In stagin
GHSA
GHSA-9ppw-wh7x-2qc9: The hypervisor contains code to accelerate VGA memory accesses for HVM
guests, when the (virtual) VGA is in "standard" mode
ghsa_unreviewed·2024-12-19
CVE-2024-45818 [MEDIUM] CWE-667 GHSA-9ppw-wh7x-2qc9: The hypervisor contains code to accelerate VGA memory accesses for HVM
guests, when the (virtual) VGA is in "standard" mode
The hypervisor contains code to accelerate VGA memory accesses for HVM
guests, when the (virtual) VGA is in "standard" mode. Locking involved
there has an unusual discipline, leaving a lock acquired past the
return from the function that acquired it. This behavior results in a
problem when emulating an instruction with two memory accesses, both of
which touch VGA memory (plus some further constraints which aren't
relevant here). When emulating the 2nd access, the lock that is already
being held would be attempted to be re-acquired, resulting in a
deadlock.
This deadlock was already found when the code was first introduced, but
was analysed incorrectly and the fix was incomplete. Analysis in light
of the new finding cannot find a way to make the existing locking
discipline work.
In stagin
Debian
CVE-2024-45818: xen - The hypervisor contains code to accelerate VGA memory accesses for HVM guests, w...
vendor_debian·2024·CVSS 6.5
CVE-2024-45818 [MEDIUM] CVE-2024-45818: xen - The hypervisor contains code to accelerate VGA memory accesses for HVM guests, w...
The hypervisor contains code to accelerate VGA memory accesses for HVM guests, when the (virtual) VGA is in "standard" mode. Locking involved there has an unusual discipline, leaving a lock acquired past the return from the function that acquired it. This behavior results in a problem when emulating an instruction with two memory accesses, both of which touch VGA memory (plus some further constraints which aren't relevant here). When emulating the 2nd access, the lock that is already being held would be attempted to be re-acquired, resulting in a deadlock. This deadlock was already found when the code was first introduced, but was analysed incorrectly and the fix was incomplete. Analysis in light of the new finding cannot find a way to make the existing locking discipline work. In staging,
No detection rules found.
No public exploits indexed.
2024-12-19
Published