From: sashiko-bot@kernel.org
To: "Longfang Liu" <liulongfang@huawei.com>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH v4 1/2] hisi_acc_vfio_pci: fix NULL dereference in reset_prepare on PF passthrough
Date: Fri, 18 Sep 2026 08:57:35 +0000 [thread overview]
Message-ID: <20260918085735.A40551F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260918084244.1485837-2-liulongfang@huawei.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] vfio/hisilicon: unprivileged userspace can spam kernel log via VFIO_DEVICE_RESET
--
commit 232c524b0aed2e92588a217b15d2d609373f3ea0
Author: Longfang Liu <liulongfang@huawei.com>
hisi_acc_vfio_pci: fix NULL dereference in reset_prepare on PF passthrough
This commit fixes a NULL pointer dereference in the PCI error handler by
checking for migration support at the entry of reset_prepare() and
aer_reset_done(). It also properly clears the set_reset_flag in
aer_reset_done() and updates the VF checking logic in the probe function.
> diff --git a/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c b/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c
> index 86362ec424a50..8ff69c8d1ff71 100644
> --- a/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c
> +++ b/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c
> @@ -1154,9 +1154,14 @@ static void hisi_acc_vf_pci_reset_prepare(struct pci_dev *pdev)
> {
> struct hisi_acc_vf_core_device *hisi_acc_vdev = hisi_acc_drvdata(pdev);
> struct hisi_qm *qm = hisi_acc_vdev->pf_qm;
> - struct device *dev = &qm->pdev->dev;
> + struct device *dev = &pdev->dev;
> u32 delay = 0;
>
> + if (!hisi_acc_vdev->core_device.vdev.mig_ops) {
> + dev_err(dev, "device not support migration\n");
[Severity: Medium]
Could this dev_err() be used by an unprivileged user or guest VM to spam the
kernel log?
Since a non-migratable VFIO device (like a PF or older VF) is a valid state,
an unprivileged user repeatedly invoking the VFIO_DEVICE_RESET ioctl might
trigger this path continuously through pci_reset_function().
Should this be changed to a debug log, be rate-limited, or return silently
to prevent potential denial of service via dmesg flooding?
> + return;
> + }
> +
> /* All reset requests need to be queued for processing */
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260918084244.1485837-1-liulongfang@huawei.com?part=1
next prev parent reply other threads:[~2026-09-18 8:57 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-18 8:42 [PATCH v4 0/2] fix two issues in hisi_acc_vfio_pci driver Longfang Liu
2026-09-18 8:42 ` [PATCH v4 1/2] hisi_acc_vfio_pci: fix NULL dereference in reset_prepare on PF passthrough Longfang Liu
2026-09-18 8:57 ` sashiko-bot [this message]
2026-09-20 9:10 ` liulongfang
2026-09-20 14:26 ` Alex Williamson
2026-09-21 8:15 ` liulongfang
2026-09-22 22:59 ` Alex Williamson
2026-09-23 6:45 ` liulongfang
2026-09-18 8:42 ` [PATCH v4 2/2] hisi_acc_vfio_pci: reject live migration on 64KB page with QM_HW_V3 hardware Longfang Liu
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=20260918085735.A40551F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=liulongfang@huawei.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.