[PATCH] usb: typec: ucsi: acpi: Check ACPI companion before use

[PATCH] usb: typec: ucsi: acpi: Check ACPI companion before use

[Jiale Yao]

Platform drivers can be forced to bind to devices outside their match
tables through driver_override. ucsi_acpi_probe() assumes that every bound
device has an ACPI companion and accesses adev->dep_unmet without checking.

Return -ENODEV when the companion is absent to avoid a NULL pointer
dereference.

Signed-off-by: Jiale Yao <yaojiale02@163.com>
---
 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 5697ccc24ec3..e8e3205cab9b 100644
--- a/drivers/usb/typec/ucsi/ucsi_acpi.c
+++ b/drivers/usb/typec/ucsi/ucsi_acpi.c
@@ -222,14 +222,18 @@ 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);
 	const struct ucsi_operations *ops = &ucsi_acpi_ops;
 	const struct dmi_system_id *id;
+	struct acpi_device *adev;
 	struct ucsi_acpi *ua;
 	struct resource *res;
 	acpi_status status;
 	int ret;
 
+	adev = ACPI_COMPANION(&pdev->dev);
+	if (!adev)
+		return -ENODEV;
+
 	if (adev->dep_unmet)
 		return -EPROBE_DEFER;
 
-- 
2.34.1

Re:[PATCH] usb: typec: ucsi: acpi: Check ACPI companion before use

[jiale yao]

At 2026-10-17 14:43:21, "Jiale Yao" <yaojiale02@163.com> wrote:
>Platform drivers can be forced to bind to devices outside their match
>tables through driver_override. ucsi_acpi_probe() assumes that every bound
>device has an ACPI companion and accesses adev->dep_unmet without checking.
>
>Return -ENODEV when the companion is absent to avoid a NULL pointer
>dereference.
>

Fixes: 1f3546ff3f0a ("usb: typec: ucsi: acpi: Check the _DEP dependencies")

>Signed-off-by: Jiale Yao <yaojiale02@163.com>
>---
> 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 5697ccc24ec3..e8e3205cab9b 100644
>--- a/drivers/usb/typec/ucsi/ucsi_acpi.c
>+++ b/drivers/usb/typec/ucsi/ucsi_acpi.c
>@@ -222,14 +222,18 @@ 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);
> 	const struct ucsi_operations *ops = &ucsi_acpi_ops;
> 	const struct dmi_system_id *id;
>+	struct acpi_device *adev;
> 	struct ucsi_acpi *ua;
> 	struct resource *res;
> 	acpi_status status;
> 	int ret;
> 
>+	adev = ACPI_COMPANION(&pdev->dev);
>+	if (!adev)
>+		return -ENODEV;
>+
> 	if (adev->dep_unmet)
> 		return -EPROBE_DEFER;
> 
>-- 
>2.34.1

Re: [PATCH] usb: typec: ucsi: acpi: Check ACPI companion before use

[Huang Wei]

Hi Jiale,

A heads-up on the history here: a functionally identical patch was
posted in September by Yogesh Gaur:

  https://lore.kernel.org/linux-usb/20260920090711.300-1-yogeshgaur.83@gmail.com/

Greg declined it on the grounds that the only realistic way to reach
probe without an ACPI companion is the driver_override + sysfs bind
path, which is a deliberate root action, with the resulting OOPS
being identifiable by the taint flag - "if userspace does it, it
deserves the pieces the kernel ends up in":

  https://lore.kernel.org/linux-usb/2026092130-thong-secrecy-1dd4@gregkh/

The open question left from that thread was whether syzbot still
exercises the override+bind path - if it does and keeps generating
these reports, that would be an argument for taking the guard anyway.
Yogesh's version referenced a syzbot report; yours does not, so I
can't tell from the patch whether you hit the same report or found
this independently.

For what it's worth, the fix itself is fine - I reviewed Yogesh's
version at the time, including checking that this is the only
unchecked ACPI_COMPANION() in drivers/usb/typec/. Whether it lands
is purely a policy call at this point.

Thanks,
Huang Wei

Re:Re: [PATCH] usb: typec: ucsi: acpi: Check ACPI companion before use

[jiale yao]

Hi Huang,

At 2026-10-20 10:27:07, "Huang Wei" <huangwei@kylinos.cn> wrote:
>Hi Jiale,
>
>A heads-up on the history here: a functionally identical patch was
>posted in September by Yogesh Gaur:
>
>  https://lore.kernel.org/linux-usb/20260920090711.300-1-yogeshgaur.83@gmail.com/
>
>Greg declined it on the grounds that the only realistic way to reach
>probe without an ACPI companion is the driver_override + sysfs bind
>path, which is a deliberate root action, with the resulting OOPS
>being identifiable by the taint flag - "if userspace does it, it
>deserves the pieces the kernel ends up in":
>
>  https://lore.kernel.org/linux-usb/2026092130-thong-secrecy-1dd4@gregkh/
>
>The open question left from that thread was whether syzbot still
>exercises the override+bind path - if it does and keeps generating
>these reports, that would be an argument for taking the guard anyway.
>Yogesh's version referenced a syzbot report; yours does not, so I
>can't tell from the patch whether you hit the same report or found
>this independently.

Thanks for your reply.
The bug was found by my static analysis tool, which is currently under development.

>
>For what it's worth, the fix itself is fine - I reviewed Yogesh's
>version at the time, including checking that this is the only
>unchecked ACPI_COMPANION() in drivers/usb/typec/. Whether it lands
>is purely a policy call at this point.
>
>Thanks,
>Huang Wei

Jiale

Re: Re: [PATCH] usb: typec: ucsi: acpi: Check ACPI companion before use

[Greg Kroah-Hartman]

On Tue, Oct 20, 2026 at 10:31:58AM +0800, jiale yao wrote:
> Hi Huang,
> 
> At 2026-10-20 10:27:07, "Huang Wei" <huangwei@kylinos.cn> wrote:
> >Hi Jiale,
> >
> >A heads-up on the history here: a functionally identical patch was
> >posted in September by Yogesh Gaur:
> >
> >  https://lore.kernel.org/linux-usb/20260920090711.300-1-yogeshgaur.83@gmail.com/
> >
> >Greg declined it on the grounds that the only realistic way to reach
> >probe without an ACPI companion is the driver_override + sysfs bind
> >path, which is a deliberate root action, with the resulting OOPS
> >being identifiable by the taint flag - "if userspace does it, it
> >deserves the pieces the kernel ends up in":
> >
> >  https://lore.kernel.org/linux-usb/2026092130-thong-secrecy-1dd4@gregkh/
> >
> >The open question left from that thread was whether syzbot still
> >exercises the override+bind path - if it does and keeps generating
> >these reports, that would be an argument for taking the guard anyway.
> >Yogesh's version referenced a syzbot report; yours does not, so I
> >can't tell from the patch whether you hit the same report or found
> >this independently.
> 
> Thanks for your reply.
> The bug was found by my static analysis tool, which is currently under development.

And how does that tool reach this patch without hitting the "the kernel
is now tainted because the user did something wrong" setting?

thanks,

greg k-h