Oliver and others: Syzbot has identified a bug in usbcore caused by our assumption that bits 4-6 in bEndpointAddress will always be 0. Note that both the USB-2.0 and USB-3.1 specs say these bits are "Reserved, reset to zero". But we don't check for this. In particular, the endpoint_is_duplicate() routine in config.c compares the bEndpointAddress values of two endpoint descriptors without any masking, so differences in the reserved bits will cause the routine to think that the endpoints are different even when the number and direction bits agree. There are three obvious ways of dealing with this: Reject invalid descriptors in which the reserved bits are nonzero. This might run into problems if later specifications decide to store real information in those bits. Accept the invalid descriptors, but clear the reserved bits in bEndpointAddress while parsing the descriptors. This could also run into problems if those bits get used for something in the future. Accept the invalid descriptors, but mask out the reserved bits when comparing the addresses in endpoint_is_duplicate(). This might run into problems if any other routines assume that the reserved bits are zero -- there's some questionable code in devio.c's findintfep() and quirk.c's usb_endpoint_is_ignored(), for example. I'm inclined to go with the first approach. If a later version of the USB spec uses those bits for something, we can adapt to it. What do you think? Alan Stern
