Re: [PATCH v3] KVM: s390: Fall back to short-term pinning in MAP ioctl

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Guest-triggerable WARN_ON_ONCE in adapter_indicators_set leads to host DoS.
--

--- Patch [1]: [PATCH v3] KVM: s390: Fall back to short-term pinning in MAP ioctl ---
commit 07b3642c0ab06a5f6b361f58b4393eb785c7021c
Author: Jaehoon Kim <jhkim@linux.ibm.com>

KVM: s390: Fall back to short-term pinning in MAP ioctl

This commit modifies the KVM s390 MAP ioctl to support memory types that cannot
be long-term pinned, such as file-backed memory. It falls back to verifying
access with a short-term pin, preserving a map entry with a new pinned flag
set to false. Accesses in the interrupt fast path are updated to skip these
unpinned entries, causing them to fall back to the non-atomic path.

> diff --git a/arch/s390/kvm/interrupt.c b/arch/s390/kvm/interrupt.c
> --- a/arch/s390/kvm/interrupt.c
> +++ b/arch/s390/kvm/interrupt.c
[ ... ]
> @@ -2929,8 +2954,11 @@ static struct s390_map_info *get_map_info(struct s390_io_adapter *adapter,
>  		return NULL;
>  
>  	list_for_each_entry(map, &adapter->maps, list) {
> -		if (map->addr == addr)
> +		if (map->addr == addr) {
> +			if (!map->pinned)
> +				return NULL;

[Severity: High]
This isn't a bug introduced by this patch, but returning NULL here forces
the caller to fall back to the non-atomic path in adapter_indicators_set().

If a malicious guest or untrusted userspace configures an IRQ routing entry
with an unmapped host virtual address for summary_addr, the short-term pin
will fail:

arch/s390/kvm/interrupt.c:adapter_indicators_set() {
    ...
    summary_info = get_map_info(adapter, adapter_int->summary_addr);
    if (!summary_info) {
        ...
        summary_page = pin_map_page(kvm, adapter_int->summary_addr, 0);
        if (WARN_ON_ONCE(!summary_page))
            return -1;
    ...
}

Could this guest-triggerable WARN_ON_ONCE lead to a host denial of service
if panic_on_warn is enabled on the host?

Should this WARN_ON_ONCE be downgraded to a normal error return so that it
safely handles unmapped addresses?

>  			return map;
> +		}
>  	}
>  	return NULL;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260724133943.1664961-1-jhkim@linux.ibm.com?part=1