Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] Uninitialized kernel memory in the `in` bounce page is exposed to the hypervisor and potentially other untrusted VTLs. -- commit e6ad11845017945abcff5cffd83d1f2f8170c980 Author: Yousef Alhouseen <[email protected]> mshv_vtl: clear hypercall output before copyout mshv_vtl_hvcall_call() copies output_size bytes to userspace. The output page is freshly allocated. Userspace chooses the copyout length. If the hypercall writes less, the tail can contain stale page data. Clear the copied range before issuing the hypercall. > diff --git a/drivers/hv/mshv_vtl_main.c b/drivers/hv/mshv_vtl_main.c > --- a/drivers/hv/mshv_vtl_main.c > +++ b/drivers/hv/mshv_vtl_main.c > @@ -1148,12 +1148,22 @@ static int mshv_vtl_hvcall_call(struct > mshv_vtl_hvcall_fd *fd, > */ > in = (void *)__get_free_page(GFP_KERNEL); [Severity: High] This is a pre-existing issue, but does this allocation also need to be cleared to prevent leaking kernel memory to the hypervisor? Since the subsequent copy_from_user() only copies hvcall.input_size bytes, the tail of the page remains uninitialized. If a user provides a small input_size but crafts hvcall.control so the hypervisor expects a larger payload, the hypervisor will read the uninitialized tail of the page during hv_do_hypercall(). Should this use __get_free_page(GFP_KERNEL | __GFP_ZERO) to prevent stale data from being exposed to the hypervisor across security boundaries? > out = (void *)__get_free_page(GFP_KERNEL); > + if (!in || !out) { > + ret = -ENOMEM; > + goto free_pages; > + } > > if (copy_from_user(in, (void __user *)hvcall.input_ptr, > hvcall.input_size)) { > ret = -EFAULT; > goto free_pages; > } -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
