Cloudanix VulnDB

CVE-2026-23446

Medium · 5.5

CVSS

5.5

EPSS

0.1%

Published

Apr 3, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in how certain USB network adapters handle power-saving on Linux can freeze the entire network system, requiring a reboot to recover.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

The aqc111_suspend callback invokes the PM-aware write_cmd path, which calls usb_autopm_get_interface and triggers rpm_resume on a device whose runtime_status is already RPM_SUSPENDING, producing a deadlock that blocks rtnl_lock and stalls the networking stack.

Why it matters to the business

Local users or automated power-management events can cause a complete, unrecoverable hang of the network stack on affected Linux systems, leading to loss of connectivity, disrupted services, and the need for manual reboot.

How an attack unfolds

An attacker with local access triggers a USB suspend event on an aqc111-based device while holding or contending for rtnl_lock; the resulting recursive PM call blocks indefinitely, locking the entire networking subsystem.

How to fix it

Apply the upstream fix that replaces aqc111_write32_cmd and related calls inside aqc111_suspend with their _nopm variants; update to a Linux kernel release containing the resolution once available.

How to confirm the fix worked

Confirm the source file drivers/net/usb/aqc111.c no longer contains PM-variant write calls inside the suspend callback, and verify the device resumes and suspends cleanly without task hangs under repeated runtime PM cycles.

Typical attack path

  1. Obtain local execution on a Linux system with an aqc111 USB Ethernet device
  2. Force or wait for a runtime suspend transition on the USB interface
  3. Invoke network operations that acquire rtnl_lock concurrently
  4. Observe indefinite hang of the networking stack

How to detect it

Search kernel logs and task dumps for hung tasks involving rpm_resume, rpm_suspend, and aqc111_write routines during USB suspend events; correlate with rtnl_lock contention traces.

What your security team should do

  • Prioritize kernel updates for systems exposing aqc111 hardware once patches are released
  • Restrict unprivileged local access on multi-user systems until fixed kernels are deployed
  • Monitor kernel bug trackers for the merged commit and backported stable updates

The record

In the Linux kernel, the following vulnerability has been resolved: net: usb: aqc111: Do not perform PM inside suspend callback syzbot reports "task hung in rpm_resume" This is caused by aqc111_suspend calling the PM variant of its write_cmd routine. The simplified call trace looks like this: rpm_suspend() usb_suspend_both() - here udev->dev.power.runtime_status == RPM_SUSPENDING aqc111_suspend() - called for the usb device interface aqc111_write32_cmd() usb_autopm_get_interface() pm_runtime_resume_and_get() rpm_resume() - here we call rpm_resume() on our parent rpm_resume() - Here we wait for a status change that will never happen. At this point we block another task which holds rtnl_lock and locks up the whole networking stack. Fix this by replacing the write_cmd calls with their _nopm variants

Affected packages

Ecosystem Package Introduced Fixed