-
Notifications
You must be signed in to change notification settings - Fork 153
Description
We have observed a race condition during the boot process on systems with nested USB hub topologies. When multiple SuperSpeed (SS) hubs are enumerated in quick succession, usbguard-daemon occasionally fails to authorize a child hub because it cannot find the sysfs path for the parent hub, even though the kernel has already fired the UEvent for it.
When this occurs, usbguard logs a "Device insert exception" and "unknown sysfs path." Because the device is not recognized in the topology, it is rejected (following authorized_default=0 logic), and the kernel de-configures the hub via set_configuration(0).
Topology: Complex nested hubs (Root Hub -> Tier 1 Hub -> Tier 2 Hub).
The logs show that the daemon attempts to process a child device (2-2.4) but fails because the parent node (2-2) is not yet fully populated/known in the daemon's internal model:
kernel: usb 2-2.4: new SuperSpeed USB device number 6 using xhci_hcd
kernel: usb 2-2.4: New USB device found, idVendor=xxxx, idProduct=xxxx, bcdDevice= 0.01
usbguard-daemon: Device insert exception: DeviceManagerBase: /devices/.../usb2/2-2: unknown sysfs path
usbguard-daemon: DeviceManagerBase: /devices/.../usb2/2-2: unknown sysfs path
usbguard-daemon: Rejecting device at syspath=/devices/.../usb2/2-2/2-2.4
kernel: hub 2-2.4:1.0: USB hub found
usbguard-daemon: Ignoring unknown UEvent action: sysfs_devpath=/devices/.../usb2/2-2/2-2.4 action=change
usbguard-daemon: USB Device Exception: SysFSDevice: (_sysfs_dirfd = open(...)) < 0: No such file or directory
kernel: usb 2-2.4: USB disconnect, device number 6
This appears to be a timing issue (Heisenbug).
- The kernel sends a UEvent for the parent hub and then the child hub.
- usbguard reads the child hub's UEvent from the netlink socket.
- usbguard attempts to verify the parent's sysfs path.
- If the kernel has not yet completed the sysfs directory population for the parent, or if usbguard hasn't finished processing the parent's own UEvent, the lookup fails.
- Enabling full debug logging (-d) slows down the daemon enough that the race is no longer hit, and the device enumerates correctly.
Steps to Reproduce
- Connect a nested USB 3.x hub topology to a system with authorized_default=0.
- Reboot the system multiple times.
- Observe that roughly 1 out of 6-10 reboots results in a child hub failing to authorize due to "unknown sysfs path."