Re: [PATCH v3 1/3] LoongArch: KVM: Set default MAILBOX access size with 8

[sashiko-bot@kernel.org]

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

New issues:
- [High] Guest-triggerable Host Denial of Service via WARN_ONCE assertions.

Pre-existing issues:
- [High] Guest-triggerable Host Denial of Service via WARN_ON_ONCE on unaligned IOCSR access.
- [High] Slab-Out-Of-Bounds memory read in `read_mailbox()` causes KASAN panic.
--

commit cd8b88f78bdc2b7a47541c3fb91dfaf558c8c761
Author: Bibo Mao <maobibo@loongson.cn>
Date:   Mon Jun 29 02:32:11 2026 +0000

    LoongArch: KVM: Set default MAILBOX access size with 8
    
    With IOCSR instruction emulation in function kvm_emu_iocsr(), the possible
    size combination is 1/2/4/8 and no other combinations. Here remove the
    old default case and replace the default case with 8 in read_mailbox()
    and write_mailbox().
    
    Signed-off-by: Bibo Mao <maobibo@loongson.cn>

> diff --git a/arch/loongarch/kvm/intc/ipi.c b/arch/loongarch/kvm/intc/ipi.c
> index 4fa0897d7bdb0..d70bf415c7fc6 100644
> --- a/arch/loongarch/kvm/intc/ipi.c
> +++ b/arch/loongarch/kvm/intc/ipi.c
> @@ -67,11 +67,8 @@ static uint64_t read_mailbox(struct kvm_vcpu *vcpu, int offset, int len)
>  		return data & 0xffff;
>  	case 4:
>  		return data & 0xffffffff;
> -	case 8:
> -		return data;
>  	default:
> -		kvm_err("%s: unknown data len: %d\n", __func__, len);
> -		return 0;
> +		return data;
>  	}
>  }

[Severity: High]
This is a pre-existing issue, but does read_mailbox() unconditionally read 8
bytes from the buffer, exceeding the 32-byte bounds if the requested offset
and length approach the end of the allowed range (e.g., offset 0x3c with
length 4)?

Looking at read_mailbox():

    arch/loongarch/kvm/intc/ipi.c:read_mailbox() {
        ...
        spin_lock(&vcpu->arch.ipi_state.lock);
        data = *(ulong *)((void *)vcpu->arch.ipi_state.buf + (offset - 0x20));
        spin_unlock(&vcpu->arch.ipi_state.lock);
        ...

A guest performing a valid 4-byte IOCSR read at offset 0x3c causes
read_mailbox() to calculate the array index as 0x1c (28). Dereferencing an
8-byte ulong pointer from this index within the 32-byte
vcpu->arch.ipi_state.buf array reads bytes 28 through 35, where bytes 32-35
fall outside the bounds of the array into adjacent fields in struct
kvm_vcpu_arch. Could this out-of-bounds memory read trigger a KASAN panic,
causing a host denial of service?

[Severity: High]
This is a pre-existing issue, but can an unprivileged guest trigger a host
denial of service via WARN_ON_ONCE on unaligned IOCSR access?

Looking at loongarch_ipi_readl() and loongarch_ipi_writel():

    arch/loongarch/kvm/intc/ipi.c:loongarch_ipi_readl() {
        ...
        offset = (uint32_t)(addr & 0x1ff);
        WARN_ON_ONCE(offset & (len - 1));
        ...

If a guest executes an IOCSR instruction with an unaligned address (e.g.,
iocsrrd.w at address 0x1001), the hardware/emulated offset is calculated as
addr & 0x1ff, which will be unaligned. This causes the
WARN_ON_ONCE(offset & (len - 1)) assertion to fire, which can panic the host
kernel if panic_on_warn is enabled.

[Severity: High]
While the intention may have been to reduce log spam by replacing kvm_err()
with WARN_ONCE(), does this inadvertently create a denial of service vector?

Looking at mail_send() in arch/loongarch/kvm/intc/ipi.c:

    arch/loongarch/kvm/intc/ipi.c:mail_send() {
        ...
        if (unlikely(vcpu == NULL)) {
            WARN_ONCE(1, "%s: invalid target cpu: %d\n", __func__, cpu);
            return 0;
        }
        ...

And in kvm_complete_iocsr_read() in arch/loongarch/kvm/exit.c:

    arch/loongarch/kvm/exit.c:kvm_complete_iocsr_read() {
        ...
        default:
            WARN_ONCE(1, "Bad IOCSR length: %d, addr is 0x%lx\n", run->iocsr_io.len, vcpu->arch.badv);
            er = EMULATE_FAIL;
        ...

An unprivileged guest can deliberately provide invalid inputs (e.g., an
unknown IOCSR address, an invalid target CPU ID for a mailbox send, or an
unsupported MMIO length). This causes the emulation handlers to hit these
WARN_ONCE() macros. Could this allow a malicious guest to trigger a kernel
panic if panic_on_warn is enabled?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260629023213.597030-1-maobibo@loongson.cn?part=1