From: sashiko-bot@kernel.org
To: "Bibo Mao" <maobibo@loongson.cn>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH v3 2/3] LoongArch: KVM: Replace kvm_err() with WARN_ONCE()
Date: Mon, 29 Jun 2026 02:37:26 +0000 [thread overview]
Message-ID: <20260629023727.428171F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260629023213.597030-3-maobibo@loongson.cn>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] Replacing `kvm_err()` with `WARN_ONCE()` on user- and guest-controllable error paths introduces a host Denial of Service (DoS) vulnerability.
--
commit 2fb4171bf923d0f32f53ed0ef52aee506acd81c3
Author: Bibo Mao <maobibo@loongson.cn>
LoongArch: KVM: Replace kvm_err() with WARN_ONCE()
Since guest kernel and ioctl parameter from user mode is untrusted,
there may be noise kernel log output in host hypervisor with abnormal
state. Here replace kvm_err() with WARN_ONCE() to reduce this kind
of noise kernel log, and there is no function change.
> diff --git a/arch/loongarch/kvm/exit.c b/arch/loongarch/kvm/exit.c
> --- a/arch/loongarch/kvm/exit.c
> +++ b/arch/loongarch/kvm/exit.c
> @@ -252,7 +252,7 @@ int kvm_complete_iocsr_read(struct kvm_vcpu *vcpu, struct kvm_run *run)
> *gpr = *(s64 *)run->iocsr_io.data;
> break;
> default:
> - kvm_err("Bad IOCSR length: %d, addr is 0x%lx\n",
> + WARN_ONCE(1, "Bad IOCSR length: %d, addr is 0x%lx\n",
> run->iocsr_io.len, vcpu->arch.badv);
[Severity: Critical]
Does changing this to a WARN_ONCE() introduce a host denial of service
vector? A malicious guest executing an operation with a bad IOCSR length
can trigger this path in kvm_complete_iocsr_read().
If the host system is configured with panic_on_warn=1, this allows an
untrusted guest to crash the host. Could this be changed to pr_warn_once()
or pr_err_ratelimited() instead to reduce the log spam without the risk
of a kernel panic?
[ ... ]
> diff --git a/arch/loongarch/kvm/intc/dmsintc.c b/arch/loongarch/kvm/intc/dmsintc.c
> --- a/arch/loongarch/kvm/intc/dmsintc.c
> +++ b/arch/loongarch/kvm/intc/dmsintc.c
> @@ -114,7 +114,7 @@ static int kvm_dmsintc_ctrl_access(struct kvm_device *dev,
> }
> break;
> default:
> - kvm_err("%s: unknown dmsintc register, addr = %d\n", __func__, addr);
> + WARN_ONCE(1, "%s: unknown dmsintc register, addr = %d\n", __func__, addr);
[Severity: Critical]
Similarly here, can a host userspace process trigger this WARN_ONCE by
passing an invalid address to KVM_SET_DEVICE_ATTR for the dmsintc device?
This would allow an unprivileged host userspace process to crash the host
if panic_on_warn=1 is set.
[ ... ]
> diff --git a/arch/loongarch/kvm/vcpu.c b/arch/loongarch/kvm/vcpu.c
> --- a/arch/loongarch/kvm/vcpu.c
> +++ b/arch/loongarch/kvm/vcpu.c
> @@ -1473,7 +1473,7 @@ int kvm_vcpu_ioctl_interrupt(struct kvm_vcpu *vcpu, struct kvm_interrupt *irq)
> else if (intr < 0)
> kvm_dequeue_irq(vcpu, -intr);
> else {
> - kvm_err("%s: invalid interrupt ioctl %d\n", __func__, irq->irq);
> + WARN_ONCE(1, "%s: invalid interrupt ioctl %d\n", __func__, irq->irq);
[Severity: Critical]
Does this also allow unprivileged userspace to trigger a warning via a
bad interrupt ioctl parameter?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260629023213.597030-1-maobibo@loongson.cn?part=2
next prev parent reply other threads:[~2026-06-29 2:37 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-29 2:32 [PATCH v3 0/3] LoongArch: KVM: Harden interrupt injection Bibo Mao
2026-06-29 2:32 ` [PATCH v3 1/3] LoongArch: KVM: Set default MAILBOX access size with 8 Bibo Mao
2026-06-29 2:45 ` sashiko-bot
2026-06-29 2:32 ` [PATCH v3 2/3] LoongArch: KVM: Replace kvm_err() with WARN_ONCE() Bibo Mao
2026-06-29 2:37 ` sashiko-bot [this message]
2026-06-30 4:27 ` Huacai Chen
2026-06-29 2:32 ` [PATCH v3 3/3] LoongArch: KVM: Use internal API to deliver interrupt in kernel mode Bibo Mao
2026-06-29 2:41 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260629023727.428171F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=maobibo@loongson.cn \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox