CVE-2026-46073

What it actually does

CVE-2026-46073 is a local Linux kernel denial-of-service flaw in the powerz hardware monitoring USB driver. When wait_for_completion_interruptible_timeout() is interrupted by a signal, it returns a negative value, but the affected code only handled the timeout case. As a result, the driver could continue as if data had been received, fail to cancel the outstanding USB request block, and read from an unfilled transfer buffer. In practical terms, a local user with access to the affected hwmon/USB device path may be able to trigger invalid kernel-side behavior that can degrade availability, potentially causing driver malfunction, kernel warnings, hangs, or system instability depending on kernel configuration and runtime conditions.

Why it matters to the business

The primary risk is interruption of systems that use affected Linux kernels with the powerz USB hardware monitoring driver and compatible devices. Exploitation requires local access and is not known to be exploited in the wild, with a very low EPSS score and no CISA KEV listing, so broad internet-scale risk is low. However, for workstations, lab systems, embedded Linux devices, monitoring hosts, or operational systems that rely on USB power-monitoring hardware, a local user or compromised low-privilege account could cause downtime or instability, leading to service disruption, failed monitoring, or operational delays.

How an attack unfolds

An attacker first obtains local code execution or an interactive low-privilege account on a Linux system running an affected kernel with the powerz hwmon USB driver available. The attacker identifies whether the relevant hardware monitoring device is present and accessible through kernel-exposed interfaces such as hwmon, sysfs, or related device nodes. They then trigger a read or operation that submits a USB request and deliberately interrupt the waiting task with a signal before the request completes. Because the vulnerable code mishandles the negative interrupt return value, it does not properly abort the USB request and proceeds to consume an unfilled transfer buffer. Repeating this pattern can destabilize the driver or kernel path, causing denial of service symptoms such as device malfunction, kernel errors, hangs, or system instability. There is no indication from the provided data that remote unauthenticated exploitation, privilege escalation, or data theft is expected.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for the powerz hwmon driver issue. Because no exact fixed package versions were provided, use the fixed kernel packages from the relevant Linux distribution or vendor advisory once available. Prioritize systems where untrusted users have shell access, where USB hardware monitoring devices are attached, or where the powerz driver is enabled. If immediate patching is not possible, reduce exposure by removing or disabling access to affected USB power-monitoring devices, unloading or blacklisting the powerz driver if not required, restricting local user access to hwmon/sysfs/device nodes through standard permissions and udev rules, and limiting untrusted local execution on affected hosts.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package includes the vendor or upstream patch for the powerz hwmon driver. Check the active kernel version with uname -r and compare it against the distribution’s fixed kernel advisory. Confirm whether the driver is present or loaded using lsmod, modinfo, or kernel module inventory tools, and verify whether compatible USB hwmon devices are attached. Where feasible in a non-production test environment, reproduce the interrupted-read condition before and after patching to confirm the patched kernel aborts the URB and returns an error instead of continuing to use an unfilled transfer buffer. Also confirm that any temporary mitigation, such as module blacklisting or device access restriction, remains in effect after reboot.

Typical attack path

1. Gain local access to a Linux system running an affected kernel.
2. Determine whether the powerz hwmon USB driver is loaded or the relevant USB hardware monitoring device is attached.
3. Access the exposed hwmon/sysfs/device interface as an allowed local user.
4. Start an operation that causes the driver to wait for USB transfer completion.
5. Interrupt the waiting operation with a signal before completion.
6. Trigger the vulnerable error path where the driver fails to call usb_kill_urb() and reads from an unfilled transfer buffer.
7. Repeat as needed to cause driver instability, kernel errors, hangs, or system denial of service.

How to detect it

Look for evidence of local attempts to stress or interrupt reads from the powerz hwmon USB driver. Useful sources include kernel logs from dmesg or journald, syslog files such as /var/log/kern.log and /var/log/messages, auditd records for access to sysfs or USB device nodes, process accounting, and EDR telemetry showing repeated signals sent to processes interacting with hwmon interfaces. Focus on systems where the powerz driver is loaded or where compatible USB power-monitoring devices are attached. Indicators may include repeated kernel messages involving powerz, hwmon, USB URB failures, interrupted transfers, hung tasks, kernel warnings, oopses, or device disconnect/reset loops around the time a local user process accessed /sys/class/hwmon, /sys/bus/usb, or related device paths. Since the vulnerability description does not provide a unique exploit string, detection should correlate abnormal local device access, repeated signal delivery, and kernel instability rather than rely on a single signature.

• powerz
• hwmon
• usb_kill_urb
• wait_for_completion_interruptible_timeout
• -ERESTARTSYS
• URB
• /sys/class/hwmon
• /sys/bus/usb
• /var/log/kern.log
• /var/log/messages
• kernel:.*powerz
• kernel:.*hwmon
• kernel:.*URB
• kernel:.*usb
• kernel:.*hung task
• kernel:.*Oops
• kernel:.*WARNING

What your security team should do

• Inventory Linux systems for affected kernel versions and determine whether the powerz hwmon driver or compatible USB monitoring devices are present.
• Prioritize patching on multi-user systems, developer workstations, lab systems, embedded Linux platforms, and operational hosts where local users or workloads are not fully trusted.
• Deploy vendor-provided fixed kernel updates during the next maintenance window, or sooner for systems where the driver is loaded and local access is broadly available.
• If patching is delayed, unload or blacklist the powerz driver where it is not operationally required.
• Restrict local access to relevant hwmon, sysfs, and USB device interfaces using least-privilege permissions and udev rules.
• Monitor kernel logs for USB, hwmon, powerz, URB, timeout, signal-interrupt, warning, hang, or oops messages that could indicate attempted triggering or instability.
• Because this issue is not in CISA KEV, has no known exploit maturity, and has very low EPSS, treat it as a targeted local availability risk rather than an urgent internet-facing emergency.