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

[luoxueqin <luoxueqin@kylinos.cn>]

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@kylinos.cn>
>> Cc: stable@vger.kernel.org
>> ---
>>   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