1) stall is needed to create an incomplete USB transaction. You are right – this is necessary to prevent request completion, as a result of which you can create a request queue. The delay does not matter. Further requests can be executed even with a sufficiently long pause after the stall (for example, 10 seconds). In fact, the USB bus does not go into the STALL state (the STALL handshake packets are not sent, only NACK). At the same time, the controller is working in such a way that it always processes SETUP packets, which is why it is possible to create a request queue.

2) No additional requests are needed. As it turned out, in the presented version of the exploit, even a single stall request is enough – it will be overwritten with new "callback" and "next" values. Apparently, this is possible because before overflowing while executing the USB_REQ_SET_CONFIGURATION request (libusb1_no_error_ctrl_transfer(device, 0, 9, 0, 0, t8010_overwrite, 50)), another request will be created and it will remain in the heap (see SecureROM sources). It will play the role of a heap barrier and will prevent access to corrupted metadata of an overflowed request during further work with the heap. If you use a request from the original code (libusb1_no_error_ctrl_transfer(device, 0, 0, 0, 0, t8010_overwrite, 50)), then the second request is needed as a heap barrier.

• 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?

• 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.