CVE-2026-31721: Linux USB HID gadget lifetime bug and the bind/unbind fix

On May 1, 2026, kernel.org published CVE-2026-31721, a medium-severity Linux kernel vulnerability in the USB gadget HID function where rebinding a gadget could corrupt kernel list state after an epoll-registered /dev/hidg0 file descriptor survived the unbind-and-bind cycle. The bug is not a remote code execution barn-burner, nor is it likely to trouble ordinary desktop users. But it is exactly the kind of lifecycle flaw that matters in embedded Linux, test rigs, Android-adjacent development, USB device emulation, and appliance-style systems where “local-only” does not always mean “low-risk.” The lesson is less about one HID gadget driver than about a recurring kernel truth: objects that outlive a device binding must not be initialized as though they die with it.

The Vulnerability Lives in the Space Between “Configured” and “Gone”​

CVE-2026-31721 sits in the Linux USB gadget subsystem, specifically the f_hid function driver that lets a Linux system present itself to another machine as a USB Human Interface Device. In plainer English, this is the machinery that allows a board, phone, test fixture, or embedded Linux device to behave like a USB keyboard, mouse, joystick, barcode scanner, or other HID-class peripheral.
That immediately narrows the affected world. This is not the same thing as plugging a malicious keyboard into your Windows laptop. It is about Linux machines that act as USB devices rather than USB hosts, and about software that opens /dev/hidg0, watches it through epoll, and then survives a USB Device Controller unbind and rebind operation.
The reported sequence is precise: set up and bind an HID gadget, open /dev/hidg0, add the file descriptor to epoll, unbind the UDC, bind it again, and then remove the file descriptor from epoll. With CONFIG_DEBUG_LIST enabled, the kernel reported list corruption inside remove_wait_queue, reached through epoll’s cleanup path.
That path matters because epoll is not a decorative detail. It is the standard Linux mechanism that serious event-driven software uses to watch file descriptors efficiently. If the kernel object backing a file descriptor is partially reset while user space still holds a reference to it, the kernel has turned a legitimate programming pattern into a trapdoor.

A Medium CVSS Score Can Still Point at a Real Kernel Bug​

NVD assigned CVE-2026-31721 a CVSS 3.1 base score of 5.5, with local attack vector, low attack complexity, low privileges required, no user interaction, unchanged scope, no confidentiality impact, no integrity impact, and high availability impact. That vector tells a straightforward story: an attacker needs local access, but if they can trigger the vulnerable path, the plausible security consequence is denial of service rather than data theft or privilege escalation.
That is a sensible rating on the public evidence. The bug as described is list corruption detected under a debug configuration, and the reported failure flows through cleanup of wait queues associated with polling. There is no public indication in the CVE text that this is a ready-made arbitrary write primitive, a kernel address leak, or a known route to root.
But CVSS can flatten the operational reality. “Local” on a developer workstation is one thing; “local” on a multi-tenant appliance, a kiosk, a lab controller, a compromised container host, or a production embedded device is another. Many systems that expose gadget functionality are not general-purpose laptops with one trusted user sitting at the keyboard.
Availability also has different meanings depending on the device. Crashing a lab board is an annoyance. Crashing a USB-connected medical peripheral, an industrial programming fixture, an access-control emulator, or a factory test station can interrupt a workflow that assumes the Linux gadget endpoint is boring plumbing. Kernel bugs in boring plumbing are often the ones administrators discover only after they have already caused downtime.

The Root Cause Is an Object Lifetime Mismatch​

The fix is conceptually small: move list and spinlock initialization from hidg_bind to hidg_alloc. In kernel terms, that is not a cosmetic refactor. It changes the lifetime boundary of internal synchronization and queue structures so they are initialized when the HID function instance is allocated, not each time the function is bound to a USB Device Controller.
The old behavior effectively treated bind as a safe moment to initialize wait queues and related state. That assumption breaks if user space still holds a file descriptor whose polling machinery has registered itself with those queues. Reinitializing a wait queue while it still contains entries is like replacing the guestbook while guests are still signing out; the next removal operation no longer sees the structure it expects.
The CVE text says the problematic queues were registered through poll_wait. That is the bridge between the HID gadget file descriptor and epoll. User space asks the kernel to notify it when the file descriptor is ready; the kernel records wait queue entries; later, epoll removes those wait queue hooks. If a bind operation reinitializes those queues in the middle, epoll’s cleanup may attempt to delete a list entry from a list that has been reset underneath it.
That is why CONFIG_DEBUG_LIST saw corruption in list_del. Debug-list checking is designed to catch list manipulation bugs early and loudly. Without that debug configuration, the same conceptual bug may not produce such a tidy diagnostic; it may instead manifest as a crash, warning, or harder-to-reproduce memory corruption symptom.

USB Gadget Bugs Rarely Map Cleanly to Desktop Risk​

WindowsForum readers may wonder why a Linux USB gadget CVE belongs in their threat model at all. The answer is not that Windows PCs are directly vulnerable to this kernel flaw. They are not, unless they are running an affected Linux kernel in a role that exposes the vulnerable gadget function.
The relevance is the ecosystem around Windows. IT shops increasingly use Linux boards, appliances, imaging rigs, development kits, phones, hypervisors, and USB test devices alongside Windows fleets. A Windows admin may never compile f_hid, but the provisioning station on the bench, the ARM board used for device testing, or the embedded product plugged into a Windows validation host may rely on it.
USB HID is also a class that security teams watch closely because HID devices are inherently trusted by hosts in ways that mass storage devices no longer are. A keyboard-looking device can type. A mouse-looking device can move. A test harness that emulates HID input is powerful by design.
CVE-2026-31721 is not an attack against the host that receives HID input. It is a bug in the Linux gadget device itself. Still, the same environments that use HID emulation tend to be environments where automation, privilege, physical connectivity, and “temporary” local access blur together.

The Affected Version Matrix Is Broad, but Not Uniform​

NVD’s initial analysis listed multiple affected Linux kernel ranges. The entries span long-term and stable series, including ranges from 3.19 up to fixed 5.10 builds, 5.11 through fixed 5.15 builds, 5.16 through fixed 6.1 builds, 6.2 through fixed 6.6 builds, 6.7 through fixed 6.12 builds, 6.13 through fixed 6.18 builds, and 6.19 through fixed 6.19 builds. It also listed 7.0 release candidates from rc1 through rc6.
That range looks alarming at first glance, but kernel CVE ranges often do. Linux maintains many stable trees, and once a bug is backported, the fixed version number differs by branch. A system on a vendor kernel may also carry the fix without advertising the exact upstream stable version NVD lists.
The practical question for administrators is not “does my version number appear somewhere in a scary range?” It is “does my running kernel include the relevant f_hid fix, and does my configuration expose the vulnerable code path?” That distinction matters because distro kernels are patched, backported, configured, and branded in ways that make raw upstream version comparison unreliable.
A Red Hat, Ubuntu, Debian, SUSE, Android, Yocto, OpenWrt, or appliance vendor kernel can carry patches independently of upstream point-release numbering. Conversely, a self-built kernel that looks new enough in spirit may still lack a backport if it sits on an older branch. Version strings are clues, not verdicts.

Local Access Is Not the Same as Physical Access​

The CVSS vector marks the vulnerability as local. That should not be read as “someone must be standing in front of the device with a screwdriver.” In Linux security language, local generally means code execution on the affected machine, not necessarily hands-on physical proximity.
For a USB gadget system, local code execution can come from many places. It might be a developer shell on a board. It might be a service account running a test controller. It might be a container with access to gadget configuration paths. It might be an automation script allowed to bind and unbind UDCs as part of device-mode testing.
That does not make the vulnerability remotely exploitable. It does mean administrators should evaluate it through the lens of who can manipulate gadget state and who can open /dev/hidg0. If untrusted or semi-trusted users can do both, the vulnerability is more interesting than its “local” label suggests.
Linux gadget configuration commonly involves ConfigFS, device nodes, permissions, and sometimes custom init scripts or daemons. The security boundary is rarely just the kernel version. It is also the operational wrapper around gadget setup and teardown.

Epoll Turns a Stale File Descriptor Into a Kernel-Lifetime Test​

The trigger sequence in the CVE is revealing because it depends on holding a file descriptor across a device lifecycle transition. That is a common stress point in kernel code. User space sees a file descriptor as a stable handle until it closes it; device code may see bind and unbind as moments when hardware-facing state is created and destroyed.
The kernel’s job is to reconcile those two models. A file descriptor should not become a dangling promise just because the underlying hardware state changed. If a device is unplugged, unbound, reset, or reconfigured, cleanup paths must still be safe for the objects user space already holds.
Epoll makes these bugs easier to expose because it stores interest in readiness events. It does not merely call read or write once. It asks the kernel to maintain relationships between an epoll instance, a watched file, and the wait queues that signal readiness. Those relationships often outlive the moment that created them.
That is why moving initialization to allocation is the right kind of fix. The wait queues and locks belong to the function instance’s lifetime, not to each bind operation. Resetting them on bind was effectively pretending the object had been freshly born when parts of the system still remembered its previous life.

Debug Kernels Are the Canary, Not the Problem​

The CVE description says the corruption was reported when CONFIG_DEBUG_LIST was enabled. Some readers will be tempted to downgrade the issue mentally: if debug builds catch it, perhaps production builds are fine. That is the wrong lesson.
Debug options in the kernel often turn silent corruption into visible failure. They add checks, poison values, assertions, and validation that make misuse of internal structures easier to diagnose. A debug warning is not evidence that the bug exists only in debug mode; it is often evidence that debug mode caught the production bug before it had a chance to become mysterious.
In this case, the core issue is reinitializing kernel list-backed wait queues while entries may still exist. That is a logic bug independent of the diagnostic feature that noticed it. Production behavior may vary by timing, architecture, compiler, workload, and surrounding memory layout.
Security teams should therefore treat CONFIG_DEBUG_LIST as the witness, not the culprit. The presence of a clean crash report is a gift. Many kernel lifecycle bugs are far less polite.

The Fix Is Small Because the Contract Was Wrong​

One reason this CVE is interesting is that the patch does not appear to introduce a new validation layer, permission check, or elaborate mitigation. It relocates initialization. That makes it a classic kernel maintenance fix: the code was doing the right operation at the wrong lifetime boundary.
Moving list and spinlock initialization from bind to alloc aligns the data structures with the lifetime of the function instance. Bind and unbind can then come and go without destroying the bookkeeping that epoll and poll paths may still depend on. The change is technically modest, but semantically important.
This is the kind of fix that rarely gets mainstream attention because it lacks drama. There is no branded vulnerability name, no logo, no widespread exploit kit, no urgent desktop pop-up. Yet these small lifetime repairs are how kernels become less crash-prone over time.
They are also why backports matter. A mature long-term kernel is not secure because it is old; it is secure because maintainers keep moving these small but consequential fixes into branches that real products still run.

The CPE Question Is Less Simple Than It Looks​

The NVD entry includes a familiar prompt: “Are we missing a CPE here?” That is not just bureaucratic boilerplate. For Linux kernel CVEs, CPE mapping is inherently awkward because the upstream kernel is not what most users install directly.
NVD can list linux:linux_kernel ranges, but deployed systems are usually distribution kernels, vendor BSPs, Android common kernels, appliance kernels, cloud images, NAS firmware, router firmware, or embedded builds derived from upstream at various points. A single upstream fix may land in dozens of downstream packages with different names, version numbers, and advisories.
So yes, in a broad operational sense, CPEs are often missing for Linux kernel vulnerabilities. But adding every downstream product CPE is not trivial and may even mislead if the product kernel has backported the fix while retaining an older version string. The more useful inventory signal is whether the running kernel contains the relevant stable patch.
For vulnerability management teams, this is where scanner output should be treated as a starting point. A raw CPE hit on an upstream kernel range should trigger vendor-advisory checks, package changelog review, or direct patch verification. It should not automatically trigger panic, nor should it be dismissed because the device is “just embedded Linux.”

Containers Do Not Magically Contain Kernel Attack Surface​

CVE-2026-31721 is not primarily a container story, but modern Linux administration makes almost every local kernel bug at least container-adjacent. Containers share the host kernel. If a container has unusual device access, elevated capabilities, or access to gadget configuration interfaces, the neat boundary between container workload and host kernel narrows quickly.
Most ordinary containers will not be able to configure USB gadget functions or open /dev/hidg0. That is good. But purpose-built containers for hardware testing, CI labs, embedded flashing, phone automation, or USB emulation often run with device mounts and privileges that would make a security purist wince.
The lesson is not that every container host is exposed. It is that “local privileged-ish hardware container” is a real deployment pattern, especially outside traditional data centers. The closer a workload gets to USB gadget setup, ConfigFS, UDC binding, and HID device nodes, the more relevant this bug becomes.
Administrators should look for exceptions, not averages. The average web container does not matter here. The one privileged lab container controlling USB gadget mode might.

Windows Shops Should Track the Linux Underlay They Forgot They Own​

A Windows-heavy organization can still own a surprising amount of Linux kernel exposure. Hyper-V hosts may run Linux guests. Windows developers may rely on WSL, though WSL’s applicability to this specific gadget path is limited by how USB gadget hardware is exposed. Endpoint teams may manage imaging appliances, security testing devices, Raspberry Pi-class controllers, NAS boxes, Android devices, and Linux-based USB tools.
The practical Windows angle is asset awareness. If a device in the Windows ecosystem can pretend to be a USB HID peripheral, someone should know what kernel it runs and how it receives security updates. That is doubly true for devices used in provisioning, authentication testing, keyboard injection testing, point-of-sale workflows, or factory automation.
Many of these systems are treated as tools rather than computers. They sit under desks, in labs, on carts, in racks, or behind monitors. They run for years. Their kernel patch cadence is often “when the image gets rebuilt,” which may mean never.
CVE-2026-31721 will not be the vulnerability that forces every IT department to inventory lab boards. But it is a useful reminder that kernel attack surface follows function, not corporate org charts. If the device can emulate a keyboard, it is part of your security environment whether or not it runs Windows.

Patch Management Should Follow Capability, Not Headlines​

The right response to CVE-2026-31721 is measured. Systems that do not enable or expose the HID gadget function are unlikely to have meaningful exposure. Systems that do should receive a patched kernel through their normal vendor or stable-kernel update channel.
For upstream stable users, the NVD change history indicates fixes across multiple kernel branches, including fixed points such as 5.10.253, 5.15.203, 6.1.169, 6.6.135, 6.12.81, 6.18.22, and 6.19.12, with 7.0 release candidates also called out as affected. The exact answer for a distro or appliance, however, depends on backports.
Administrators should avoid the common mistake of comparing only uname -r to upstream stable versions. Enterprise and embedded vendors frequently backport security fixes while preserving older base version numbers. The more reliable route is to check the vendor security advisory, package changelog, or source package patch list.
Where vendor information is absent, test and staging systems can help. If the gadget HID function is central to a product or workflow, reproduce the bind, epoll, unbind, rebind, epoll-delete sequence under a debug or instrumented kernel. That is not a substitute for patching, but it can clarify whether a custom kernel tree has incorporated the lifetime fix.

The Most Important Risk Signal Is Who Can Rebind the Gadget​

The exploit prerequisites embedded in the description are operationally specific. An attacker or buggy local program must be able to set up and bind an HID gadget, open /dev/hidg0, register the file descriptor with epoll, unbind the UDC, bind it again, and then manipulate the epoll registration. That is not the same as merely having an unprivileged shell on a normal Linux desktop.
Permissions around ConfigFS, UDC binding, and /dev/hidg0 are therefore central. If only trusted root-owned services can perform gadget lifecycle operations, the bug is more likely to be triggered by reliability faults than by adversarial users. If less-trusted automation can do it, the security concern rises.
Embedded products often blur those boundaries. Scripts run as root because it was easiest. Test daemons expose control sockets. Web UIs trigger USB mode changes. Factory workflows grant broad permissions to avoid interrupting production. Each shortcut turns a kernel-local bug into a more reachable failure mode.
This is where security review can be productive even before patches land. Tightening who can bind and unbind UDCs, who can access HID gadget nodes, and which services run with broad capabilities reduces exposure not just to this CVE, but to the next gadget subsystem bug as well.

The Bug Also Shows Why Hotplug Paths Deserve Hostile Testing​

USB gadget lifecycle code lives in a world of attach, detach, bind, unbind, suspend, resume, reconfigure, and teardown. Those are precisely the transitions where kernel bugs like to hide. Steady-state I/O can be well-tested while teardown paths remain under-exercised.
The reported trigger combines a long-lived user-space reference with a device lifecycle transition. That is a pattern worth testing across kernel subsystems, not just USB HID gadgets. Open a device, register it with epoll, tear down or reconfigure the backing device, bring it back, then clean up the old user-space state. If that sequence sounds unfair, remember that production systems do unfair things constantly.
Robust kernel code must assume user space will keep file descriptors open longer than expected. It must assume epoll registrations will survive device state changes. It must assume teardown will race with observers. The job is not to make the happy path fast; it is to make the unhappy path safe.
CVE-2026-31721 is therefore a good regression-test candidate. The sequence in the disclosure is concrete enough to automate, and it targets a class of lifetime bugs that can reappear when code is refactored.

The Patch Tells a Bigger Story About Kernel CVEs in 2026​

The Linux kernel’s CVE process has become more formal and more visible, which means administrators are seeing more kernel CVEs that look like fixed commits rather than traditional incident reports. Some are severe. Some are obscure. Many are somewhere in between: real bugs, plausible security impact, narrow triggers, and fixes already moving through stable trees.
That can create alert fatigue. A medium local kernel CVE in a subsystem you do not use is easy to ignore. But the correct response to the rising volume is not cynicism; it is better triage. Kernel CVEs need to be sorted by reachable attack surface, deployed configuration, privilege boundary, and vendor patch status.
CVE-2026-31721 is a useful example because it is neither sensational nor meaningless. It has a specific trigger, a clear fix, a plausible availability impact, and a narrow but real population of affected systems. That is exactly the sort of vulnerability mature IT teams should be able to process without drama.
The worst outcome would be treating every kernel CVE as an emergency. The second-worst outcome would be treating every non-critical kernel CVE as noise. The professional response lives in between.

The HID Gadget Fix Leaves a Short Checklist Behind​

For most WindowsForum readers, the actionable part of CVE-2026-31721 is not writing an exploit or reading kernel list macros. It is identifying whether any Linux systems under your care use USB gadget HID mode and whether their kernels have received the stable fix. The bug is narrow enough for targeted triage, but concrete enough that ignoring it on gadget-heavy systems would be sloppy.

• Systems that do not use Linux USB gadget HID functionality are unlikely to face practical exposure from this specific flaw.
• Systems that expose /dev/hidg0 and allow UDC bind or unbind operations should be prioritized for kernel updates or vendor firmware updates.
• Version checks should account for downstream backports, because distro and appliance kernels may contain the fix without matching upstream stable version numbers.
• Local access should be interpreted in terms of actual device permissions, not merely physical access to a machine.
• Privileged containers, hardware automation services, lab rigs, and embedded products deserve special attention if they control USB gadget state.
• The durable mitigation beyond patching is to restrict who can configure gadget functions, open gadget device nodes, and trigger USB controller lifecycle changes.

CVE-2026-31721 is not the kind of vulnerability that should send desktop users scrambling, but it should make kernel maintainers, embedded developers, and IT teams with Linux-powered USB tooling pay attention. The fix is a reminder that security often turns on mundane lifetime rules: initialize an object when it is born, not when one of its many operating modes happens to begin. As Linux continues to sit beneath Windows-adjacent tooling, appliances, labs, and devices, the organizations that fare best will be the ones that know where those kernels are, what roles they play, and which “local-only” bugs are local to something that matters.

---

References​

1. Primary source: NVD / Linux Kernel
   Published: 2026-05-19T01:41:59-07:00
   

   NVD - CVE-2026-31721

   nvd.nist.gov
2. Security advisory: MSRC
   Published: 2026-05-19T01:41:59-07:00
   Original feed URL
   

   Security Update Guide - Microsoft Security Response Center

   msrc.microsoft.com
3. Related coverage: spinics.net
   

   [PATCH] usb: gadget: f_hid: move list and spinlock inits from bind to alloc — Linux Kernel

   Linux Kernel: [PATCH] usb: gadget: f_hid: move list and spinlock inits from bind to alloc

   www.spinics.net
4. Related coverage: db.gcve.eu
   
   

   Vulnerability-Lookup

   Vulnerability-Lookup - Fast vulnerability lookup correlation from different sources.

   db.gcve.eu
5. Related coverage: opennet.dev
   
   Changelog in Linux kernel 6.18.22
6. Related coverage: opennet.ru
   
   Changelog in Linux kernel 6.1.169