Acknowledged
Created: Oct 29, 2025
Updated: Oct 30, 2025
Found In Version: 10.25.33.1
Severity: Standard
Applicable for: Wind River Linux LTS 25
Component/s: Kernel
In the Linux kernel, the following vulnerability has been resolved:[EOL][EOL]uio_hv_generic: Let userspace take care of interrupt mask[EOL][EOL]Remove the logic to set interrupt mask by default in uio_hv_generic[EOL]driver as the interrupt mask value is supposed to be controlled[EOL]completely by the user space. If the mask bit gets changed[EOL]by the driver, concurrently with user mode operating on the ring,[EOL]the mask bit may be set when it is supposed to be clear, and the[EOL]user-mode driver will miss an interrupt which will cause a hang.[EOL][EOL]For eg- when the driver sets inbound ring buffer interrupt mask to 1,[EOL]the host does not interrupt the guest on the UIO VMBus channel.[EOL]However, setting the mask does not prevent the host from putting a[EOL]message in the inbound ring buffer.Â\xa0So letâ\x80\x99s assume that happens,[EOL]the host puts a message into the ring buffer but does not interrupt.[EOL][EOL]Subsequently, the user space code in the guest sets the inbound ring[EOL]buffer interrupt mask to 0, saying â\x80\x9cHey, Iâ\x80\x99m ready for interruptsâ\x80\x9d.[EOL]User space code then calls pread() to wait for an interrupt.[EOL]Then one of two things happens:[EOL][EOL]* The host never sends another message. So the pread() waits forever.[EOL]* The host does send another message. But because thereâ\x80\x99s already a[EOL] message in the ring buffer, it doesnâ\x80\x99t generate an interrupt.[EOL] This is the correct behavior, because the host should only send an[EOL] interrupt when the inbound ring buffer transitions from empty to[EOL] not-empty. Adding an additional message to a ring buffer that is not[EOL] empty is not supposed to generate an interrupt on the guest.[EOL] Since the guest is waiting in pread() and not removing messages from[EOL] the ring buffer, the pread() waits forever.[EOL][EOL]This could be easily reproduced in hv_fcopy_uio_daemon if we delay[EOL]setting interrupt mask to 0.[EOL][EOL]Similarly if hv_uio_channel_cb() sets the interrupt_mask to 1,[EOL]thereâ\x80\x99s a race condition. Once user space empties the inbound ring[EOL]buffer, but before user space sets interrupt_mask to 0, the host could[EOL]put another message in the ring buffer but it wouldnâ\x80\x99t interrupt.[EOL]Then the next pread() would hang.[EOL][EOL]Fix these by removing all instances where interrupt_mask is changed,[EOL]while keeping the one in set_event() unchanged to enable userspace[EOL]control the interrupt mask by writing 0/1 to /dev/uioX.