You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With recent kernels (at least on Fedora), I have seen the USB root hubs change ports. If you have DeviceRulesWithPort=true (not the default) set in usbguard-daemon.conf, your USB root hubs will be disabled after rebooting to newer kernels.
Steps I followed
Have DeviceRulesWithPort=true (not the default) set in usbguard-daemon.conf
Update from kernel 6.2.7 to a newer version (tested with 6.2.8 and 6.2.9)
Reboot
What happens
Unable to use any USB root hub. If you have no other means (e.g. non-USB keyboard or SSH) to modify USBGuard configuration, you are locked out of your computer. It feels as if the login screen was frozen, but it is the USB devices (mouse, keyboard) not working.
On a technical level: The USB root hubs (EHCI Host Controller or xHCI Host Controller) get different ports assigned. The value of via-port changes between kernel versions, e.g. from usb1 to usb2 or vice versa.
What should happen
I'm not entirely sure as I think that this is intended behavior. One could discuss whether it makes sense to have the ports of USB root hubs (via-port) stored or not as this order is probably defined by software (kernel) only. This order might even be inconsistent between kernel sessions (reboots), as it might depend on timing, i.e., be non-deterministic.
Workarounds
I found workarounds while keeping the non-default setting DeviceRulesWithPort=true.
Option 1: Reboot into your older kernel
Boot with older kernel (from grub menu)
Open /etc/usbguard/rules.conf as root
Remove via-port "usb[N]" from your host controllers, with N being any number
Reboot into newer kernel
Option 2: Use a live media
(More complicated, will not list detailed steps here). Reboot into live media of your linux distribution, chroot into the filesystem and modify settings in usbguard-daemon.conf to allow all USB devices. Then reboot into your regular system and set up USBGuard again.
Affected software versions
usbguard-1.1.0-4.fc37.x86_64
kernel-6.2.7-200.fc37.x86_64 : The last kernel with old root hub order
kernel-6.2.9-200.fc37.x86_64 : Root hub order changed again
Additional information
This issue may or may not be specific to Fedora's linux kernels as they are doing some patching. See Fedora 37's linux kernel changelog for details on the changes.
I have seen this issue on 2 different devices (different hardware, rather old devices), both running Fedora 37.
The text was updated successfully, but these errors were encountered:
With recent kernels (at least on Fedora), I have seen the USB root hubs change ports. If you have
DeviceRulesWithPort=true
(not the default) set inusbguard-daemon.conf
, your USB root hubs will be disabled after rebooting to newer kernels.Steps I followed
DeviceRulesWithPort=true
(not the default) set inusbguard-daemon.conf
What happens
Unable to use any USB root hub. If you have no other means (e.g. non-USB keyboard or SSH) to modify USBGuard configuration, you are locked out of your computer. It feels as if the login screen was frozen, but it is the USB devices (mouse, keyboard) not working.
On a technical level: The USB root hubs (EHCI Host Controller or xHCI Host Controller) get different ports assigned. The value of
via-port
changes between kernel versions, e.g. fromusb1
tousb2
or vice versa.What should happen
I'm not entirely sure as I think that this is intended behavior. One could discuss whether it makes sense to have the ports of USB root hubs (
via-port
) stored or not as this order is probably defined by software (kernel) only. This order might even be inconsistent between kernel sessions (reboots), as it might depend on timing, i.e., be non-deterministic.Workarounds
I found workarounds while keeping the non-default setting
DeviceRulesWithPort=true
.Option 1: Reboot into your older kernel
/etc/usbguard/rules.conf
as rootvia-port "usb[N]"
from your host controllers, withN
being any numberOption 2: Use a live media
(More complicated, will not list detailed steps here). Reboot into live media of your linux distribution, chroot into the filesystem and modify settings in
usbguard-daemon.conf
to allow all USB devices. Then reboot into your regular system and set up USBGuard again.Affected software versions
Additional information
This issue may or may not be specific to Fedora's linux kernels as they are doing some patching. See Fedora 37's linux kernel changelog for details on the changes.
I have seen this issue on 2 different devices (different hardware, rather old devices), both running Fedora 37.
The text was updated successfully, but these errors were encountered: