https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 29 Sep 2026 17:18:59 +0000 https://vulnerability.circl.lu/vuln/cve-2024-36977 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>usb: dwc3: Wait unconditionally after issuing EndXfer command</p> <p>Currently all controller IP/revisions except DWC3_usb3 &gt;= 310a wait 1ms unconditionally for ENDXFER completion when IOC is not set. This is because DWC_usb3 controller revisions &gt;= 3.10a supports GUCTL2[14: Rst_actbitlater] bit which allows polling CMDACT bit to know whether ENDXFER command is completed.</p> <p>Consider a case where an IN request was queued, and parallelly soft_disconnect was called (due to ffs_epfile_release). This eventually calls stop_active_transfer with IOC cleared, hence send_gadget_ep_cmd() skips waiting for CMDACT cleared during EndXfer. For DWC3 controllers with revisions &gt;= 310a, we don&#39;t forcefully wait for 1ms either, and we proceed by unmapping the requests. If ENDXFER didn&#39;t complete by this time, it leads to SMMU faults since the controller would still be accessing those requests.</p> <p>Fix this by ensuring ENDXFER completion by adding 1ms delay in __dwc3_stop_active_transfer() unconditionally.</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>usb: dwc3: Wait unconditionally after issuing EndXfer command</p> <p>Currently all controller IP/revisions except DWC3_usb3 &gt;= 310a wait 1ms unconditionally for ENDXFER completion when IOC is not set. This is because DWC_usb3 controller revisions &gt;= 3.10a supports GUCTL2[14: Rst_actbitlater] bit which allows polling CMDACT bit to know whether ENDXFER command is completed.</p> <p>Consider a case where an IN request was queued, and parallelly soft_disconnect was called (due to ffs_epfile_release). This eventually calls stop_active_transfer with IOC cleared, hence send_gadget_ep_cmd() skips waiting for CMDACT cleared during EndXfer. For DWC3 controllers with revisions &gt;= 310a, we don&#39;t forcefully wait for 1ms either, and we proceed by unmapping the requests. If ENDXFER didn&#39;t complete by this time, it leads to SMMU faults since the controller would still be accessing those requests.</p> <p>Fix this by ensuring ENDXFER completion by adding 1ms delay in __dwc3_stop_active_transfer() unconditionally.</p> https://vulnerability.circl.lu/vuln/cve-2024-36977