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

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

[Xueqin Luo]

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

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

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

[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

-- 
heikki

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

[luoxueqin]

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

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

[Greg KH]

On Thu, Aug 13, 2026 at 11:25:55AM +0800, luoxueqin wrote:
> 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.

Yes, but it requires root to cause this crash, right?  Which probably
means that other CVE should be rejected?

As this is a manual bind command, if that ever breaks, you get to keep
the pieces.  We don't "defend" for that in the kernel.

thanks,

greg k-h