Re: [PATCH v2] usb: typec: ucsi: Add ACPI_COMPANION() NULL check in ucsi_acpi_probe

From: luoxueqin

Date: Wed Aug 12 2026 - 23:26:29 EST


Hi Heikki,

Thanks for the review.

However, I'd like to point out that this exact issue has been recognized
as a security vulnerability (CVE-2026-64227), and Rafael already applied
the same fix pattern to 14 ACPI platform drivers in commit e4865a56d013
("ACPI: driver: Check ACPI_COMPANION() against NULL during probe"), which
is marked for stable backport.

The NULL pointer dereference triggers a kernel oops/panic - a full system
crash - not just a silent failure. Returning -ENODEV is the correct and
graceful behavior, consistent with all other drivers fixed in that commit.

Could you please reconsider?

Best regards,
Xueqin Luo

在 2026/8/12 17:37, Heikki Krogerus 写道:
On Tue, Aug 11, 2026 at 05:58:27PM +0800, Xueqin Luo wrote:
Add NULL check for ACPI_COMPANION() in ucsi_acpi_probe() to prevent
NULL pointer dereference when driver_override matches a device without
ACPI companion.

Since every platform driver can be forced to match a device that doesn't
match its list of device IDs because of device_match_driver_override(),
the ACPI_COMPANION() may return NULL, leading to a NULL pointer
dereference at adev->dep_unmet.

Test steps:

$ sudo modprobe ucsi_acpi
$ echo ucsi_acpi | sudo tee /sys/bus/platform/devices/alarmtimer.0.auto/driver_override
$ echo alarmtimer.0.auto | sudo tee /sys/bus/platform/drivers/alarmtimer/unbind
$ echo alarmtimer.0.auto | sudo tee /sys/bus/platform/drivers/ucsi_acpi/bind

which triggered the following crash:

[ 6599.180948] calling ucsi_acpi_platform_driver_init+0x0/0xff0 [ucsi_acpi] @ 24208
[ 6599.181198] initcall ucsi_acpi_platform_driver_init+0x0/0xff0 [ucsi_acpi] returned 0 after 207 usecs
[ 6729.051074] BUG: kernel NULL pointer dereference, address: 00000000000005f4
[ 6729.051102] #PF: supervisor read access in kernel mode
[ 6729.051113] #PF: error_code(0x0000) - not-present page
[ 6729.051122] PGD 0 P4D 0
[ 6729.051136] Oops: 0000 [#1] PREEMPT SMP NOPTI
....
[ 6729.051300] PKRU: 55555554
[ 6729.051306] Call Trace:
[ 6729.051314] <TASK>
[ 6729.051327] platform_probe+0x41/0xa0
[ 6729.051348] really_probe+0x1a9/0x410
[ 6729.051364] __driver_probe_device+0xc9/0x170
[ 6729.051377] device_driver_attach+0x46/0xb0
[ 6729.051390] bind_store+0x77/0xd0
I don't think kernel can protect the user from everything. I would
rather keep the NULL pointer dereference than silently fail in this
kind of cases.

Note that you can use the driver_override like that also with a device
(not UCSI) that does have the ACPI device node. In that case the probe
would just continue pass the condition you are introducing below.

Thanks,

Fixes: 1f3546ff3f0a ("usb: typec: ucsi: acpi: Check the _DEP dependencies")
Signed-off-by: Xueqin Luo <luoxueqin@xxxxxxxxxx>
Cc: stable@xxxxxxxxxxxxxxx
---
drivers/usb/typec/ucsi/ucsi_acpi.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/typec/ucsi/ucsi_acpi.c b/drivers/usb/typec/ucsi/ucsi_acpi.c
index 18286d3e9cc5..b4a783217dc6 100644
--- a/drivers/usb/typec/ucsi/ucsi_acpi.c
+++ b/drivers/usb/typec/ucsi/ucsi_acpi.c
@@ -188,7 +188,7 @@ static void ucsi_acpi_notify(acpi_handle handle, u32 event, void *data)
static int ucsi_acpi_probe(struct platform_device *pdev)
{
- struct acpi_device *adev = ACPI_COMPANION(&pdev->dev);
+ struct acpi_device *adev;
const struct ucsi_operations *ops = &ucsi_acpi_ops;
const struct dmi_system_id *id;
struct ucsi_acpi *ua;
@@ -196,6 +196,10 @@ static int ucsi_acpi_probe(struct platform_device *pdev)
acpi_status status;
int ret;
+ adev = ACPI_COMPANION(&pdev->dev);
+ if (!adev)
+ return -ENODEV;
+
if (adev->dep_unmet)
return -EPROBE_DEFER;
--
2.43.0