On 10/18/2026 9:16 AM, Jiale Yao wrote:
mshv_vtl_init() registers /dev/mshv before initializing the poll file
mutex. A concurrent MSHV_SET_POLL_FILE ioctl can therefore attempt to lock
an uninitialized mutex while module initialization is still in progress.

Initialize the file-scope mutex statically so it is ready before the misc
device becomes visible.

Fixes: 7bfe3b8ea6e3 ("Drivers: hv: Introduce mshv_vtl driver")
Signed-off-by: Jiale Yao <[email protected]>
---
  drivers/hv/mshv_vtl_main.c | 4 +---
  1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/hv/mshv_vtl_main.c b/drivers/hv/mshv_vtl_main.c
index d8225242c73f..2b40c9e3bf88 100644
--- a/drivers/hv/mshv_vtl_main.c
+++ b/drivers/hv/mshv_vtl_main.c
@@ -95,7 +95,7 @@ union hv_synic_overlay_page_msr {
        } __packed;
  };
-static struct mutex mshv_vtl_poll_file_lock;
+static DEFINE_MUTEX(mshv_vtl_poll_file_lock);
  static union hv_register_vsm_page_offsets mshv_vsm_page_offsets;
  static union hv_register_vsm_capabilities mshv_vsm_capabilities;
@@ -1370,8 +1370,6 @@ static int __init mshv_vtl_init(void)
                goto free_low;
        }
- mutex_init(&mshv_vtl_poll_file_lock);
-
        device_initialize(mem_dev);
        dev_set_name(mem_dev, "mshv vtl mem dev");
        ret = device_add(mem_dev);

While this issue may not happen in practice, as OpenVMM userspace runs much later than these init function invocations, but it is good to have the potential race condition fixed.

Reviewed-by: Naman Jain <[email protected]>

Regards,
Naman



Reply via email to