Re: [PATCH v4 14/22] PCI/CMA: Validate Subject Alternative Name in certificates

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] pci: case-sensitive SAN validation rejects uppercase hexadecimal device identities
- [High] pci: ASN.1 decoder aborts prematurely on certificates with multiple CMA SANs
--

commit 8216d5120f9a26d7f0a6ec14495fd951b1a7513d
Author: Lukas Wunner <lukas@wunner.de>

PCI/CMA: Validate Subject Alternative Name in certificates

This patch introduces validation for the Subject Alternative Name (SAN) in PCIe
leaf certificates per PCIe r6.1 specifications. It uses an ASN.1 decoder module
to parse and authenticate the identity encoding within the certificate's SAN
against the device's actual configuration space.

> diff --git a/drivers/pci/cma.c b/drivers/pci/cma.c
> index 6b52b129574ec..6e4eb3b921131 100644
> --- a/drivers/pci/cma.c
> +++ b/drivers/pci/cma.c

[ ... ]

> +int pci_cma_note_san(void *context, size_t hdrlen, unsigned char tag,
> +		     const void *value, size_t vlen)
> +{
> +	struct pci_cma_x509_context *ctx = context;
> +
> +	/* These aren't the drOIDs we're looking for. */
> +	if (ctx->last_oid != OID_CMA)
> +		return 0;
> +
> +	if (tag != ASN1_UTF8STR ||
> +	    vlen != ctx->expected_len ||
> +	    memcmp(value, ctx->expected_name, vlen) != 0) {

[Severity: High]
Will this strict memcmp() in pci_cma_note_san() fail if a device presents
a compliant SAN string using uppercase hexadecimal characters?

> +		pci_err(ctx->pdev, "Leaf certificate of slot %u "
> +			"has invalid Subject Alternative Name\n", ctx->slot);
> +		return -EINVAL;

[Severity: High]
Could returning -EINVAL here prematurely abort the ASN.1 decoding sequence
for certificates with multiple CMA SANs?

If a multi-function device shares a single leaf certificate containing
multiple Subject Alternative Name entries, aborting on the first mismatch
prevents the decoder from checking subsequent SANs that might legitimately
match the current PCIe function.

> +	}
> +
> +	ctx->found = true;
> +
> +	return 0;
> +}

[ ... ]

> +static unsigned int pci_cma_construct_san(struct pci_dev *pdev, char *name)
> +{
> +	unsigned int len;
> +	u64 serial;
> +
> +	len = scnprintf(name, CMA_NAME_MAX,
> +			"Vendor=%04hx:Device=%04hx:CC=%06x:REV=%02hhx",
> +			pdev->vendor, pdev->device, pdev->class, pdev->revision);

[Severity: High]
Is it possible that using lowercase formatting (%04hx) here inadvertently
causes the validation in pci_cma_note_san() to reject valid certificates
that encode their identity using uppercase hexadecimal characters?

> +
> +	if (pdev->hdr_type == PCI_HEADER_TYPE_NORMAL)
> +		len += scnprintf(name + len, CMA_NAME_MAX - len,
> +				 ":SSVID=%04hx:SSID=%04hx",
> +				 pdev->subsystem_vendor, pdev->subsystem_device);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260928011123.450800-1-alistair.francis@wdc.com?part=14