fkie_cve-2025-38376
Vulnerability from fkie_nvd
Published
2025-07-25 13:15
Modified
2025-07-25 15:29
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: usb: chipidea: udc: disconnect/reconnect from host when do suspend/resume Shawn and John reported a hang issue during system suspend as below: - USB gadget is enabled as Ethernet - There is data transfer over USB Ethernet (scp a big file between host and device) - Device is going in/out suspend (echo mem > /sys/power/state) The root cause is the USB device controller is suspended but the USB bus is still active which caused the USB host continues to transfer data with device and the device continues to queue USB requests (in this case, a delayed TCP ACK packet trigger the issue) after controller is suspended, however the USB controller clock is already gated off. Then if udc driver access registers after that point, the system will hang. The correct way to avoid such issue is to disconnect device from host when the USB bus is not at suspend state. Then the host will receive disconnect event and stop data transfer in time. To continue make USB gadget device work after system resume, this will reconnect device automatically. To make usb wakeup work if USB bus is already at suspend state, this will keep connection for it only when USB device controller has enabled wakeup capability.
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/31a6afbe86e8e9deba9ab53876ec49eafc7fd901
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/5fd585fedb79bac2af9976b0fa3ffa354f0cc0bb
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/937f49be49d6ee696eb5457c21ff89c135c9b5ae
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/c68a27bbebbdb4e0ccd45d4f0df7111a09ddac24
Impacted products
Vendor Product Version


To clipboard 

{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: chipidea: udc: disconnect/reconnect from host when do suspend/resume\n\nShawn and John reported a hang issue during system suspend as below:\n\n - USB gadget is enabled as Ethernet\n - There is data transfer over USB Ethernet (scp a big file between host\n                                             and device)\n - Device is going in/out suspend (echo mem \u003e /sys/power/state)\n\nThe root cause is the USB device controller is suspended but the USB bus\nis still active which caused the USB host continues to transfer data with\ndevice and the device continues to queue USB requests (in this case, a\ndelayed TCP ACK packet trigger the issue) after controller is suspended,\nhowever the USB controller clock is already gated off. Then if udc driver\naccess registers after that point, the system will hang.\n\nThe correct way to avoid such issue is to disconnect device from host when\nthe USB bus is not at suspend state. Then the host will receive disconnect\nevent and stop data transfer in time. To continue make USB gadget device\nwork after system resume, this will reconnect device automatically.\n\nTo make usb wakeup work if USB bus is already at suspend state, this will\nkeep connection for it only when USB device controller has enabled wakeup\ncapability."
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: chipidea: udc: desconectar/reconectar del host al suspender/reanudar Shawn y John informaron de un problema de cuelgue durante la suspensi\u00f3n del sistema como se muestra a continuaci\u00f3n: - El dispositivo USB est\u00e1 habilitado como Ethernet - Hay transferencia de datos a trav\u00e9s de USB Ethernet (scp un archivo grande entre el host y el dispositivo) - El dispositivo entra/sale de suspensi\u00f3n (echo mem \u0026gt; /sys/power/state) La causa ra\u00edz es que el controlador del dispositivo USB est\u00e1 suspendido, pero el bus USB sigue activo, lo que provoc\u00f3 que el host USB siguiera transfiriendo datos con el dispositivo y el dispositivo siguiera poniendo en cola las solicitudes USB (en este caso, un paquete TCP ACK retrasado desencaden\u00f3 el problema) despu\u00e9s de que el controlador se suspendiera; sin embargo, el reloj del controlador USB ya estaba desactivado. Entonces, si el acceso al controlador udc se registra despu\u00e9s de ese punto, el sistema se colgar\u00e1. La forma correcta de evitar este problema es desconectar el dispositivo del host cuando el bus USB no est\u00e9 en estado de suspensi\u00f3n. Entonces, el host recibir\u00e1 el evento de desconexi\u00f3n y detendr\u00e1 la transferencia de datos a tiempo. Para que el dispositivo USB siga funcionando despu\u00e9s de reanudar el sistema, esto volver\u00e1 a conectar el dispositivo autom\u00e1ticamente. Para que la activaci\u00f3n USB funcione si el bus USB ya est\u00e1 en estado de suspensi\u00f3n, esto mantendr\u00e1 la conexi\u00f3n solo cuando el controlador del dispositivo USB haya habilitado la capacidad de activaci\u00f3n."
    }
  ],
  "id": "CVE-2025-38376",
  "lastModified": "2025-07-25T15:29:19.837",
  "metrics": {},
  "published": "2025-07-25T13:15:26.650",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/31a6afbe86e8e9deba9ab53876ec49eafc7fd901"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/5fd585fedb79bac2af9976b0fa3ffa354f0cc0bb"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/937f49be49d6ee696eb5457c21ff89c135c9b5ae"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/c68a27bbebbdb4e0ccd45d4f0df7111a09ddac24"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Awaiting Analysis"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.