Skip to content

Race Condition: "unknown sysfs path" during rapid hub enumeration leads to device rejection #689

@reinauer

Description

@reinauer

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

  1. The kernel sends a UEvent for the parent hub and then the child hub.
  2. usbguard reads the child hub's UEvent from the netlink socket.
  3. usbguard attempts to verify the parent's sysfs path.
  4. 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.
  5. 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

  1. Connect a nested USB 3.x hub topology to a system with authorized_default=0.
  2. Reboot the system multiple times.
  3. Observe that roughly 1 out of 6-10 reboots results in a child hub failing to authorize due to "unknown sysfs path."

Suggested Fix

PR#687

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions