CVE-2025-40048

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> uio_hv_generic: Let userspace take care of interrupt mask<br /> <br /> Remove the logic to set interrupt mask by default in uio_hv_generic<br /> driver as the interrupt mask value is supposed to be controlled<br /> completely by the user space. If the mask bit gets changed<br /> by the driver, concurrently with user mode operating on the ring,<br /> the mask bit may be set when it is supposed to be clear, and the<br /> user-mode driver will miss an interrupt which will cause a hang.<br /> <br /> For eg- when the driver sets inbound ring buffer interrupt mask to 1,<br /> the host does not interrupt the guest on the UIO VMBus channel.<br /> However, setting the mask does not prevent the host from putting a<br /> message in the inbound ring buffer. So let’s assume that happens,<br /> the host puts a message into the ring buffer but does not interrupt.<br /> <br /> Subsequently, the user space code in the guest sets the inbound ring<br /> buffer interrupt mask to 0, saying “Hey, I’m ready for interrupts”.<br /> User space code then calls pread() to wait for an interrupt.<br /> Then one of two things happens:<br /> <br /> * The host never sends another message. So the pread() waits forever.<br /> * The host does send another message. But because there’s already a<br /> message in the ring buffer, it doesn’t generate an interrupt.<br /> This is the correct behavior, because the host should only send an<br /> interrupt when the inbound ring buffer transitions from empty to<br /> not-empty. Adding an additional message to a ring buffer that is not<br /> empty is not supposed to generate an interrupt on the guest.<br /> Since the guest is waiting in pread() and not removing messages from<br /> the ring buffer, the pread() waits forever.<br /> <br /> This could be easily reproduced in hv_fcopy_uio_daemon if we delay<br /> setting interrupt mask to 0.<br /> <br /> Similarly if hv_uio_channel_cb() sets the interrupt_mask to 1,<br /> there’s a race condition. Once user space empties the inbound ring<br /> buffer, but before user space sets interrupt_mask to 0, the host could<br /> put another message in the ring buffer but it wouldn’t interrupt.<br /> Then the next pread() would hang.<br /> <br /> Fix these by removing all instances where interrupt_mask is changed,<br /> while keeping the one in set_event() unchanged to enable userspace<br /> control the interrupt mask by writing 0/1 to /dev/uioX.