CVE-2025-40048 in Linux
Summary
by MITRE • 10/28/2025
In the Linux kernel, the following vulnerability has been resolved:
uio_hv_generic: Let userspace take care of interrupt mask
Remove the logic to set interrupt mask by default in uio_hv_generic driver as the interrupt mask value is supposed to be controlled completely by the user space. If the mask bit gets changed by the driver, concurrently with user mode operating on the ring, the mask bit may be set when it is supposed to be clear, and the user-mode driver will miss an interrupt which will cause a hang.
For eg- when the driver sets inbound ring buffer interrupt mask to 1, the host does not interrupt the guest on the UIO VMBus channel. However, setting the mask does not prevent the host from putting a message in the inbound ring buffer. So let’s assume that happens, the host puts a message into the ring buffer but does not interrupt.
Subsequently, the user space code in the guest sets the inbound ring buffer interrupt mask to 0, saying “Hey, I’m ready for interrupts”. User space code then calls pread() to wait for an interrupt. Then one of two things happens:
* The host never sends another message. So the pread() waits forever. * The host does send another message. But because there’s already a message in the ring buffer, it doesn’t generate an interrupt. This is the correct behavior, because the host should only send an interrupt when the inbound ring buffer transitions from empty to not-empty. Adding an additional message to a ring buffer that is not empty is not supposed to generate an interrupt on the guest. Since the guest is waiting in pread() and not removing messages from the ring buffer, the pread() waits forever.
This could be easily reproduced in hv_fcopy_uio_daemon if we delay setting interrupt mask to 0.
Similarly if hv_uio_channel_cb() sets the interrupt_mask to 1, there’s a race condition. Once user space empties the inbound ring buffer, but before user space sets interrupt_mask to 0, the host could put another message in the ring buffer but it wouldn’t interrupt. Then the next pread() would hang.
Fix these by removing all instances where interrupt_mask is changed, while keeping the one in set_event() unchanged to enable userspace control the interrupt mask by writing 0/1 to /dev/uioX.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 05/20/2026
The vulnerability CVE-2025-40048 affects the Linux kernel's uio_hv_generic driver which handles UIO (Userspace I/O) operations over Hyper-V VMBus channels. This flaw stems from improper interrupt mask management within the driver, creating a race condition between kernel space operations and userspace driver behavior. The core issue arises from the driver's automatic intervention in interrupt mask state management, which conflicts with the intended userspace control mechanism. According to CWE-691, this represents an inadequate control of a resource through use of a system call, where the kernel component does not properly delegate interrupt handling responsibilities to the user application. The vulnerability specifically targets the hypervisor-based virtualization environment where the UIO framework mediates communication between guest operating systems and hypervisor services through VMBus channels.
The technical flaw manifests when the uio_hv_generic driver attempts to automatically set interrupt masks during operation, creating a fundamental conflict with userspace expectations. When the driver sets the inbound ring buffer interrupt mask to 1, it prevents the host from generating interrupts to the guest, even though the host may still place messages into the ring buffer. This creates a scenario where messages accumulate in the buffer without interrupt notifications, leading to indefinite waiting states for userspace applications. The race condition becomes apparent when userspace code attempts to read from the ring buffer using pread() operations while the driver's automatic masking interferes with proper interrupt signaling. This behavior violates the expected interrupt semantics where interrupts should only occur when the ring buffer transitions from empty to non-empty, as defined by the VMBus protocol specifications. The ATT&CK technique T1059.003 applies here as the vulnerability enables persistent communication channel manipulation through kernel-level interrupt control.
The operational impact of this vulnerability is significant for virtualized environments relying on Hyper-V integration services, particularly affecting daemon processes like hv_fcopy_uio_daemon that depend on proper interrupt handling for message processing. When the race condition occurs, userspace applications can hang indefinitely waiting for interrupt events that never arrive, causing complete service disruption and system unresponsiveness. The vulnerability is particularly dangerous in production environments where virtual machines depend on timely message delivery for backup operations, file copying, and other critical services. The fix addresses this by removing all automatic interrupt mask modifications while preserving the set_event() function that allows userspace to control the interrupt mask through direct device file operations. This ensures that interrupt handling remains under explicit userspace control, preventing the kernel from inadvertently masking interrupts that userspace applications require for proper operation. The solution aligns with the principle of least privilege and proper separation of concerns between kernel and userspace components in virtualized I/O handling.