Skip to contentSkip to conversation

usb: gadget: tegra-xudc: Fix crash in vbus_draw

PATCH In review Jon Hunter 3 participants 8 messages Apr 5, 2023 – Apr 20, 2023

Subsystems (2)
USB Tegra architecture support
lore
Share & tools
lore

Jon Hunter

author maintainer
#0 lore raw

PATCH 1/2 usb: gadget: tegra-xudc: Fix crash in vbus_draw

Commit ac82b56bda5f ("usb: gadget: tegra-xudc: Add vbus_draw support") populated the vbus_draw callback for the Tegra XUDC driver. The function tegra_xudc_gadget_vbus_draw(), that was added by this commit, assumes that the pointer 'curr_usbphy' has been initialised, which is not always the case because this is only initialised when the USB role is updated. Fix this crash, by checking that the 'curr_usbphy' is valid before dereferencing.

Fixes ac82b56bda5f ("usb: gadget: tegra-xudc: Add vbus_draw support")
Signed-off-by Jon Hunter <[email protected]>
---
 drivers/usb/gadget/udc/tegra-xudc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/gadget/udc/tegra-xudc.c +1 -1
index 2b71b33725f1..5bccd64847ff 100644
@@ -2167,7 +2167,7 @@ static int tegra_xudc_gadget_vbus_draw(struct usb_gadget *gadget,
 
 	dev_dbg(xudc->dev, "%s: %u mA\n", __func__, m_a);
 
-	if (xudc->curr_usbphy->chg_type == SDP_TYPE)
+	if (xudc->curr_usbphy && xudc->curr_usbphy->chg_type == SDP_TYPE)
 		ret = usb_phy_set_power(xudc->curr_usbphy, m_a);
 
 	return ret;
Signature · 1 line
2.34.1
author maintainer
#1 lore raw

PATCH 2/2 usb: gadget: tegra-xudc: Remove unneeded return variable

The 'ret' variable in the function tegra_xudc_gadget_vbus_draw() is not needed and so remove this variable.

Signed-off-by Jon Hunter <[email protected]>
---
 drivers/usb/gadget/udc/tegra-xudc.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)
drivers/usb/gadget/udc/tegra-xudc.c +2 -3
index 5bccd64847ff..34e9c1df54c7 100644
@@ -2162,15 +2162,14 @@ static int tegra_xudc_gadget_stop(struct usb_gadget *gadget)
 static int tegra_xudc_gadget_vbus_draw(struct usb_gadget *gadget,
 						unsigned int m_a)
 {
-	int ret = 0;
 	struct tegra_xudc *xudc = to_xudc(gadget);
 
 	dev_dbg(xudc->dev, "%s: %u mA\n", __func__, m_a);
 
 	if (xudc->curr_usbphy && xudc->curr_usbphy->chg_type == SDP_TYPE)
-		ret = usb_phy_set_power(xudc->curr_usbphy, m_a);
+		return usb_phy_set_power(xudc->curr_usbphy, m_a);
 
-	return ret;
+	return 0;
 }
 
 static int tegra_xudc_set_selfpowered(struct usb_gadget *gadget, int is_on)
Signature · 1 line
2.34.1
Reviewed-by on v1 2/2
#2 lore raw

Re: [PATCH 2/2] usb: gadget: tegra-xudc: Remove unneeded return variable

Quoted 7 lines · Jon Hunter

The 'ret' variable in the function tegra_xudc_gadget_vbus_draw() is not needed and so remove this variable.

Signed-off-by Jon Hunter <[email protected]>
---
 drivers/usb/gadget/udc/tegra-xudc.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)
Reviewed-by Thierry Reding <[email protected]>
#3 lore raw
In reply to Jon Hunter
Quoted 19 lines · Jon Hunter

Commit ac82b56bda5f ("usb: gadget: tegra-xudc: Add vbus_draw support") populated the vbus_draw callback for the Tegra XUDC driver. The function tegra_xudc_gadget_vbus_draw(), that was added by this commit, assumes that the pointer 'curr_usbphy' has been initialised, which is not always the case because this is only initialised when the USB role is updated. Fix this crash, by checking that the 'curr_usbphy' is valid before dereferencing.

Fixes ac82b56bda5f ("usb: gadget: tegra-xudc: Add vbus_draw support")
Signed-off-by Jon Hunter <[email protected]>
---
 drivers/usb/gadget/udc/tegra-xudc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/gadget/udc/tegra-xudc.c +0 -0
index 2b71b33725f1..5bccd64847ff 100644

drivers/usb/gadget/udc/tegra-xudc.c static int tegra_xudc_gadget_vbus_draw(struct usb_gadget *gadget, · line 2173

Quoted 8 lines
drivers/usb/gadget/udc/tegra-xudc.c +1 -1
@@ -2167,7 +2167,7 @@ static int tegra_xudc_gadget_vbus_draw(struct usb_gadget *gadget,
 
 	dev_dbg(xudc->dev, "%s: %u mA\n", __func__, m_a);
 
-	if (xudc->curr_usbphy->chg_type == SDP_TYPE)
+	if (xudc->curr_usbphy && xudc->curr_usbphy->chg_type == SDP_TYPE)
 		ret = usb_phy_set_power(xudc->curr_usbphy, m_a);
 
 	return ret;

Looking at tegra_xudc_probe(), that calls tegra_xudc_update_data_role() for all PHYs, so shouldn't that be enough to get curr_usbphy set? Or is there perhaps a race between ->vbus_draw() and the data role update? Is ->vbus_draw() perhaps called as part of usb_add_gadget_udc()? Should we reorder those to make sure the role is properly updated before the gadget is registered?

Thierry

author maintainer
#4 lore raw
Quoted 27 lines · Thierry Reding
Quoted 26 lines · Jon Hunter

Commit ac82b56bda5f ("usb: gadget: tegra-xudc: Add vbus_draw support") populated the vbus_draw callback for the Tegra XUDC driver. The function tegra_xudc_gadget_vbus_draw(), that was added by this commit, assumes that the pointer 'curr_usbphy' has been initialised, which is not always the case because this is only initialised when the USB role is updated. Fix this crash, by checking that the 'curr_usbphy' is valid before dereferencing.

Fixes ac82b56bda5f ("usb: gadget: tegra-xudc: Add vbus_draw support")
Signed-off-by Jon Hunter <[email protected]>
---
  drivers/usb/gadget/udc/tegra-xudc.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/gadget/udc/tegra-xudc.c +1 -1
index 2b71b33725f1..5bccd64847ff 100644
@@ -2167,7 +2167,7 @@ static int tegra_xudc_gadget_vbus_draw(struct usb_gadget *gadget,
 
  	dev_dbg(xudc->dev, "%s: %u mA\n", __func__, m_a);
 
-	if (xudc->curr_usbphy->chg_type == SDP_TYPE)
+	if (xudc->curr_usbphy && xudc->curr_usbphy->chg_type == SDP_TYPE)
  		ret = usb_phy_set_power(xudc->curr_usbphy, m_a);
Quoted 8 lines

drivers/usb/gadget/udc/tegra-xudc.c static int tegra_xudc_gadget_vbus_draw(struct usb_gadget *gadget, · line 2173

Quoted 1 line
drivers/usb/gadget/udc/tegra-xudc.c +0 -0
  	return ret;

Looking at tegra_xudc_probe(), that calls tegra_xudc_update_data_role() for all PHYs, so shouldn't that be enough to get curr_usbphy set? Or is there perhaps a race between ->vbus_draw() and the data role update? Is ->vbus_draw() perhaps called as part of usb_add_gadget_udc()? Should we reorder those to make sure the role is properly updated before the gadget is registered?

Yes it does call it, but it still does not set the curr_usbphy. If you look at the function it may not set it.

In the backtrace I saw, which was happening on reboot, it was in the unregister of the gadget ...

[ 1102.047896] Call trace:
[ 1102.050402]  0xffffde9fd18c0878
[ 1102.053602]  usb_gadget_vbus_draw+0x28/0x50
[ 1102.057879]  composite_disconnect+0x1c/0x40 [libcomposite]
[ 1102.063509]  usb_get_function_instance+0x1808/0x27b0 [libcomposite]
[ 1102.069935]  usb_gadget_disconnect+0x64/0xa0
[ 1102.074304]  usb_gadget_remove_driver+0x2c/0xc0
[ 1102.078942]  usb_gadget_unregister_driver+0x70/0xf0
[ 1102.083927]  usb_get_function_instance+0x2774/0x27b0 [libcomposite]
[ 1102.090339]  unregister_gadget_item+0x280/0x470 [libcomposite]
[ 1102.096314]  configfs_write_iter+0xc4/0x120
[ 1102.100609]  new_sync_write+0xe8/0x190
[ 1102.104461]  vfs_write+0x234/0x380
[ 1102.107938]  ksys_write+0x6c/0x100
[ 1102.111417]  __arm64_sys_write+0x1c/0x30
[ 1102.115427]  invoke_syscall.constprop.0+0x4c/0xe0
[ 1102.120245]  do_el0_svc+0x50/0x150
[ 1102.123723]  el0_svc+0x28/0xc0
[ 1102.126854]  el0t_64_sync_handler+0xb0/0xc0
[ 1102.131138]  el0t_64_sync+0x1a0/0x1a4
[ 1102.134889] Code: 910003fd a90153f3 f94ce413 f100027f (b9409a60)
[ 1102.141139] ---[ end trace cdf6612bd43fcbf2 ]---

Jon

Reviewed-by
#5 lore raw
Quoted 55 lines · Jon Hunter
Quoted 24 lines · Thierry Reding
Quoted 23 lines · Jon Hunter

Commit ac82b56bda5f ("usb: gadget: tegra-xudc: Add vbus_draw support") populated the vbus_draw callback for the Tegra XUDC driver. The function tegra_xudc_gadget_vbus_draw(), that was added by this commit, assumes that the pointer 'curr_usbphy' has been initialised, which is not always the case because this is only initialised when the USB role is updated. Fix this crash, by checking that the 'curr_usbphy' is valid before dereferencing.

Fixes ac82b56bda5f ("usb: gadget: tegra-xudc: Add vbus_draw support")
Signed-off-by Jon Hunter <[email protected]>
---
  drivers/usb/gadget/udc/tegra-xudc.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/gadget/udc/tegra-xudc.c +1 -1
index 2b71b33725f1..5bccd64847ff 100644
@@ -2167,7 +2167,7 @@ static int tegra_xudc_gadget_vbus_draw(struct usb_gadget *gadget,
  	dev_dbg(xudc->dev, "%s: %u mA\n", __func__, m_a);
-	if (xudc->curr_usbphy->chg_type == SDP_TYPE)
+	if (xudc->curr_usbphy && xudc->curr_usbphy->chg_type == SDP_TYPE)
  		ret = usb_phy_set_power(xudc->curr_usbphy, m_a);
Quoted 8 lines

drivers/usb/gadget/udc/tegra-xudc.c static int tegra_xudc_gadget_vbus_draw(struct usb_gadget *gadget, · line 2173

Quoted 1 line
drivers/usb/gadget/udc/tegra-xudc.c +0 -0
  	return ret;

Looking at tegra_xudc_probe(), that calls tegra_xudc_update_data_role() for all PHYs, so shouldn't that be enough to get curr_usbphy set? Or is there perhaps a race between ->vbus_draw() and the data role update? Is ->vbus_draw() perhaps called as part of usb_add_gadget_udc()? Should we reorder those to make sure the role is properly updated before the gadget is registered?

Yes it does call it, but it still does not set the curr_usbphy. If you look at the function it may not set it.

In the backtrace I saw, which was happening on reboot, it was in the unregister of the gadget ...

[ 1102.047896] Call trace:
[ 1102.050402]  0xffffde9fd18c0878
[ 1102.053602]  usb_gadget_vbus_draw+0x28/0x50
[ 1102.057879]  composite_disconnect+0x1c/0x40 [libcomposite]
[ 1102.063509]  usb_get_function_instance+0x1808/0x27b0 [libcomposite]
[ 1102.069935]  usb_gadget_disconnect+0x64/0xa0
[ 1102.074304]  usb_gadget_remove_driver+0x2c/0xc0
[ 1102.078942]  usb_gadget_unregister_driver+0x70/0xf0
[ 1102.083927]  usb_get_function_instance+0x2774/0x27b0 [libcomposite]
[ 1102.090339]  unregister_gadget_item+0x280/0x470 [libcomposite]
[ 1102.096314]  configfs_write_iter+0xc4/0x120
[ 1102.100609]  new_sync_write+0xe8/0x190
[ 1102.104461]  vfs_write+0x234/0x380
[ 1102.107938]  ksys_write+0x6c/0x100
Quoted 8 lines
[ 1102.111417]  __arm64_sys_write+0x1c/0x30
[ 1102.115427]  invoke_syscall.constprop.0+0x4c/0xe0
[ 1102.120245]  do_el0_svc+0x50/0x150
[ 1102.123723]  el0_svc+0x28/0xc0
[ 1102.126854]  el0t_64_sync_handler+0xb0/0xc0
[ 1102.131138]  el0t_64_sync+0x1a0/0x1a4
[ 1102.134889] Code: 910003fd a90153f3 f94ce413 f100027f (b9409a60)
[ 1102.141139] ---[ end trace cdf6612bd43fcbf2 ]---

Alright. There are a lot of cases where we can run into this and it all looks a little complicated, so I think it would be good to unwind this at some point. But I can't think of an easy way to do that, so for a fix this looks good:

Reviewed-by Thierry Reding <[email protected]>
author maintainer
#6 lore raw

Hi Greg,

Quoted 65 lines · Thierry Reding
Quoted 55 lines · Jon Hunter
Quoted 24 lines · Thierry Reding
Quoted 23 lines · Jon Hunter

Commit ac82b56bda5f ("usb: gadget: tegra-xudc: Add vbus_draw support") populated the vbus_draw callback for the Tegra XUDC driver. The function tegra_xudc_gadget_vbus_draw(), that was added by this commit, assumes that the pointer 'curr_usbphy' has been initialised, which is not always the case because this is only initialised when the USB role is updated. Fix this crash, by checking that the 'curr_usbphy' is valid before dereferencing.

Fixes ac82b56bda5f ("usb: gadget: tegra-xudc: Add vbus_draw support")
Signed-off-by Jon Hunter <[email protected]>
---
   drivers/usb/gadget/udc/tegra-xudc.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/gadget/udc/tegra-xudc.c +1 -1
index 2b71b33725f1..5bccd64847ff 100644
@@ -2167,7 +2167,7 @@ static int tegra_xudc_gadget_vbus_draw(struct usb_gadget *gadget,
   	dev_dbg(xudc->dev, "%s: %u mA\n", __func__, m_a);
-	if (xudc->curr_usbphy->chg_type == SDP_TYPE)
+	if (xudc->curr_usbphy && xudc->curr_usbphy->chg_type == SDP_TYPE)
   		ret = usb_phy_set_power(xudc->curr_usbphy, m_a);
Quoted 8 lines

drivers/usb/gadget/udc/tegra-xudc.c static int tegra_xudc_gadget_vbus_draw(struct usb_gadget *gadget, · line 2173

Quoted 1 line
drivers/usb/gadget/udc/tegra-xudc.c +0 -0
   	return ret;

Looking at tegra_xudc_probe(), that calls tegra_xudc_update_data_role() for all PHYs, so shouldn't that be enough to get curr_usbphy set? Or is there perhaps a race between ->vbus_draw() and the data role update? Is ->vbus_draw() perhaps called as part of usb_add_gadget_udc()? Should we reorder those to make sure the role is properly updated before the gadget is registered?

Yes it does call it, but it still does not set the curr_usbphy. If you look at the function it may not set it.

In the backtrace I saw, which was happening on reboot, it was in the unregister of the gadget ...

[ 1102.047896] Call trace:
[ 1102.050402]  0xffffde9fd18c0878
[ 1102.053602]  usb_gadget_vbus_draw+0x28/0x50
[ 1102.057879]  composite_disconnect+0x1c/0x40 [libcomposite]
[ 1102.063509]  usb_get_function_instance+0x1808/0x27b0 [libcomposite]
[ 1102.069935]  usb_gadget_disconnect+0x64/0xa0
[ 1102.074304]  usb_gadget_remove_driver+0x2c/0xc0
[ 1102.078942]  usb_gadget_unregister_driver+0x70/0xf0
[ 1102.083927]  usb_get_function_instance+0x2774/0x27b0 [libcomposite]
[ 1102.090339]  unregister_gadget_item+0x280/0x470 [libcomposite]
[ 1102.096314]  configfs_write_iter+0xc4/0x120
[ 1102.100609]  new_sync_write+0xe8/0x190
[ 1102.104461]  vfs_write+0x234/0x380
[ 1102.107938]  ksys_write+0x6c/0x100
Quoted 8 lines
[ 1102.111417]  __arm64_sys_write+0x1c/0x30
[ 1102.115427]  invoke_syscall.constprop.0+0x4c/0xe0
[ 1102.120245]  do_el0_svc+0x50/0x150
[ 1102.123723]  el0_svc+0x28/0xc0
[ 1102.126854]  el0t_64_sync_handler+0xb0/0xc0
[ 1102.131138]  el0t_64_sync+0x1a0/0x1a4
[ 1102.134889] Code: 910003fd a90153f3 f94ce413 f100027f (b9409a60)
[ 1102.141139] ---[ end trace cdf6612bd43fcbf2 ]---
Quoted 6 lines

Alright. There are a lot of cases where we can run into this and it all looks a little complicated, so I think it would be good to unwind this at some point. But I can't think of an easy way to do that, so for a fix this looks good:

Reviewed-by Thierry Reding <[email protected]>

OK for pick this up v6.4?

Thanks
Jon

Signature · 1 line
nvpublic
maintainer
#7 lore raw
Quoted 68 lines · Jon Hunter

Hi Greg,

Quoted 65 lines · Thierry Reding
Quoted 63 lines · Jon Hunter
Quoted 24 lines · Thierry Reding
Quoted 23 lines · Jon Hunter

Commit ac82b56bda5f ("usb: gadget: tegra-xudc: Add vbus_draw support") populated the vbus_draw callback for the Tegra XUDC driver. The function tegra_xudc_gadget_vbus_draw(), that was added by this commit, assumes that the pointer 'curr_usbphy' has been initialised, which is not always the case because this is only initialised when the USB role is updated. Fix this crash, by checking that the 'curr_usbphy' is valid before dereferencing.

Fixes ac82b56bda5f ("usb: gadget: tegra-xudc: Add vbus_draw support")
Signed-off-by Jon Hunter <[email protected]>
---
   drivers/usb/gadget/udc/tegra-xudc.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/gadget/udc/tegra-xudc.c +1 -1
index 2b71b33725f1..5bccd64847ff 100644
@@ -2167,7 +2167,7 @@ static int tegra_xudc_gadget_vbus_draw(struct usb_gadget *gadget,
   	dev_dbg(xudc->dev, "%s: %u mA\n", __func__, m_a);
-	if (xudc->curr_usbphy->chg_type == SDP_TYPE)
+	if (xudc->curr_usbphy && xudc->curr_usbphy->chg_type == SDP_TYPE)
   		ret = usb_phy_set_power(xudc->curr_usbphy, m_a);
Quoted 8 lines

drivers/usb/gadget/udc/tegra-xudc.c static int tegra_xudc_gadget_vbus_draw(struct usb_gadget *gadget, · line 2173

Quoted 1 line
drivers/usb/gadget/udc/tegra-xudc.c +0 -0
   	return ret;

Looking at tegra_xudc_probe(), that calls tegra_xudc_update_data_role() for all PHYs, so shouldn't that be enough to get curr_usbphy set? Or is there perhaps a race between ->vbus_draw() and the data role update? Is ->vbus_draw() perhaps called as part of usb_add_gadget_udc()? Should we reorder those to make sure the role is properly updated before the gadget is registered?

Yes it does call it, but it still does not set the curr_usbphy. If you look at the function it may not set it.

In the backtrace I saw, which was happening on reboot, it was in the unregister of the gadget ...

[ 1102.047896] Call trace:
[ 1102.050402]  0xffffde9fd18c0878
[ 1102.053602]  usb_gadget_vbus_draw+0x28/0x50
[ 1102.057879]  composite_disconnect+0x1c/0x40 [libcomposite]
[ 1102.063509]  usb_get_function_instance+0x1808/0x27b0 [libcomposite]
[ 1102.069935]  usb_gadget_disconnect+0x64/0xa0
[ 1102.074304]  usb_gadget_remove_driver+0x2c/0xc0
[ 1102.078942]  usb_gadget_unregister_driver+0x70/0xf0
[ 1102.083927]  usb_get_function_instance+0x2774/0x27b0 [libcomposite]
[ 1102.090339]  unregister_gadget_item+0x280/0x470 [libcomposite]
[ 1102.096314]  configfs_write_iter+0xc4/0x120
[ 1102.100609]  new_sync_write+0xe8/0x190
[ 1102.104461]  vfs_write+0x234/0x380
[ 1102.107938]  ksys_write+0x6c/0x100
[ 1102.111417]  __arm64_sys_write+0x1c/0x30
[ 1102.115427]  invoke_syscall.constprop.0+0x4c/0xe0
[ 1102.120245]  do_el0_svc+0x50/0x150
[ 1102.123723]  el0_svc+0x28/0xc0
[ 1102.126854]  el0t_64_sync_handler+0xb0/0xc0
[ 1102.131138]  el0t_64_sync+0x1a0/0x1a4
[ 1102.134889] Code: 910003fd a90153f3 f94ce413 f100027f (b9409a60)
[ 1102.141139] ---[ end trace cdf6612bd43fcbf2 ]---
Quoted 8 lines
Quoted 6 lines

Alright. There are a lot of cases where we can run into this and it all looks a little complicated, so I think it would be good to unwind this at some point. But I can't think of an easy way to do that, so for a fix this looks good:

Reviewed-by Thierry Reding <[email protected]>

OK for pick this up v6.4?

It's in my queue, which is big, I'm at a conference this week but will try to get to it today on the train ride...

greg k-h