dev_get_drvdata() on the parent device can return NULL if we attempt to
bind our device as a root device with no parent. This causes a null pointer
dereference when accessing pmic->regmap later as pmic uses the parent
struct. Fix this by adding a NULL check for pmic and returning -ENODEV
if to_platform_device() returns NULL for pmic.

Reported-by: syzbot+1a01783ea233350598b5@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=1a01783ea233350598b5
Fixes: d2061f9cc32d ("usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C PHY")
Cc: stable@vger.kernel.org
Signed-off-by: Jeffin Philip <jeffinphilip14@gmail.com>
---
 drivers/usb/typec/tcpm/wcove.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/usb/typec/tcpm/wcove.c b/drivers/usb/typec/tcpm/wcove.c
index 0e5a3e277c3e..80bca8edeba6 100644
--- a/drivers/usb/typec/tcpm/wcove.c
+++ b/drivers/usb/typec/tcpm/wcove.c
@@ -612,6 +612,10 @@ static int wcove_typec_probe(struct platform_device *pdev)
 	int irq;
 	int ret;
 
+	/* check if we have a parent device first */
+	if (!pmic)
+		return -ENODEV;
+
 	wcove = devm_kzalloc(&pdev->dev, sizeof(*wcove), GFP_KERNEL);
 	if (!wcove)
 		return -ENOMEM;
-- 
2.55.0

On Fri, Aug 21, 2026 at 07:22:46PM +0530, Jeffin Philip wrote:
> dev_get_drvdata() on the parent device can return NULL if we attempt to
> bind our device as a root device with no parent. This causes a null pointer
> dereference when accessing pmic->regmap later as pmic uses the parent
> struct. Fix this by adding a NULL check for pmic and returning -ENODEV
> if to_platform_device() returns NULL for pmic.
> 
> Reported-by: syzbot+1a01783ea233350598b5@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=1a01783ea233350598b5
> Fixes: d2061f9cc32d ("usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C PHY")
> Cc: stable@vger.kernel.org
> Signed-off-by: Jeffin Philip <jeffinphilip14@gmail.com>
> ---
>  drivers/usb/typec/tcpm/wcove.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/usb/typec/tcpm/wcove.c b/drivers/usb/typec/tcpm/wcove.c
> index 0e5a3e277c3e..80bca8edeba6 100644
> --- a/drivers/usb/typec/tcpm/wcove.c
> +++ b/drivers/usb/typec/tcpm/wcove.c
> @@ -612,6 +612,10 @@ static int wcove_typec_probe(struct platform_device *pdev)
>  	int irq;
>  	int ret;
>  
> +	/* check if we have a parent device first */
> +	if (!pmic)
> +		return -ENODEV;

How can a platform device NOT have a parent device?  WHat system is this
broken in?  Why not fix the platform definition properly instead as
something is really wrong here if this is a "root" platform device as
that should never happen.

thanks,

greg k-h

On Fri, 21 Aug 2026 17:00:12 +0200, Greg KH wrote:
>How can a platform device NOT have a parent device?  WHat system is this
>broken in?  Why not fix the platform definition properly instead as
>something is really wrong here if this is a "root" platform device as
>that should never happen.

As seen in the Closes: tag, this is a syzbot issue. It used driver_override()
to bind it in an unnatural way. So, I don't think it is possible in a real system.
We could atleast validate pmic like other functions using dev_get_drvdata() or it
could be left alone as is.

Thanks,
Jeffin.

On Fri, Aug 21, 2026 at 08:41:07PM +0530, Jeffin Philip wrote:
> On Fri, 21 Aug 2026 17:00:12 +0200, Greg KH wrote:
> >How can a platform device NOT have a parent device?  WHat system is this
> >broken in?  Why not fix the platform definition properly instead as
> >something is really wrong here if this is a "root" platform device as
> >that should never happen.
> 
> As seen in the Closes: tag, this is a syzbot issue. It used driver_override()
> to bind it in an unnatural way. So, I don't think it is possible in a real system.
> We could atleast validate pmic like other functions using dev_get_drvdata() or it
> could be left alone as is.

If you call bind on a device, you have to know what you are doing, as it
can easily crash as you see here.  Just fix syzbot please.