USB mass-storage writes via tinyehci + usbstorage on a Trinity Xbox 360 can corrupt FAT32 USB drives (tested on a 128GB SanDisk USB 2.0, MBR FAT32). Reads are stable.
Small writes may succeed instantly or hang ~16s, then fail with -ETIMEDOUT. Repeated failures can corrupt the filesystem (FAT, partition table, labels, filenames), making the drive unreadable on a PC without reformatting.
When a write stalls, the device appears to accept data at an extremely slow rate (~256 B/s). The controller eventually times out because it doesn’t receive timely progress/heartbeat signals during this slow state.
Bugs found:
-
NULL pointer use in ehci.c (qh_end_transfer)**
On early failure, error handling can dereference a freed/invalid qh pointer.
-
Infinite loop in usbstorage.c (__cycle)**
Error paths use continue, causing the transfer loop to restart indefinitely instead of exiting or retrying correctly.
Even my patches, writes still fail at the USB controller level under stalled transfers. Large or blocked writes continue extremely slowly and always hit the timeout window.
Likely cause is USB device back-pressure causing prolonged throttling, combined with overly aggressive timeouts and lack of progress signaling. Interrupted writes leave the device in an inconsistent state, likely triggering the observed filesystem corruption.
I am currently unsure of how to fix these issues.
USB mass-storage writes via
tinyehci+usbstorageon a Trinity Xbox 360 can corrupt FAT32 USB drives (tested on a 128GB SanDisk USB 2.0, MBR FAT32). Reads are stable.Small writes may succeed instantly or hang ~16s, then fail with
-ETIMEDOUT. Repeated failures can corrupt the filesystem (FAT, partition table, labels, filenames), making the drive unreadable on a PC without reformatting.When a write stalls, the device appears to accept data at an extremely slow rate (~256 B/s). The controller eventually times out because it doesn’t receive timely progress/heartbeat signals during this slow state.
Bugs found:
NULL pointer use in
ehci.c(qh_end_transfer)**On early failure, error handling can dereference a freed/invalid
qhpointer.Infinite loop in
usbstorage.c(__cycle)**Error paths use
continue, causing the transfer loop to restart indefinitely instead of exiting or retrying correctly.Even my patches, writes still fail at the USB controller level under stalled transfers. Large or blocked writes continue extremely slowly and always hit the timeout window.
Likely cause is USB device back-pressure causing prolonged throttling, combined with overly aggressive timeouts and lack of progress signaling. Interrupted writes leave the device in an inconsistent state, likely triggering the observed filesystem corruption.
I am currently unsure of how to fix these issues.