CVE-2026-23446: aqc111 USB Ethernet suspend deadlock and Linux fix

Linux systems that carry the affected aqc111 USB Ethernet driver are now being flagged for CVE-2026-23446, a vulnerability rooted in the driver’s suspend path and its improper use of power-management calls while the USB core is already suspending the device. The kernel-side fix is straightforward but important: replace PM-aware command helpers with their _nopm variants so the suspend callback no longer tries to wake a parent device that is in the middle of a system transition. That matters because the bug can deadlock the networking stack by hanging in rpm_resume, a failure mode that is especially nasty on hosts where the affected adapter is part of the main network path. The public description and NIST record both frame this as a stability-and-availability issue rather than a classic code-execution bug, with a published CVSS 3.1 score of 5.5 and a Linux kernel fix already tied to stable branches.

Overview​

This CVE is a good reminder that not every serious Linux vulnerability looks dramatic at first glance. In this case, the problem is not a buffer overflow, a privilege escalation chain, or a memory corruption primitive in the usual sense. It is a power-management recursion bug: the driver’s suspend callback calls into a helper that itself performs a runtime-PM operation, and that operation tries to resume a parent device that is already suspended, or in the middle of suspending, creating a wait state that can never complete. The Linux USB documentation explicitly warns that callbacks are mutually exclusive and that drivers must not perform a power-management operation that interferes with another driver bound to the same interface.
The published kernel description is unusually clear about the call chain. aqc111_suspend calls the PM variant of aqc111_write_cmd, which ends up in usb_autopm_get_interface, then pm_runtime_resume_and_get, and from there into rpm_resume. The problem is that the USB core is already in rpm_suspend, with the device in RPM_SUSPENDING, so the attempted resume can block forever waiting for a status change that will never arrive. In practice, that can tie up a thread holding rtnl_lock, which means the fallout is not confined to the USB adapter itself; it can stall the wider networking stack. The patched versions switch those command paths to non-PM helpers, removing the reentrant power-management call from the suspend callback entirely.
What makes this issue notable is that it sits at the boundary between driver correctness and system-wide availability. USB network adapters are often treated as peripheral devices, but in laptops, compact desktops, embedded appliances, and lab systems, they can be the only network interface available. A suspend-time deadlock on that path is not a nuisance bug; it can become a full connectivity freeze during sleep transitions, docking events, or power-state changes. That is exactly the kind of bug that operators remember only after the machine becomes unresponsive at the wrong time.
There is also a broader lesson here about kernel design discipline. The simplest fixes are often the safest ones when the bug is caused by crossing the wrong boundary. Here, the right answer is not a more elaborate retry loop, a new lock, or a special exception in the PM core. It is to stop calling the PM-aware helper from within suspend and use the helper that does not try to change power state. That is a textbook example of fixing the control-flow mistake at the source rather than building a taller fence around it.

Background​

The aqc111 driver supports ASIX-based USB Ethernet hardware, which places it in a class of drivers that must work across many power-state transitions. USB networking is especially sensitive to suspend and resume sequencing because it depends on both the USB core and the network stack honoring the same lifecycle rules. When those assumptions break, the symptom may be a hang, a lost link, a failed resume, or a seemingly random freeze that only appears during low-power transitions.
USB driver callbacks are not just ordinary functions. The kernel documentation makes a point of separating probe, disconnect, suspend, resume, and device-level operations, and it warns that callbacks are mutually exclusive. That means a suspend callback must behave like a carefully bounded critical section, not like a normal code path that can trigger new PM transitions. The documentation is explicit that power-management operations should not interfere with another driver bound to the interface, which is exactly why a nested usb_autopm_get_interface call inside suspend is such a bad fit.
The rpm_resume hang described in the CVE is a classic example of a self-deadlocking lifecycle mismatch. The kernel is already executing a suspend transition, and the helper used by the driver tries to initiate a resume transition as part of its normal behavior. That is not a malformed packet, an attacker-controlled payload, or an exotic race. It is a state machine contradiction. Once the PM core decides the interface is transitioning downward, the driver should not ask it to move upward at the same time.
The impact of these bugs is often underestimated because they look local. Yet networking is one of the least local subsystems in the kernel. A blocked driver can hold a global lock, stall unrelated work, and delay user-visible events that depend on the networking stack making forward progress. The CVE description specifically notes that another task holding rtnl_lock can become blocked, which is why the entire network stack can appear locked even though the root cause started in a USB PM callback.
This is also why the kernel community treats seemingly small suspend-path bugs seriously. Stability bugs in PM code often become maintenance bugs for downstream vendors, because they are hard to reproduce, they are tied to specific hardware, and they can show up only on certain timing windows. The best fixes are the ones that are narrow enough to backport, obvious enough to audit, and conservative enough to fit long-term-support kernels without disturbing unrelated behavior. The published fix for CVE-2026-23446 fits that pattern well.

---

How the Bug Happens​

The failure chain is compact, but it is important to understand it in order. During usb_suspend_both, the USB core already knows the device is suspending. While that transition is in progress, aqc111_suspend is invoked for the interface. Instead of using a helper that assumes the device is already in the correct PM state, the driver calls into a variant that tries to acquire runtime-PM access. That call leads to pm_runtime_resume_and_get, which in turn invokes rpm_resume even though the parent device is already in RPM_SUSPENDING.
The problem is not merely that this is “inefficient” or “unwise.” It is that the resume path waits for a status change that cannot happen because the suspend path has not completed. In other words, the driver is asking the PM core to resolve a contradiction in real time. Once the kernel blocks in that state, the damage compounds quickly if another thread is waiting on networking infrastructure protected by rtnl_lock. That is how a local PM mistake escalates into a network-wide stall.

Why _nopm is the right replacement​

The fix replaces the PM-aware command helpers with their _nopm variants. That matters because those variants do the hardware interaction without trying to manipulate power state behind the suspend callback’s back. In kernel terms, this is a clean separation of concerns: the suspend callback handles suspend behavior, and the command helper handles register writes without recursively calling back into PM infrastructure.
This is also a good example of a fix that preserves intent. The driver still needs to send commands to the hardware as part of shutdown preparation, but it must do so without asking the PM layer to re-awaken a device that is already on the way down. The patch therefore changes the mechanism, not the feature. That is the hallmark of a stable-friendly fix.

• The bug is triggered during system suspend, not normal packet processing.
• The recursive PM call comes from a helper that should not have been used there.
• The deadlock can propagate into the broader networking stack.
• The fix is to use non-PM command helpers in suspend.
• The change is small, which improves backportability.

Why the hang is so disruptive​

A suspend-path hang is frustrating for consumers, but it is especially damaging in managed environments. If a server, thin client, or lab machine cannot transition cleanly through sleep or power-state handling, automation may misclassify the failure as a hardware issue, a BIOS issue, or a bad cable. That uncertainty lengthens mean time to repair and makes it harder to distinguish a driver bug from an environmental fault.
There is also the matter of lock contention. Once rtnl_lock enters the story, the bug ceases to be a narrow device-level issue. The networking stack is a shared dependency for link configuration, routing updates, interface management, and service discovery. Blocking it in a power-management path can have side effects that are disproportionate to the tiny patch that fixes the root cause.

---

What the Linux Documentation Says​

The USB callback documentation is almost a commentary on this CVE. It says the suspend callback is part of the PM lifecycle, that callbacks are mutually exclusive, and that drivers should not perform operations that interfere with another driver on the same interface. Those rules exist precisely because suspend and resume already involve subtle coordination between layers. Adding a nested PM call makes coordination much harder and can violate the assumptions the USB core depends on.
The same document also explains that once disconnect returns, no further I/O is allowed, and that pre_reset and post_reset have their own strict boundaries. The point is not just to catalog rules, but to prevent drivers from blurring lifecycle phases. CVE-2026-23446 is what happens when those boundaries are blurred in one of the most sensitive phases of all: suspend.

The suspend contract in practice​

In practice, suspend callbacks should be conservative. They should finish quickly, avoid unnecessary dependencies, and never create a dependency on a state transition that is already underway. That means if a driver needs to flush hardware state or write a last register, it should do so in a way that does not trigger runtime PM entry points that might try to reconfigure power. The _nopm helpers exist for exactly this kind of situation.
This is one reason the bug is relatively easy to understand after the fact, but also easy to miss during development. The helper name looks harmless, and the code path may work fine during normal operation. Only when suspend orchestration begins does the helper’s hidden PM behavior become dangerous. That is a timing-dependent correctness bug, not a simple functional defect.

• Suspend callbacks should not make nested PM transitions.
• USB lifecycle hooks are intentionally strict about sequencing.
• Helper choice matters as much as explicit locking.
• _nopm variants are a common way to avoid recursion.
• A clean callback boundary reduces the chance of deadlock.

---

Severity and Exploitability​

The current public record places CVSS 3.1 at 5.5 with a vector of AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H, which tells the story pretty well: local access, low complexity, low privileges, no user interaction, no confidentiality or integrity impact, but a high availability impact. In other words, this is not a code-execution vulnerability; it is a serious reliability problem that can still have major operational consequences.
That distinction matters because many administrators triage vulnerabilities only by whether they enable remote compromise. This one belongs in a different class. It is a kernel hang issue that can disrupt hosts during suspend and, by extension, any workflows that depend on clean power transitions. On laptops, edge systems, and managed workstations, that can be very visible to users. On infrastructure nodes, it can translate into service instability if the device is part of the management or uplink path.

What the CVSS score does and does not mean​

A medium score should not be read as “safe to ignore.” It means the impact is constrained in the way CVSS models it, not that the bug is operationally trivial. Availability-only bugs are often underweighted by teams that focus on confidentiality and integrity, yet in production the inability to resume or suspend cleanly can be every bit as damaging as a data exposure if it leads to outages, failed updates, or control-plane lockups.
The absence of a confidentiality or integrity vector also helps explain why the fix stayed so narrow. The kernel did not need to redesign the driver, add a new synchronization primitive, or alter user-visible behavior. It only needed to stop the helper from trying to change PM state inside the PM callback. That is the kind of patch that can be shipped quickly and backported across supported branches.

• Availability is the dominant risk here.
• The bug is locally triggerable rather than remotely weaponized.
• Impact is greatest where the adapter is operationally critical.
• The score is medium, but the outage potential is real.
• The remediation path is small and likely to backport cleanly.

Why local bugs still matter​

Kernel security discussions sometimes overfocus on remote exploitability. That is understandable, but it misses how often local bugs become the thing that ruins uptime. A local, low-complexity hang in a core subsystem can still create a major incident if it affects fleet-wide automation, login sessions, remote management, or recovery procedures. This CVE fits that pattern well.
It also matters that the affected code sits in a USB networking driver, which is often used in unpredictable environments. USB Ethernet dongles show up in travel kits, lab benches, rescue consoles, and field-deployed appliances. That means exposure is broader than the “attached peripheral” framing might suggest. A device class that looks niche can still be operationally central.

---

Enterprise Impact​

For enterprises, the main concern is not whether the bug is flashy; it is whether the host depends on the affected adapter during suspend/resume transitions. That is especially relevant for mobile workers, hot-desk fleets, field laptops, and compact systems that use USB Ethernet as their primary or fallback network path. If a machine hangs in suspend because the driver deadlocks the PM core, the cost is measured in lost productivity and support time.
Enterprises also need to think about fleet consistency. A kernel bug of this type might only affect a subset of machines with a particular adapter, a specific dock, or a particular USB topology. That makes it easy to miss in broad compliance scans. The machine may pass standard health checks while still being susceptible to a suspend-time lockup that appears only when someone closes a laptop lid or a management agent tries to enter low-power mode.

Operational risks for managed environments​

The operational risks are not just technical. They include support escalations, failed remote sessions, and incidents that look like flaky hardware when they are actually driver bugs. In a large deployment, those misdiagnoses can waste hours because the symptoms often appear only around power transitions rather than during ordinary traffic. That is why this kind of issue belongs on patch-management watchlists even if the severity number seems modest.
There is a second-order enterprise concern as well: if the driver freezes networking while the system is entering or leaving sleep, endpoint management tools may lose contact at exactly the wrong time. That can delay updates, interfere with remote support, and complicate compliance tracking. The CVE does not need to be a remote exploit to have high operational cost.

• Docked laptops may be more exposed than desktop systems.
• Remote management can fail if networking freezes during suspend.
• USB NICs are often the only interface on compact systems.
• Fleet imaging may miss the hardware-specific trigger.
• Helpdesk triage can misclassify the bug as flaky hardware.

Consumer impact​

For consumers, the most likely symptom is annoyance rather than a breach: a laptop that fails to sleep properly, a device that hangs during resume, or a USB Ethernet adapter that causes the whole system to lock up after a power transition. Those are still serious because they damage trust in the machine and can interrupt work, but they are not the sort of security failure most people instinctively associate with a CVE.
Consumers who use USB Ethernet for home office setups or travel docking are the most plausible at-risk group. If a machine depends on that adapter for connectivity and the adapter participates in suspend behavior, the bug can surface in ordinary day-to-day use. That is why driver bugs in peripheral networking code often end up feeling much more important in real life than they sound in a short advisory.

---

Patch Shape and Why It Matters​

The biggest virtue of this fix is its restraint. Instead of reaching deeper into the PM core or attempting to special-case the runtime state machine, the patch simply swaps the problematic command helpers for _nopm variants. That is exactly the kind of change maintainers prefer when the error is localized and the correction can be made at the call site.
That restraint also improves backportability. Small, obvious changes are easier to stabilize across supported trees because they are less likely to collide with adjacent power-management code or hardware quirks. The NVD record already ties the issue to multiple affected Linux kernel version ranges, and the presence of stable patch references indicates downstream maintainers treated the bug as a real production issue rather than an academic cleanup.

Why not add more locking?​

Adding more locking would be the wrong instinct here. The failure is not a race between two ordinary threads; it is a callback trying to force a conflicting PM transition while the framework is already suspending the device. More locking would not change the fact that the helper is fundamentally inappropriate inside that callback. In kernel engineering, the cleanest fix is often to remove the conflicting action entirely.
This is also a reminder that helper naming can be misleading to newcomers. A function that writes a register may still have side effects involving power management, depending on which wrapper you call. The _nopm suffix is the clue that the helper has been stripped of those transitions. That makes code review easier and reduces the chance of accidental recursion in sensitive paths.

• The patch changes behavioral plumbing, not feature logic.
• It avoids introducing new synchronization side effects.
• It is easy to explain and easier to backport.
• It reduces the chance of future suspend recursion.
• It keeps the hardware programming sequence intact.

How maintainers usually think about fixes like this​

Maintainers generally want three things in a PM-related fix: correctness, minimal scope, and low regression risk. This patch checks those boxes. It resolves the suspend deadlock, it affects only the specific helper call sites, and it leaves the broader device behavior alone. That is ideal for long-term stable branches, where broad behavioral changes can be more dangerous than the original bug.
It also sends a message to driver authors: if your suspend callback needs to talk to hardware, make sure the path does not secretly invoke the PM core again. That principle is simple, but the kernel accumulates bugs whenever developers violate it in one-off ways. CVE-2026-23446 is a case study in why those constraints exist.

---

Strengths and Opportunities​

This vulnerability is frustrating, but it is also one of the cleaner kinds of Linux kernel defects to remediate. The root cause is understandable, the affected behavior is narrow, and the fix preserves the intended hardware interaction while removing the recursive PM call. That combination makes it easier for vendors to backport and for administrators to verify.

• The bug is well localized to the aqc111 suspend path.
• The fix is small and surgical.
• The patch preserves the driver’s intended register writes.
• The issue is easy to explain to operators and support teams.
• The CVE creates a concrete target for regression testing.
• The Linux documentation already supports the fix’s design rationale.
• Stable branches can absorb the change with relatively low risk.

There is also an opportunity here for teams to review any custom kernel modules or out-of-tree USB drivers that use PM-aware helpers inside suspend callbacks. Problems of this shape often recur across different hardware families because the temptation is the same: reuse the normal helper everywhere. The safer approach is to distinguish between ordinary command issuance and command issuance during lifecycle transitions.

---

Risks and Concerns​

The main concern is that this kind of bug can be hard to notice until it hits the wrong device at the wrong moment. Users rarely think about suspend callbacks, and administrators do not always map USB NICs to critical infrastructure dependencies. That makes the issue easy to overlook even though the symptom can be a full networking stall.

• The trigger is timing-dependent, which makes reproduction inconsistent.
• Symptoms may be mistaken for generic networking or hardware problems.
• USB Ethernet adapters can be central to mobile and embedded systems.
• A blocked rtnl_lock can have broad collateral effects.
• Vendor kernel branches may lag upstream fixes.
• Suspend/resume bugs can evade routine validation.

A second concern is visibility. Because this is an availability issue rather than a headline-grabbing exploit, some teams will under-prioritize it until they see real failures. That is a mistake. When a device driver can deadlock the network stack during power transitions, the resulting downtime can be more expensive than many more sensational-seeming bugs.
A third concern is that systems with USB NICs in docks, rescue environments, or niche appliances may not be obvious in asset inventories. Those are exactly the systems where suspend/resume behavior is most likely to be important and where a bug like this can quietly degrade operational reliability. In security terms, the bug is narrow; the deployment surface is not.

---

Looking Ahead​

The immediate question is how quickly the fix reaches downstream kernels, not whether the upstream root cause is understood. The NVD entry already shows affected kernel version ranges and stable patch references, which is a strong sign that the issue is being treated as production-significant. The practical task for administrators is to confirm whether their supported kernel stream includes the correction, especially if they rely on USB Ethernet for primary connectivity.
The second thing to watch is whether vendors annotate the fix as a security update or fold it into a broader stability rollup. Either approach is fine from a technical standpoint, but the labeling affects prioritization. Security teams often move faster when a fix is clearly tied to a CVE, while operations teams may pay more attention when they see a suspend/resume regression being addressed in a kernel update.

What to monitor next​

• Downstream distribution advisories for backports
• Kernel stable trees that include the aqc111 suspend fix
• Reports of suspend hangs on USB Ethernet adapters
• Any follow-on cleanup in related USB network drivers
• Changes in how vendors label the update in security bulletins

There is also a larger architectural lesson worth watching. Kernel power-management code remains a place where small helper choices can trigger system-wide consequences. As more systems depend on low-power transitions for battery life, thermal efficiency, and operational convenience, the cost of these mistakes rises. That is why a modest-looking patch like this deserves attention well beyond the few lines it changes.
CVE-2026-23446 is not the kind of Linux bug that makes headlines for dramatic exploitation, but it is exactly the sort of bug that can make a real machine feel broken. The fix is small because the error is conceptual rather than complex: do not ask the power-management stack to resume a device while the system is already suspending it. That lesson is older than this driver and will outlast it, which is why the patch is important not only as a security update but as a reminder that kernel reliability still begins with respecting the lifecycle boundaries the platform already defines.

---

Source: NVD / Linux Kernel Security Update Guide - Microsoft Security Response Center