Re: [PATCH RFC 1/3] vfio/pci: Virtualize and scrub Device Serial Number from guests

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Missing bounds check in `vfio_ecap_init()` and `vfio_cap_init()` allows malformed PCI capabilities to cause out-of-bounds memory accesses.
--

commit b6096a89941aa7c7c7c1394233c57ed4b01c16d6
Author: Pranjal Arya <pranjal.arya@oss.qualcomm.com>

vfio/pci: Virtualize and scrub Device Serial Number from guests

This commit virtualizes the PCIe Device Serial Number (DSN) capability in
vfio-pci to prevent guests from reading the persistent hardware serial number.
It adds a permission bits initializer for DSN and zeros out the serial number
in the virtualized config space during capability initialization.

> diff --git a/drivers/vfio/pci/vfio_pci_config.c b/drivers/vfio/pci/vfio_pci_config.c
> index a10ed733f0e3a..24dfeb43cb714 100644
> --- a/drivers/vfio/pci/vfio_pci_config.c
> +++ b/drivers/vfio/pci/vfio_pci_config.c

[ ... ]

> @@ -1702,6 +1729,18 @@ static int vfio_ecap_init(struct vfio_pci_core_device *vdev)
>  		if (ret)
>  			return ret;
>  
> +		/*
> +		 * Scrub the physical Device Serial Number from the
> +		 * virtualized config space so the guest cannot read the
> +		 * host device's unique identifier.  The capability is fully
> +		 * virtualized (see init_pci_ext_cap_dsn_perm()), so reads
> +		 * return this scrubbed value rather than hardware.  The user
> +		 * can present a chosen serial via VFIO_DEVICE_FEATURE_PCI_DSN.
> +		 */
> +		if (ecap == PCI_EXT_CAP_ID_DSN)
> +			memset(&vdev->vconfig[epos + PCI_DSN_LOW_DW], 0,
> +			       sizeof(__le64));

[Severity: High]
This is a pre-existing issue, but does this loop need to verify that the
capability length fits within the config space buffer before writing?

Looking at vfio_ecap_init(), the loop iterates using the hardware-provided
capability pointer (epos). If a device presents a DSN capability (which has
a length of 12) at an offset near the end of the config space (for example,
if epos is 4092 for a 4096-byte PCIe config space), the capability would
extend beyond pdev->cfg_size.

Since vconfig and map are dynamically allocated based on pdev->cfg_size,
would the newly added memset() write out-of-bounds into the kernel heap?

This new memset() shares the same lack of bounds checking as the existing
unconditional capability writes in vfio_ecap_init():

	memset(map + epos, ecap, len);

and similarly in vfio_cap_init():

	memset(map + pos, cap, len);

Could a malicious physical PCI device or compromised VF supply a crafted
capability list to exploit this?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260613-pcie_vfio-v1-0-09168188f3f2@oss.qualcomm.com?part=1