CVE-2025-37800

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:LAttack vector, local

The vulnerable code is reached by read(2) on a sysfs file (`/sys/devices/**/uevent`) and the racing unbind via ioctl on `/dev/bus/usb/*`, both requiring a local account on the system. There is no network-facing path into `dev_uevent()`.

AC:LAttack complexity, low

The attacker controls both sides of the race: an unprivileged thread spins reading the world-readable `uevent` attribute while another thread toggles `USBDEVFS_DISCONNECT`/`USBDEVFS_CONNECT` (or CLAIM/RELEASE_INTERFACE) on the same USB interface, driving `dev->driver` between a valid pointer and NULL at will. No condition depends on state outside the attacker's influence, and the window can be retried indefinitely at high rate.

PR:LPrivileges required, low

`dev_attr_uevent` is DEVICE_ATTR_RW (0644), so any unprivileged local user can read it, and the usbfs disconnect/connect ioctls have no `capable()` check — only rw access to a `/dev/bus/usb` node, which udev `uaccess` rules routinely grant to the logged-in seat user. No root or capability is required.

UI:NUser interaction, none

The attacker performs both the sysfs read and the driver unbind from their own processes; no victim action is needed. On kiosk-style systems the routine hotplug churn that also triggers it happens without any deliberate user step.

S:UScope, unchanged

The fault and its consequences are confined to the kernel of the same host; no VM, IOMMU, or sandbox boundary is crossed.

C:HConfidentiality impact, high

If the driver is unregistered and its module unloaded after the pointer is loaded, `drv->name` is read from freed memory and the resulting dangling `char *` is expanded by `add_uevent_var(env, "DRIVER=%s", ...)` into the env buffer that `uevent_show()` copies back to the unprivileged reader — a use-after-free read that leaks arbitrary kernel memory contents to userspace. The fix's klist_drivers lock exists specifically to stop the driver structure disappearing mid-read.

I:NIntegrity impact, none

The racy path only loads `dev->driver` and formats `drv->name` into a bounded, kernel-allocated uevent buffer; it performs no attacker-influenced write to kernel memory and yields no control-flow hijack primitive.

A:HAvailability impact, high

Reloading `dev->driver` as NULL makes `dev->driver->name` a NULL-page dereference, and the freed-module variant faults on unmapped vmalloc memory — either way an oops in the driver-core read path, repeatable at will for a reliable local denial of service.