CVE-2023-54007 in Linux
Summary
by MITRE • 12/24/2025
In the Linux kernel, the following vulnerability has been resolved:
vmci_host: fix a race condition in vmci_host_poll() causing GPF
During fuzzing, a general protection fault is observed in vmci_host_poll().
general protection fault, probably for non-canonical address 0xdffffc0000000019: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x00000000000000c8-0x00000000000000cf]
RIP: 0010:__lock_acquire+0xf3/0x5e00 kernel/locking/lockdep.c:4926 <- omitting registers -> Call Trace: <TASK> lock_acquire+0x1a4/0x4a0 kernel/locking/lockdep.c:5672 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0xb3/0x100 kernel/locking/spinlock.c:162 add_wait_queue+0x3d/0x260 kernel/sched/wait.c:22 poll_wait include/linux/poll.h:49 [inline]
vmci_host_poll+0xf8/0x2b0 drivers/misc/vmw_vmci/vmci_host.c:174 vfs_poll include/linux/poll.h:88 [inline]
do_pollfd fs/select.c:873 [inline]
do_poll fs/select.c:921 [inline]
do_sys_poll+0xc7c/0x1aa0 fs/select.c:1015 __do_sys_ppoll fs/select.c:1121 [inline]
__se_sys_ppoll+0x2cc/0x330 fs/select.c:1101 do_syscall_x64 arch/x86/entry/common.c:51 [inline]
do_syscall_64+0x4e/0xa0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x46/0xb0
Example thread interleaving that causes the general protection fault is as follows:
CPU1 (vmci_host_poll) CPU2 (vmci_host_do_init_context) ----- ----- // Read uninitialized context context = vmci_host_dev->context; // Initialize context vmci_host_dev->context = vmci_ctx_create(); vmci_host_dev->ct_type = VMCIOBJ_CONTEXT;
if (vmci_host_dev->ct_type == VMCIOBJ_CONTEXT) {
// Dereferencing the wrong pointer poll_wait(..., &context->host_context); }
In this scenario, vmci_host_poll() reads vmci_host_dev->context first, and then reads vmci_host_dev->ct_type to check that vmci_host_dev->context is initialized. However, since these two reads are not atomically executed, there is a chance of a race condition as described above.
To fix this race condition, read vmci_host_dev->context after checking the value of vmci_host_dev->ct_type so that vmci_host_poll() always reads an initialized context.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 01/30/2026
The vulnerability described in CVE-2023-54007 resides within the Linux kernel's VMware VMCI (Virtual Machine Communication Interface) subsystem, specifically in the vmci_host_poll() function. This issue manifests as a general protection fault (GPF) that occurs during kernel execution, indicating a critical failure in memory access management. The flaw was discovered through fuzzing techniques that systematically test kernel code paths to identify potential instability conditions. The error trace reveals a null pointer dereference within the kernel's locking subsystem, specifically in lockdep.c, suggesting that the kernel's lock tracking mechanism encountered an invalid memory reference during the polling operation.
The technical root cause of this vulnerability stems from a race condition in the vmci_host_poll() function's logic flow. The function performs two separate memory reads from the vmci_host_device structure - first accessing vmci_host_dev->context and then checking vmci_host_dev->ct_type to determine if the context is valid. This non-atomic sequence creates a window where another execution thread can modify the context pointer between these two reads, leading to a scenario where vmci_host_poll() attempts to dereference a pointer that has been initialized by a concurrent thread but not yet fully established. This race condition is classified as a classic data race pattern that violates memory consistency guarantees required for concurrent kernel operations.
The operational impact of this vulnerability extends beyond simple kernel crashes, as it represents a potential security risk that could be exploited to cause system instability or potentially enable privilege escalation. The GPF condition occurs during normal polling operations, meaning that any application or system process that relies on VMCI communication interfaces could trigger this fault. This vulnerability affects systems running Linux kernels with VMware VMCI support, particularly those utilizing virtualization environments where VMCI is actively used for guest-to-host communication. The fault demonstrates a failure in proper synchronization mechanisms, as the code does not employ atomic operations or proper locking to ensure consistency between the context pointer and type checking operations, which aligns with CWE-362 - Concurrent Execution using Shared Resource with Improper Synchronization.
The fix for this vulnerability requires a modification to the vmci_host_poll() function's logic to ensure proper ordering of memory operations. The recommended approach involves reordering the operations so that vmci_host_dev->ct_type is checked first, followed by reading vmci_host_dev->context only after confirming that the context has been properly initialized. This ensures that the polling function always operates on a valid context pointer, eliminating the race condition window. The solution follows established kernel programming practices for avoiding data races and aligns with ATT&CK technique T1068 - Exploitation for Privilege Escalation, as it addresses a fundamental concurrency issue that could potentially be leveraged to gain elevated privileges through system instability. This fix represents a defensive programming approach that prioritizes memory safety over performance considerations in kernel space operations, ensuring that shared resource access patterns maintain proper synchronization semantics.