Re: [PATCH v5 1/9] mshv: Provide a way to get partition ID if running in a VMM process

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [High] Using `current->tgid` for implicit VM partition binding restricts multi-process architectures, introduces PID reuse vulnerabilities (Privilege Escalation and DoS), and causes spurious creation failures.

Pre-existing issues:
- [Critical] Unchecked virtual processor (VP) access in `mshv_try_assert_irq_fast` can lead to a kernel panic.
--

--- Patch [1]: [PATCH v5 1/9] mshv: Provide a way to get partition ID if running in a VMM process ---
commit c09a2034eaac3e66996c48aebdd226e834f0611e
Author: Mukesh R <mrathor@linux.microsoft.com>

mshv: Provide a way to get partition ID if running in a VMM process

This commit adds a field to the MSHV partition structure to save the
tgid of the VMM process that created it. It also introduces a helper to
retrieve the partition ID by matching the current tgid and restricts
creation to one partition per VMM instance.

> diff --git a/drivers/hv/mshv_root_main.c b/drivers/hv/mshv_root_main.c
> --- a/drivers/hv/mshv_root_main.c
> +++ b/drivers/hv/mshv_root_main.c
[ ... ]
> +u64 mshv_current_partid(void)
> +{
> +	struct mshv_partition *pt;
> +	int i;
> +	u64 ret_ptid = HV_PARTITION_ID_INVALID;
> +
> +	rcu_read_lock();
> +
> +	hash_for_each_rcu(mshv_root.pt_htable, i, pt, pt_hnode) {
> +		if (pt->pt_vmm_tgid == current->tgid) {
> +			ret_ptid = pt->pt_id;
> +			break;
> +		}
> +	}
> +
> +	rcu_read_unlock();
> +	return ret_ptid;
> +}
> +EXPORT_SYMBOL_GPL(mshv_current_partid);
> +
> +/* At present, we only allow one partition per VMM instance */
>  static int
>  add_partition(struct mshv_partition *partition)
>  {
> +	int rc = 0;
> +
>  	spin_lock(&mshv_root.pt_ht_lock);
>  
> +	if (mshv_current_partid() != HV_PARTITION_ID_INVALID) {
> +		rc = -EEXIST;
> +		goto out;
> +	}
> +
> +	partition->pt_vmm_tgid = current->tgid;

[Severity: High]
Does using current->tgid for implicit VM partition binding introduce risks
with process lifecycle and PID reuse?

If a VMM process creates a partition, passes the file descriptor to another
process (e.g., via a UNIX socket) and exits, the original tgid could be
recycled for a new, unrelated process.

If that new process performs operations that invoke mshv_current_partid(),
could it incorrectly inherit the partition context of the previous process?

Alternatively, if the new process attempts to create its own partition in
add_partition(), would it incorrectly fail with -EEXIST?

[Severity: Critical]
This is a pre-existing issue, but I noticed a potential unchecked access
during the review of this subsystem.

In drivers/hv/mshv_eventfd.c:mshv_try_assert_irq_fast():

    vp = partition->pt_vp_array[irq->lapic_apic_id];

    if (!vp->vp_register_page) {
        ...

If userspace sets up an irqfd routing entry with an APIC ID that has no
corresponding virtual processor created yet, will vp be NULL when fetched
from pt_vp_array?

If so, would the immediate dereference of vp->vp_register_page result in a
host kernel panic when the eventfd is signaled?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260731223427.2554388-1-mrathor@linux.microsoft.com?part=1