drivers/crypto/ccp/sp-pci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
psp_firmware_is_visible() decides whether to publish tee_version by
testing the TEE capability bit reported by the hardware, and then reads
through the driver's own tee vdata pointer without checking it:
if (attr == &dev_attr_tee_version.attr && psp->capability.tee &&
psp->vdata->tee->info_reg)
The capability register describes the silicon. The vdata describes what
this driver was given to drive it with. The two can disagree: any device
whose firmware sets the TEE capability bit while its psp_vdata carries no
tee data dereferences NULL here. The attribute group is registered from
probe, so the result is an oops during module init:
RIP: 0010:psp_firmware_is_visible+0x6c/0x80 [ccp]
? __pfx_init_module+0x10/0x10 [ccp]
sp_mod_init+0x1a/0xff0 [ccp]
This was hit on an AMD BC-250, whose PSP capability register at 0x109fc
reads 0x00000002 and so advertises a TEE that the board has no working
ring for.
Check the pointer before following it.
Fixes: 2e424c33d8e7 ("crypto: ccp - Add support for displaying PSP firmware versions")
Signed-off-by: Mattia Tadini <info@mtsistemi.it>
---
drivers/crypto/ccp/sp-pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/ccp/sp-pci.c b/drivers/crypto/ccp/sp-pci.c
index ede6ff9..f79df33 100644
--- a/drivers/crypto/ccp/sp-pci.c
+++ b/drivers/crypto/ccp/sp-pci.c
@@ -80,7 +80,7 @@ static umode_t psp_firmware_is_visible(struct kobject *kobj, struct attribute *a
val = ioread32(psp->io_regs + psp->vdata->bootloader_info_reg);
if (attr == &dev_attr_tee_version.attr && psp->capability.tee &&
- psp->vdata->tee->info_reg)
+ psp->vdata->tee && psp->vdata->tee->info_reg)
val = ioread32(psp->io_regs + psp->vdata->tee->info_reg);
/* If platform disallows accessing this register it will be all f's */
--
2.55.0
The cover letter for this series did not reach the list: the three
patches are in the archive, [PATCH 0/3] is not, and no bounce came back. Resent
here so the series context is in the thread rather than nowhere.
The AMD BC-250 is a Zen 2 APU board (Cyan Skillfish) sold as surplus mining
hardware and now used as a small desktop by a fair number of people. It carries
an AMD Secure Processor at PCI 1022:143e that sp_pci_table[] does not match, so
the device has always been left unbound with its memory windows disabled.
Adding the ID turned out to need two fixes first, both of the same shape: the
driver decides what to bring up from the hardware capability register alone,
and then uses the psp_vdata pointers for those features without checking that
this device has them. On this board the two disagree, because the firmware
advertises a TEE whose ring never comes up.
Patch 1 is a NULL pointer dereference in the sysfs is_visible callback. It
oopses during probe. It needs no new hardware to be reachable in principle:
any device whose firmware sets the TEE capability bit while its psp_vdata
carries no tee data hits it, which today means pspv1 and pspv2 parts. I have
only observed it on the BC-250, so I have not added a stable tag - please add
one if you think it deserves it.
Patch 2 stops a failed optional sub-device from taking down the rest of the
PSP. Without it, a psp_vdata that deliberately omits TEE gets nothing at all,
platform access included.
Patch 3 adds the board. The register layout was read off the device rather
than assumed, and the numbers are in the commit message.
Tested on a BC-250 running 7.2.6. Before:
01:00.2 Encryption controller: AMD Device 143e
Memory at fe700000 [disabled] [size=1M]
Memory at fe884000 [disabled] [size=8K]
(no driver)
After:
ccp 0000:01:00.2: enabling device (0000 -> 0002)
ccp 0000:01:00.2: platform access enabled
ccp 0000:01:00.2: psp enabled
# cat /sys/bus/pci/devices/0000:01:00.2/bootloader_version
00.1c.01.02
with the platform mailbox answering commands. Dynamic boost control is probed
and cleanly rejected by this firmware, and HSTI reports nothing because the
security reporting capability bit is clear. There is no CCP crypto engine
behind this function: the version register at 0x100 reads back all ones.
The series is against v7.2.6 and touches only drivers/crypto/ccp/.
Mattia Tadini (3):
crypto: ccp - fix NULL dereference in psp_firmware_is_visible()
crypto: ccp - do not start PSP sub-devices without their vdata
crypto: ccp - add support for the AMD BC-250 secure processor
drivers/crypto/ccp/psp-dev.c | 8 ++++++--
drivers/crypto/ccp/sp-pci.c | 24 +++++++++++++++++++++++-
2 files changed, 29 insertions(+), 3 deletions(-)
--
2.55.0
© 2016 - 2026 Red Hat, Inc.