Kernel race condition when accessing authorized_default for a root hub

[tweksteen]

This is somewhat similar to #315 and #316 but I believe an issue at the kernel level. The logs from the bug:

15:32:25.327490+01:00  kernel: [85159.705987] xhci_hcd 0000:3e:00.0: xHCI Host Controller
15:32:25.327523+01:00  kernel: [85159.706005] xhci_hcd 0000:3e:00.0: new USB bus registered, assigned bus number 3
15:32:25.327529+01:00  kernel: [85159.707550] xhci_hcd 0000:3e:00.0: hcc params 0x200077c1 hci version 0x110 quirks 0x0000000000009810
15:32:25.327534+01:00  kernel: [85159.707922] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 4.19
15:32:25.327538+01:00  kernel: [85159.707928] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
15:32:25.327542+01:00  kernel: [85159.707933] usb usb3: Product: xHCI Host Controller
15:32:25.327552+01:00  kernel: [85159.707942] usb usb3: SerialNumber: 0000:3e:00.0
15:32:25.331464+01:00  kernel: [85159.709443] hub 3-0:1.0: USB hub found
15:32:25.331491+01:00  kernel: [85159.709467] hub 3-0:1.0: 2 ports detected
15:32:25.331497+01:00  kernel: [85159.711112] xhci_hcd 0000:3e:00.0: xHCI Host Controller
15:32:25.331500+01:00  kernel: [85159.711125] xhci_hcd 0000:3e:00.0: new USB bus registered, assigned bus number 4
15:32:25.331503+01:00  kernel: [85159.711137] xhci_hcd 0000:3e:00.0: Host supports USB 3.1 Enhanced SuperSpeed
15:32:25.331516+01:00  kernel: [85159.711239] usb usb4: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 4.19
15:32:25.331521+01:00  kernel: [85159.711245] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
15:32:25.331526+01:00  kernel: [85159.711250] usb usb4: Product: xHCI Host Controller
15:32:25.331531+01:00  kernel: [85159.711261] usb usb4: SerialNumber: 0000:3e:00.0
15:32:25.331534+01:00  kernel: [85159.712875] hub 4-0:1.0: USB hub found
15:32:25.331537+01:00  kernel: [85159.713133] hub 4-0:1.0: 2 ports detected
15:32:25.410558+01:00  usbguard-daemon[45662]: Device insert exception: SysFSDevice: authorized_default: No such file or directory
15:32:25.411063+01:00  upowerd[1824]: unhandled action 'bind' on /sys/devices/pci0000:00/0000:00:1d.6/0000:06:00.0/0000:07:02.0/0000:3e:00.0/usb4/4-0:1.0
15:32:25.411181+01:00  usbguard-daemon[45662]: SysFSDevice: authorized_default: No such file or directory
15:32:25.411286+01:00  upowerd[1824]: unhandled action 'bind' on /sys/devices/pci0000:00/0000:00:1d.6/0000:06:00.0/0000:07:02.0/0000:3e:00.0/usb3/3-0:1.0
15:32:25.411365+01:00  usbguard-daemon[45662]: Rejecting device at syspath=

USBGuard tries to configure the root hub shortly after it is being setup by the kernel. The authorized_default file is not found and it triggers an exception.

This is before #318 was merged so it may be the same issue. However, the sysfs fail on a specific file and not the parent directory. I've traced back how authorized_default is published by the kernel and when is the uevent for that bus generated. Compared to a standard USB device where the uevent is sent after sysfs is created, the authorized_default is only published after. I believe this is the race condition we observed. From the kernel source code:

(drivers/usb/core/hcd.c)
          /* starting here, usbcore will pay attention to this root hub */
          retval = register_root_hub(hcd);
          if (retval != 0)
                  goto err_register_root_hub;
          [...]

          retval = sysfs_create_group(&rhdev->dev.kobj, &usb_bus_attr_group);
          if (retval < 0) {
                  printk(KERN_ERR "Cannot register USB bus sysfs attributes: %d\n",
                         retval);
                  goto error_create_attr_group;
          }

where usb_bus_attr_group contains the definitions for authorized_default and interface_authorized_default.

The call chain from register_root_hub to generating the uevent is:

1. register_root_hub
2. (hub.c) usb_new_device
3. (drivers/base/core.c) device_add
4. kobject_uevent(&dev->kobj, KOBJ_ADD);

I'm reporting this here since USBGuard is the main userland consumer of that API. I will send a bug report to linux-usb@ to describe this issue and follow-up.

[tweksteen]

This is now fixed upstream: torvalds/linux@27709ae