[PATCH] usb: typec: ucsi: acpi: don't dereference a missing ACPI companion

[PATCH] usb: typec: ucsi: acpi: don't dereference a missing ACPI companion

[Yogesh Gaur]

ucsi_acpi_probe() reads adev->dep_unmet before it has established that
the platform device has an ACPI companion at all:

	struct acpi_device *adev = ACPI_COMPANION(&pdev->dev);
	...
	if (adev->dep_unmet)
		return -EPROBE_DEFER;

ACPI_COMPANION() returns NULL for a platform device that was not
enumerated from an ACPI node. The driver only advertises an
acpi_match_table, so the bus-match path cannot reach the probe with a
NULL companion -- but the probe is also reachable from sysfs, and that
path does not consult a match table. Writing a device name to
/sys/bus/platform/drivers/ucsi_acpi/bind goes straight to
device_driver_attach() -> really_probe(), so any platform device in the
system can be handed to ucsi_acpi_probe(), including the many that have
no ACPI companion:

  Oops: general protection fault, probably for non-canonical address
        0xdffffc00000000fc: 0000 [#1] SMP KASAN PTI
  KASAN: null-ptr-deref in range [0x00000000000007e0-0x00000000000007e7]
  RIP: 0010:ucsi_acpi_probe+0x6c/0x4b0 drivers/usb/typec/ucsi/ucsi_acpi.c:199
  Call Trace:
   platform_probe+0xf9/0x190 drivers/base/platform.c:1507
   really_probe+0x254/0xae0 drivers/base/dd.c:706
   __driver_probe_device+0x1e8/0x360 drivers/base/dd.c:868
   device_driver_attach+0xe0/0x1d0 drivers/base/dd.c:1203
   bind_store+0x1d3/0x220 drivers/base/bus.c:267
   kernfs_fop_write_iter+0x3a5/0x540 fs/kernfs/file.c:345
   vfs_write+0x61e/0xbb0 fs/read_write.c:687

The faulting address is the dep_unmet member read off a NULL
struct acpi_device.

Bail out with -ENODEV when there is no companion. Every other use of
the device in this probe goes through ACPI_HANDLE(), which tolerates a
missing companion and would just have failed later with a less useful
error, so rejecting the bind up front is both the smallest fix and the
honest answer: this driver cannot drive a non-ACPI device.

This is the only unchecked ACPI_COMPANION() in drivers/usb/typec/.

Fixes: 1f3546ff3f0a ("usb: typec: ucsi: acpi: Check the _DEP dependencies")
Reported-by: syzbot+e7aa19176573a6992617@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=e7aa19176573a6992617
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: Yogesh Gaur <yogeshgaur.83@gmail.com>
---
 drivers/usb/typec/ucsi/ucsi_acpi.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/typec/ucsi/ucsi_acpi.c b/drivers/usb/typec/ucsi/ucsi_acpi.c
index 18286d3e9cc5..9fe4ba43afea 100644
--- a/drivers/usb/typec/ucsi/ucsi_acpi.c
+++ b/drivers/usb/typec/ucsi/ucsi_acpi.c
@@ -196,6 +196,9 @@ static int ucsi_acpi_probe(struct platform_device *pdev)
 	acpi_status status;
 	int ret;
 
+	if (!adev)
+		return -ENODEV;
+
 	if (adev->dep_unmet)
 		return -EPROBE_DEFER;
 
-- 
2.55.0.windows.5

Re: [PATCH] usb: typec: ucsi: acpi: don't dereference a missing ACPI companion

[Huang Wei]

Hi Yogesh,

I checked this over. The fix is correct - the sysfs bind path can
indeed hand a non-ACPI platform device to ucsi_acpi_probe(), and
adev->dep_unmet is the first dereference.

I also went and checked the "only unchecked ACPI_COMPANION() in
drivers/usb/typec" claim. port-mapper.c looked like a second candidate
at first glance, but typec_link_ports() bails out early when the port
has no ACPI companion, so typec_port_match() never runs with
con_adev == NULL. The claim holds.

Fixes: 1f3546ff3f0a is also the right one for the stable backport -
that commit added the dep_unmet check back in 2020, so the deref has
been there a while.

Reviewed-by: Huang Wei <huangwei@kylinos.cn>

Thanks,
Huang Wei

Re: [PATCH] usb: typec: ucsi: acpi: don't dereference a missing ACPI companion

[Greg Kroah-Hartman]

On Mon, Sep 21, 2026 at 11:03:46AM +0800, Huang Wei wrote:
> Hi Yogesh,
> 
> I checked this over. The fix is correct - the sysfs bind path can
> indeed hand a non-ACPI platform device to ucsi_acpi_probe(), and
> adev->dep_unmet is the first dereference.

And that's the problem, don't do that.  Seriously, if userspace does it,
it deserves the pieces the kernel ends up in.  This isn't a kernel
issue, it's a userspace "do not do this" issue.

There is now a taint flag that gets set if userspace tries to do this,
showing us all what is really going on, so we can ignore reports like
this.  Also syzbot now should not be attempting foolish things like
this.

thanks,

greg k-h

Re: [PATCH] usb: typec: ucsi: acpi: don't dereference a missing ACPI companion

[Huang Wei]

Hi Greg,

Fair enough - my Reviewed-by was about the fix being technically
correct, not about whether we want it, and it takes a driver_override
write plus the bind to get there, which is a fairly deliberate root
action.

The one question I'd leave open is the syzbot noise - this report came
in recently, so if the fuzzer is still exercising the override+bind
path there will likely be more of these. If those reports can be
identified and closed as noise, the patch is indeed solving a
non-problem.

Yogesh, either way the analysis in your patch was solid - the bind
path research was right on.

Thanks,
Huang Wei