CVE-2025-39801

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: dwc3: Remove WARN_ON for device endpoint command timeouts<br /> <br /> This commit addresses a rarely observed endpoint command timeout<br /> which causes kernel panic due to warn when &amp;#39;panic_on_warn&amp;#39; is enabled<br /> and unnecessary call trace prints when &amp;#39;panic_on_warn&amp;#39; is disabled.<br /> It is seen during fast software-controlled connect/disconnect testcases.<br /> The following is one such endpoint command timeout that we observed:<br /> <br /> 1. Connect<br /> =======<br /> -&gt;dwc3_thread_interrupt<br /> -&gt;dwc3_ep0_interrupt<br /> -&gt;configfs_composite_setup<br /> -&gt;composite_setup<br /> -&gt;usb_ep_queue<br /> -&gt;dwc3_gadget_ep0_queue<br /> -&gt;__dwc3_gadget_ep0_queue<br /> -&gt;__dwc3_ep0_do_control_data<br /> -&gt;dwc3_send_gadget_ep_cmd<br /> <br /> 2. Disconnect<br /> ==========<br /> -&gt;dwc3_thread_interrupt<br /> -&gt;dwc3_gadget_disconnect_interrupt<br /> -&gt;dwc3_ep0_reset_state<br /> -&gt;dwc3_ep0_end_control_data<br /> -&gt;dwc3_send_gadget_ep_cmd<br /> <br /> In the issue scenario, in Exynos platforms, we observed that control<br /> transfers for the previous connect have not yet been completed and end<br /> transfer command sent as a part of the disconnect sequence and<br /> processing of USB_ENDPOINT_HALT feature request from the host timeout.<br /> This maybe an expected scenario since the controller is processing EP<br /> commands sent as a part of the previous connect. It maybe better to<br /> remove WARN_ON in all places where device endpoint commands are sent to<br /> avoid unnecessary kernel panic due to warn.