Re: [PATCH v19 09/18] vfio/pci: Hide TPH capability when TPH is unsupported

[fengchengwen <fengchengwen@huawei.com>]

On 7/2/2026 9:00 PM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] Hiding the TPH capability by returning a length of 0 unintentionally grants the guest raw read/write access to the physical TPH registers.

After checking the full vfio_ecap_init logic, this is a false positive risk
report.

When vfio_ext_cap_len() returns 0 for unsupported TPH ecap, the !len branch
takes over:
1. It allocates minimal PCI_CAP_SIZEOF length and marks hidden=true;
2. memset(map + epos, PCI_EXT_CAP_ID_TPH, len) populates pci_config_map,
   so these offsets are never marked PCI_CAP_ID_INVALID;
3. Accesses to TPH range hit the dedicated TPH ecap permission table
   with vfio_tph_config_write handler which discards all writes,
   never falling back to unassigned_perms raw physical write.

The hidden flag erases the capability ID in virtual config space so guests
cannot enumerate TPH, while full permission isolation is retained for all
config offsets of this ecap. No raw hardware bypass vulnerability exists
with current implementation.

Thanks

> --
> 
> commit 1d6f16c85a6a295f7dee447fc8d7ac56c232977a
> Author: Chengwen Feng <fengchengwen@huawei.com>
> 
> vfio/pci: Hide TPH capability when TPH is unsupported
> 
> Check the device negotiated TPH support status before parsing the TPH
> extended capability. Return zero length to hide the capability from
> userspace if TPH is disabled during topology negotiation.
> 
>> diff --git a/drivers/vfio/pci/vfio_pci_config.c b/drivers/vfio/pci/vfio_pci_config.c
>> index a10ed733f0e3a..5c6ab172df6c0 100644
>> --- a/drivers/vfio/pci/vfio_pci_config.c
>> +++ b/drivers/vfio/pci/vfio_pci_config.c
> [ ... ]
>> @@ -1450,6 +1451,8 @@ static int vfio_ext_cap_len(struct vfio_pci_core_device *vdev, u16 ecap, u16 epo
>>  		byte &= PCI_DPA_CAP_SUBSTATE_MASK;
>>  		return PCI_DPA_BASE_SIZEOF + byte + 1;
>>  	case PCI_EXT_CAP_ID_TPH:
>> +		if (!pcie_tph_supported(pdev, false))
>> +			return 0;
> 
> [Severity: High]
> Does hiding the capability by returning 0 here inadvertently grant the guest
> raw read/write access to the physical TPH registers?
> 
> When a length of 0 is returned in vfio_ext_cap_len(), the VFIO capability
> parsing loop skips mapping the capability. This leaves the physical offsets
> marked as PCI_CAP_ID_INVALID in vdev->pci_config_map.
> 
> Guest accesses to unmapped offsets fall back to unassigned_perms:
> 
> static struct perm_bits unassigned_perms = {
> 	.readfn = vfio_raw_config_read,
> 	.writefn = vfio_raw_config_write
> };
> 
> This allows a guest to perform raw writes directly to the physical device
> using vfio_raw_config_write(), bypassing VFIO isolation.
> 
> Could a malicious guest use this raw access to manually enable TPH and
> configure Steering Tags to steer DMA to arbitrary CPU caches?
> 
>>  		ret = pci_read_config_dword(pdev, epos + PCI_TPH_CAP, &dword);
>>  		if (ret)
>>  			return pcibios_err_to_errno(ret);
>