lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <aEZxmlHmjeWcXiF3@dragon>
Date: Mon, 9 Jun 2025 13:31:06 +0800
From: Shawn Guo <shawnguo2@...h.net>
To: Xu Yang <xu.yang_2@....com>, Peter Chen <peter.chen@...nel.org>
Cc: Shawn Guo <shawnguo@...nel.org>, imx@...ts.linux.dev,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org
Subject: i.MX kernel hangup caused by chipidea USB gadget driver

Hi Xu, Peter,

I'm seeing a kernel hangup on imx8mm-evk board.  It happens when:

 - USB gadget is enabled as Ethernet
 - There is data transfer over USB Ethernet
 - Device is going in/out suspend

A simple way to reproduce the issue could be:

 1. Copy a big file (like 500MB) from host PC to device with scp

 2. While the file copy is ongoing, suspend & resume the device like:

    $ echo +3 > /sys/class/rtc/rtc0/wakealarm; echo mem > /sys/power/state

 3. The device will hang up there

I reproduced on the following kernels:

 - Mainline kernel
 - NXP kernel lf-6.6.y
 - NXP kernel lf-6.12.y

But NXP kernel lf-6.1.y doesn't have this problem.  I tracked it down to
Peter's commit [1] on lf-6.1.y, and found that the gadget disconnect &
connect calls got lost from suspend & resume hooks, when the commit were
split and pushed upstream.  I confirm that adding the calls back fixes
the hangup.

---8<--------------------

diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 8a9b31fd5c89..72329a7eac4d 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -2374,6 +2374,9 @@ static void udc_suspend(struct ci_hdrc *ci)
         */
        if (hw_read(ci, OP_ENDPTLISTADDR, ~0) == 0)
                hw_write(ci, OP_ENDPTLISTADDR, ~0, ~0);
+
+       if (ci->driver && ci->vbus_active && (ci->gadget.state != USB_STATE_SUSPENDED))
+               usb_gadget_disconnect(&ci->gadget);
 }
 
 static void udc_resume(struct ci_hdrc *ci, bool power_lost)
@@ -2384,6 +2387,9 @@ static void udc_resume(struct ci_hdrc *ci, bool power_lost)
                                        OTGSC_BSVIS | OTGSC_BSVIE);
                if (ci->vbus_active)
                        usb_gadget_vbus_disconnect(&ci->gadget);
+       } else {
+               if (ci->driver && ci->vbus_active)
+                       usb_gadget_connect(&ci->gadget);
        }
 
        /* Restore value 0 if it was set for power lost check */

---->8------------------

But it's unclear to me why the hangup happens and how the change above
fix the problem.  Do you guys have any insight here?

Shawn

[1] https://github.com/reMarkable/linux-imx/commit/0791d25578cb0e46fd93ae7a3c36ff7a424f3547


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ