It seems to prevent the io requests on the execution queue from being completed, providing enough time to add any number of them before the usb bus is reset. This is implied but not said explicitly.
How can the USB bus be «stalled» but still receive additional setup packets and data from later USB packets from the host?
2) It seems you added an extra usb_leak() to the end before sending the overwrite payload. Is there a purpose of the extra send?
It seems likely no. If I have interpreted your analysis correctly, there would then be three io_requests on the heap after the io_buffer rather than two in the original checkm8, right? One fo th stall and then two more for the two usb_leak calls.
Thanks so much for this. Great post. You guys did some excellent work here.
2) It seems you added an extra usb_leak() to the end before sending the overwrite payload. Is there a purpose of the extra send?
Thanks so much for this. Great post. You guys did some excellent work here.