[PATCH] usb: typec: tipd: fix uninitialized typec_partner_desc on stack

Radhey Shyam Pandey posted 1 patch 1 month, 4 weeks ago
There is a newer version of this series
drivers/usb/typec/tipd/core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
[PATCH] usb: typec: tipd: fix uninitialized typec_partner_desc on stack
Posted by Radhey Shyam Pandey 1 month, 4 weeks ago
tps6598x_connect() and cd321x_update_work() pass a stack-allocated
typec_partner_desc to typec_register_partner() after initializing only
usb_pd, accessory and identity.

typec_register_partner() copies attach and deattach from the descriptor
into the partner. With those fields left unset, garbage function pointers
may be stored and later invoked from typec_partner_link_device() when a USB
device is linked to the port. Uninitialized pd_revision and usb_capability
similarly leak stack data through partner sysfs.

Zero-initialize the descriptor so optional callbacks remain NULL and the
remaining fields are zero.

Fixes: 82432bbfb9e8 ("usb: typec: tipd: Handle mode transitions for CD321x")
Fixes: 0a4c005bd171 ("usb: typec: driver for TI TPS6598x USB Power Delivery controllers")
Cc: stable@vger.kernel.org
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
---
AI code scanning identified this issue; the possible call graph is shown below.

  USB-C plug event (IRQ)
    tps6598x_interrupt()
      tps6598x_handle_plug_event()
        tps6598x_connect()
          struct typec_partner_desc desc;     /* bug: attach/deattach unset */
          desc.usb_pd / .accessory / .identity = ...
          typec_register_partner(port, &desc)   /* class.c */
            partner->attach   = desc->attach;   /* copy stack garbage */
            partner->deattach = desc->deattach;
            [if port->usb2_dev || port->usb3_dev already set]
              typec_partner_link_device(partner, dev)
                if (partner->attach)
                  partner->attach(partner, dev)  /* indirect call via bad ptr */
---
 drivers/usb/typec/tipd/core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/typec/tipd/core.c b/drivers/usb/typec/tipd/core.c
index 522f56742aa9..1dee1084b02f 100644
--- a/drivers/usb/typec/tipd/core.c
+++ b/drivers/usb/typec/tipd/core.c
@@ -344,7 +344,7 @@ static void tps6598x_set_data_role(struct tps6598x *tps,
 
 static int tps6598x_connect(struct tps6598x *tps, u32 status)
 {
-	struct typec_partner_desc desc;
+	struct typec_partner_desc desc = { };
 	enum typec_pwr_opmode mode;
 	int ret;
 
@@ -841,7 +841,7 @@ static void cd321x_update_work(struct work_struct *work)
 
 	/* Set up partner if we were previously disconnected (or changed). */
 	if (!tps->partner) {
-		struct typec_partner_desc desc;
+		struct typec_partner_desc desc = { };
 
 		desc.usb_pd = is_pd;
 		desc.accessory = TYPEC_ACCESSORY_NONE; /* XXX: handle accessories */

base-commit: 415606a7be939835db9b0d6b711887586646346d
-- 
2.43.0
Re: [PATCH] usb: typec: tipd: fix uninitialized typec_partner_desc on stack
Posted by Greg KH 1 month, 4 weeks ago
On Mon, Aug 03, 2026 at 10:45:21PM +0530, Radhey Shyam Pandey wrote:
> tps6598x_connect() and cd321x_update_work() pass a stack-allocated
> typec_partner_desc to typec_register_partner() after initializing only
> usb_pd, accessory and identity.
> 
> typec_register_partner() copies attach and deattach from the descriptor
> into the partner. With those fields left unset, garbage function pointers
> may be stored and later invoked from typec_partner_link_device() when a USB
> device is linked to the port. Uninitialized pd_revision and usb_capability
> similarly leak stack data through partner sysfs.
> 
> Zero-initialize the descriptor so optional callbacks remain NULL and the
> remaining fields are zero.
> 
> Fixes: 82432bbfb9e8 ("usb: typec: tipd: Handle mode transitions for CD321x")
> Fixes: 0a4c005bd171 ("usb: typec: driver for TI TPS6598x USB Power Delivery controllers")
> Cc: stable@vger.kernel.org
> Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
> ---
> AI code scanning identified this issue; the possible call graph is shown below.

Nice, then please use an Assisted-by: tag.

thanks,

greg k-h