CVE-2023-34324: Linux · Vulnerability
Affects LinuxSource CVE Database V5
Not known to be exploited · CVSS 4.9 Medium.
Data as of 26 Oct 2026, 06:26 UTC
- EPSS
- 1.1% chance of exploitation in 30 days – higher than 66% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:HExploitation evidence
Disclosed: evidence found.
CVE published 5 Jan 2024
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 2026-10-26.
What to do
AI-suggested
To mitigate CVE-2023-34324, European organizations should prioritize the following actions: 1) Apply Linux kernel updates as soon as patches become available from trusted vendors or distributions, ensuring Xen-related fixes are included. 2) Monitor Xen hypervisor and guest kernel versions to identify vulnerable deployments. 3) Limit the use of paravirtual devices and event channel closures during critical operations to reduce the chance of triggering the deadlock. 4) Implement strict access controls and monitoring to prevent unauthorized privilege escalation within guest VMs, as exploitation requires high privileges. 5) Consider architectural changes to reduce reliance on Xen paravirtualization where feasible, or migrate to alternative virtualization technologies less susceptible to this issue. 6) Employ robust incident response plans to detect and recover from potential DoS conditions caused by this vulnerability. 7) Engage with Linux and Xen communities to stay informed about patches and recommended configurations. 8) Test updates and configuration changes in staging environments to ensure stability before production deployment.
Description
Closing of an event channel in the Linux kernel can result in a deadlock. This happens when the close is being performed in parallel to an unrelated Xen console action and the handling of a Xen console interrupt in an unprivileged guest. The closing of an event channel is e.g.triggered by removal of a paravirtual device on the other side. As this action will cause console messages to be issued on the other side quite often, the chance of triggering the deadlock is not neglectable. Note that 32-bit Arm-guests are not affected, as the 32-bit Linux kernel on Arm doesn't use queued-RW-locks, which are required to trigger the issue (on Arm32 a waiting writer doesn't block further readers to get the lock).