Re: [PATCH v20 08/16] PCI/TPH: Refactor pcie_tph_get_cpu_st & add requester variant

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Missing length check for ACPI buffer in tph_invoke_dsm() leads to a heap out-of-bounds read.
--

--- Patch [8]: [PATCH v20 08/16] PCI/TPH: Refactor pcie_tph_get_cpu_st & add requester variant ---
commit a4213c1c2a9777e1dab404b096c528682a773636
Author: Chengwen Feng <fengchengwen@huawei.com>

PCI/TPH: Refactor pcie_tph_get_cpu_st & add requester variant

This commit refactors pcie_tph_get_cpu_st() into a compatibility wrapper
and introduces pcie_tph_get_cpu_st_ext() to allow explicit TPH requester
type selection. It also adds validation for the requester type against
hardware negotiated capabilities.

> diff --git a/drivers/pci/tph.c b/drivers/pci/tph.c
> --- a/drivers/pci/tph.c
> +++ b/drivers/pci/tph.c

[ ... ]

> @@ -313,17 +319,38 @@ int pcie_tph_get_cpu_st(struct pci_dev *pdev, enum tph_mem_type mem_type,
>  		return -EINVAL;
>  	}
>  
> -	*tag = tph_extract_tag(mem_type, pdev->tph_req_type, &info);
> +	*tag = tph_extract_tag(mem_type, req_type, &info);

[Severity: High]
This is a pre-existing issue, but while reviewing this code I noticed a
potential out-of-bounds read in tph_invoke_dsm() when it populates the
info union.

When tph_invoke_dsm() evaluates the ACPI _DSM method, it verifies the return
type is a buffer, but it doesn't verify the buffer length before casting the
pointer to a 64-bit integer and dereferencing it:

drivers/pci/tph.c:tph_invoke_dsm() {
    ...
    if (out_obj->type != ACPI_TYPE_BUFFER) {
        ACPI_FREE(out_obj);
        return AE_ERROR;
    }

    st_out->value = *((u64 *)(out_obj->buffer.pointer));
    ...
}

Could this cause a heap out-of-bounds read if buggy ACPI firmware provides a
buffer that is smaller than 8 bytes?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260714104325.54444-1-fengchengwen@huawei.com?part=8