CVE-2026-31724 is a medium-severity Linux kernel flaw published on May 1, 2026, affecting the USB gadget Ethernet Emulation Model function, where a network device can outlive its parent gadget device and leave broken sysfs links after unbind and rebind cycles. The bug is not a remote Windows exploit, and it is not a reason to panic-patch every desktop in sight. But it is a useful reminder that “medium” kernel bugs often live in the awkward space where embedded Linux, lab hardware, Android-derived builds, and Windows-adjacent development workflows quietly overlap. For WindowsForum readers, the story is less about a single dangling symlink than about how modern infrastructure increasingly depends on Linux kernels that Windows teams may not think they own.
The core of CVE-2026-31724 is almost comically narrow: a
The fix uses
NVD currently scores the issue as CVSS 3.1 5.5, a medium-severity local vulnerability with high availability impact. The vector matters: local access is required, no user interaction is needed, and the modeled impact is denial of service rather than confidentiality or integrity loss. This is not a remote code execution headline. It is a kernel robustness flaw in a subsystem that matters most to systems acting as USB devices rather than ordinary USB hosts.
That distinction is important because “USB bug” can sound broader than it is. Most Windows users think of USB from the host side: a laptop accepting keyboards, storage drives, webcams, or phones. Linux USB gadget code is the other side of the cable. It lets a Linux device present itself as something else over USB: an Ethernet adapter, serial device, storage function, MIDI interface, camera, or composite gadget.
That makes the vulnerability relevant to a different population than a typical desktop kernel bug. The likely affected systems are not ordinary Windows PCs; they are Linux devices that can be configured as USB peripherals and that load the relevant gadget function. The practical risk rises when an attacker can trigger gadget bind and unbind cycles or otherwise influence how the device’s USB function is reconfigured.
For sysadmins, the immediate question is not “Are my Windows endpoints vulnerable?” It is “Do I have Linux kernels in products, appliances, CI rigs, lab devices, kiosks, industrial controllers, Android-based hardware, or recovery environments that expose USB gadget networking?” In many organizations, that inventory is not owned by the same team that manages Windows Update or endpoint protection.
The Windows connection is still real. Windows fleets increasingly sit beside Linux-powered hardware: Surface-adjacent test benches, Hyper-V labs, WSL development environments, Azure appliances, security tooling, firmware flashing stations, and embedded devices managed from Windows workstations. A Linux CVE can therefore become a Windows operations problem without ever being a Windows vulnerability.
Sysfs is not merely a directory tree for humans. It is a userspace-facing projection of kernel device objects. Network managers, udev rules, monitoring agents, container runtimes, diagnostics scripts, and device-management tools all inspect it. When sysfs lies about where a device lives, the failure can ripple outward into automation that assumes device relationships are coherent.
The fix is not to remove the symlink after the fact. It is to maintain a valid parent-child relationship throughout the object’s lifecycle. Moving the
That is why the CVSS availability impact is plausible even though the visible symptom is a dangling link. Kernel device-model mistakes often show up as crashes, hangs, use-after-free patterns, broken hotplug flows, or userspace components waiting on events that no longer make sense. The CVE text does not claim privilege escalation or data exposure, but it does describe exactly the kind of lifecycle mismatch that kernel maintainers try hard to eliminate.
Security teams sometimes complain that this creates noise. They are not entirely wrong. A medium local DoS in a niche USB gadget function does not deserve the same response as an actively exploited remote vulnerability in a default network service. But dismissing these records as mere bookkeeping is also a mistake, especially for organizations that ship or manage Linux-based devices.
The value of CVE-2026-31724 is not that every admin must memorize
There is also a timing wrinkle. The NVD entry was published on May 1, 2026, and modified on May 7, 2026, with affected Linux kernel CPE ranges later attached. That means the record moved from initial disclosure into enrichment over several days. Teams that ingest only the first version of a CVE record may miss later version-range clarification.
This is especially true for enterprise Linux distributions and vendor-maintained embedded kernels. A product may identify as a vulnerable kernel version while carrying the specific backported patch. Another may carry a custom kernel with no clean CPE match at all. In embedded environments, the printed kernel version can be less informative than the vendor’s build metadata and patch manifest.
The right validation step is therefore branch-aware. Check whether the vendor kernel includes one of the stable fixes or an equivalent backport for the
For Microsoft-oriented admins, this is where the MSRC listing can be misleading if read too casually. Microsoft’s vulnerability guide can track CVEs that intersect with Microsoft products, services, or ecosystems, but a listing does not automatically mean Windows itself is vulnerable in the way a Linux gadget device is. The affected software here is the Linux kernel. The operational relevance depends on where Microsoft-supplied or Microsoft-hosted Linux kernels are in your environment.
WSL is usually a Linux guest environment running on a Windows host, not a device pretending to be a USB Ethernet gadget to another host. Even where USB-related workflows exist around Windows and Linux development, the affected
That does not mean WSL users should ignore kernel updates. It means the risk model should be proportional. If Microsoft ships a WSL kernel update that includes the relevant upstream stable patch, take it as part of normal hygiene. But this CVE is not, on its own, evidence that a Windows laptop running WSL is exposed to a practical local DoS path.
The better Windows admin takeaway is about boundaries. WSL has made Linux feel like a Windows feature, but Linux kernel CVEs still need Linux-style triage. Ask whether the subsystem is present, whether the vulnerable code can be reached, whether the module is built or loadable, and whether the environment permits the operations needed to trigger the bug.
A lab technician, kiosk user, field engineer, attacker with brief physical access, or compromised management station may have opportunities that do not map cleanly to server-side threat models. If a device exposes a USB network gadget during setup, recovery, provisioning, diagnostics, or firmware flashing, then bind and unbind behavior may be reachable in real workflows. An availability-impacting kernel bug may become a way to crash or destabilize equipment at inconvenient moments.
This matters for Windows shops because Windows workstations are often the management hosts for these devices. The vulnerable kernel may be in the thing plugged into the Windows machine, not in the Windows machine itself. The business impact can still land on the Windows team when a provisioning bench fails, a device fleet becomes unreliable, or a support workflow starts producing mysterious USB networking behavior.
Organizations that build products should be especially alert. If your device exposes USB Ethernet for initial configuration, support access, tethering, diagnostics, or factory flashing, you should know which gadget functions are enabled and whether userspace can reconfigure them. If
That approach is pragmatic. Kernel subsystems accumulate compatibility constraints, and USB composite gadget drivers are no exception. The CVE description explicitly calls out legacy composite drivers such as
The fix also shows how vulnerabilities can arise from code that is not obviously “security code.” There is no cryptographic error, no authentication bypass, no buffer overflow in a packet parser. The bug is about when an object exists, who its parent is, and what happens when the parent goes away. In kernel space, lifecycle correctness is security engineering.
For defenders, that should temper the reflex to rank vulnerabilities only by drama. Many real outages are caused by boring bugs in edge-case code paths. A USB gadget lifecycle defect may never show up in your SOC dashboard, but it can still matter if the affected code sits inside a medical device, industrial controller, developer board, or appliance in a hard-to-reach location.
But the presence of a CVE in a Microsoft security context should not collapse all distinctions. A Linux kernel CVE is not automatically a Windows CVE. A vulnerability affecting a driver function used by USB gadget devices is not automatically relevant to every Azure VM, every WSL user, or every Windows endpoint. The exact affected product and configuration still matter.
That nuance is especially important for patch management teams. Overbroad interpretation creates needless emergency work; underbroad interpretation leaves real Linux assets unmanaged. The mature response is to treat the CVE as a prompt for targeted discovery. Find Linux kernels under your responsibility, then narrow to systems with USB gadget support and relevant functions enabled.
Microsoft’s own ecosystem makes that harder and more necessary. A Windows-first enterprise may now have Linux in Defender appliances, Azure images, Kubernetes nodes, IoT devices, developer machines, firmware workflows, and vendor-managed hardware. Some of those kernels are updated by Microsoft. Some are updated by Linux distributions. Some are updated by OEMs. Some, uncomfortably, are updated by nobody unless a customer asks.
Start with kernel provenance. Is the kernel upstream stable, distribution-maintained, Android-derived, vendor-modified, or custom? Then check configuration. Is USB gadget support enabled? Is the EEM function available as built-in code or a loadable module? Is the system ever configured to present USB Ethernet to a host? Are bind and unbind cycles part of normal operation?
Next, identify who can trigger those cycles. A locked-down appliance with no accessible USB port and no userspace mechanism to reconfigure gadget functions presents a different risk from a developer board on a shared bench. A device that exposes gadget networking only during recovery mode is different from one that keeps it active during normal operation. The more reachable the state transition, the more urgent the fix becomes.
Finally, look for vendor advisories rather than relying only on generic CPE matching. If your distro or supplier says the fix is backported, document that. If there is no advisory, ask. For internally maintained kernels, treat the referenced stable commits as the start of your code review, then test bind, unbind, and rebind behavior under the gadget profiles you actually ship.
This does not mean the USB gadget subsystem is uniquely broken. It means it carries the burden of old hardware expectations, composite-function flexibility, userspace configuration, and kernel device-model complexity. It also sits at a boundary where physical connectivity, networking abstractions, and driver lifetimes meet. Boundaries are where bugs like to hide.
For IT pros, a patch queue can be more informative than a CVSS score. If several fixes land in the same subsystem around the same time, and your estate depends on that subsystem, you should consider testing the whole stable update rather than cherry-picking only the CVE that your scanner yelled about. Kernel stability is often improved by taking coherent backport sets.
That is doubly true for embedded products. Cherry-picking a lifecycle fix without adjacent race fixes may solve one visible symptom while leaving the surrounding code in an untested hybrid state. The safest path is usually to follow the maintained stable branch for your kernel line, then run product-specific regression tests around the gadget configurations you support.
Source: NVD / Linux Kernel Security Update Guide - Microsoft Security Response Center
A Medium Bug With a Very Specific Blast Radius
The core of CVE-2026-31724 is almost comically narrow: a net_device created for the Linux USB gadget f_eem function is registered under a gadget device in sysfs, but the gadget device can be destroyed while the network device continues to exist. The result is a stale /sys/class/net/usb0 entry pointing into a device path that no longer exists. That is untidy on its face, but in kernel code, untidy lifetime management is rarely just cosmetic.The fix uses
device_move() to move the network device between the gadget’s device tree and /sys/devices/virtual as the function binds and unbinds. In plain English, the kernel now changes the network interface’s parentage before the old parent disappears, then moves it back under the new gadget when the function is rebound. That preserves sysfs topology and avoids confusing device lifetime, power management ordering, and userspace tools that inspect /sys.NVD currently scores the issue as CVSS 3.1 5.5, a medium-severity local vulnerability with high availability impact. The vector matters: local access is required, no user interaction is needed, and the modeled impact is denial of service rather than confidentiality or integrity loss. This is not a remote code execution headline. It is a kernel robustness flaw in a subsystem that matters most to systems acting as USB devices rather than ordinary USB hosts.
That distinction is important because “USB bug” can sound broader than it is. Most Windows users think of USB from the host side: a laptop accepting keyboards, storage drives, webcams, or phones. Linux USB gadget code is the other side of the cable. It lets a Linux device present itself as something else over USB: an Ethernet adapter, serial device, storage function, MIDI interface, camera, or composite gadget.
The Device Is the Peripheral, Not the PC
USB gadget support is heavily used in embedded boards, phones, development kits, appliances, test fixtures, and products that need to expose network-over-USB functions. The affectedf_eem function implements Ethernet Emulation Model behavior, one of several ways Linux can expose a network interface over USB. If you have ever plugged a small Linux board into a workstation and watched a new USB Ethernet interface appear, you have seen the broader class of behavior this code supports.That makes the vulnerability relevant to a different population than a typical desktop kernel bug. The likely affected systems are not ordinary Windows PCs; they are Linux devices that can be configured as USB peripherals and that load the relevant gadget function. The practical risk rises when an attacker can trigger gadget bind and unbind cycles or otherwise influence how the device’s USB function is reconfigured.
For sysadmins, the immediate question is not “Are my Windows endpoints vulnerable?” It is “Do I have Linux kernels in products, appliances, CI rigs, lab devices, kiosks, industrial controllers, Android-based hardware, or recovery environments that expose USB gadget networking?” In many organizations, that inventory is not owned by the same team that manages Windows Update or endpoint protection.
The Windows connection is still real. Windows fleets increasingly sit beside Linux-powered hardware: Surface-adjacent test benches, Hyper-V labs, WSL development environments, Azure appliances, security tooling, firmware flashing stations, and embedded devices managed from Windows workstations. A Linux CVE can therefore become a Windows operations problem without ever being a Windows vulnerability.
The Sysfs Detail Is the Security Story
The most useful part of this CVE is the description of the failure mode. A symlink remains in/sys/class/net/usb0, but the path it points to under the gadget device no longer exists. To a casual observer, that looks like filesystem clutter. To kernel developers, it is evidence that object lifetimes and device hierarchy are out of sync.Sysfs is not merely a directory tree for humans. It is a userspace-facing projection of kernel device objects. Network managers, udev rules, monitoring agents, container runtimes, diagnostics scripts, and device-management tools all inspect it. When sysfs lies about where a device lives, the failure can ripple outward into automation that assumes device relationships are coherent.
The fix is not to remove the symlink after the fact. It is to maintain a valid parent-child relationship throughout the object’s lifecycle. Moving the
net_device to the virtual device tree during final unbind keeps the object anchored somewhere legitimate before the gadget parent is destroyed. Moving it back on rebind restores the intended topology.That is why the CVSS availability impact is plausible even though the visible symptom is a dangling link. Kernel device-model mistakes often show up as crashes, hangs, use-after-free patterns, broken hotplug flows, or userspace components waiting on events that no longer make sense. The CVE text does not claim privilege escalation or data exposure, but it does describe exactly the kind of lifecycle mismatch that kernel maintainers try hard to eliminate.
Linux’s CVE Machine Is Now Surfacing More Plumbing Bugs
This CVE also reflects a broader shift in Linux vulnerability handling. Since the Linux kernel project became more formalized as a CVE Numbering Authority, many kernel fixes that previously might have appeared only as stable patches now surface as CVE records. That has changed the texture of vulnerability feeds: more entries, more driver-level fixes, more lifecycle bugs, and more medium-severity issues that are operationally important but not sensational.Security teams sometimes complain that this creates noise. They are not entirely wrong. A medium local DoS in a niche USB gadget function does not deserve the same response as an actively exploited remote vulnerability in a default network service. But dismissing these records as mere bookkeeping is also a mistake, especially for organizations that ship or manage Linux-based devices.
The value of CVE-2026-31724 is not that every admin must memorize
f_eem. It is that the CVE forces an inventory question. If your exposure to Linux is limited to a few Ubuntu servers in a rack, this may be uninteresting. If your company builds hardware, uses development boards, maintains Android-derived devices, or runs labs full of USB-connected Linux targets, this belongs in the patch triage queue.There is also a timing wrinkle. The NVD entry was published on May 1, 2026, and modified on May 7, 2026, with affected Linux kernel CPE ranges later attached. That means the record moved from initial disclosure into enrichment over several days. Teams that ingest only the first version of a CVE record may miss later version-range clarification.
The CPE Ranges Are a Starting Point, Not an Asset Inventory
The user-submitted record lists affected Linux kernel configurations including 7.0 release candidates and several broad version ranges, with fixed points in stable branches. That is useful for scanners, but CPE matching has always been a blunt instrument for kernels. Distribution kernels are frequently patched without changing to the exact upstream version number that a simple scanner expects.This is especially true for enterprise Linux distributions and vendor-maintained embedded kernels. A product may identify as a vulnerable kernel version while carrying the specific backported patch. Another may carry a custom kernel with no clean CPE match at all. In embedded environments, the printed kernel version can be less informative than the vendor’s build metadata and patch manifest.
The right validation step is therefore branch-aware. Check whether the vendor kernel includes one of the stable fixes or an equivalent backport for the
f_eem lifecycle issue. If you maintain your own kernel tree, inspect the relevant USB gadget code. If you rely on an OEM, board vendor, distro, Android BSP, or appliance supplier, the question to ask is not merely “What version are you on?” but “Does your kernel include the CVE-2026-31724 fix?”For Microsoft-oriented admins, this is where the MSRC listing can be misleading if read too casually. Microsoft’s vulnerability guide can track CVEs that intersect with Microsoft products, services, or ecosystems, but a listing does not automatically mean Windows itself is vulnerable in the way a Linux gadget device is. The affected software here is the Linux kernel. The operational relevance depends on where Microsoft-supplied or Microsoft-hosted Linux kernels are in your environment.
WSL Is Not the Obvious Front Door
Whenever a Linux kernel CVE appears in a Windows venue, someone asks about Windows Subsystem for Linux. That instinct is understandable. WSL 2 runs a real Linux kernel inside a lightweight virtualized environment, and Microsoft ships updates for that kernel. But CVE-2026-31724 lives in USB gadget functionality, which is not the typical shape of WSL exposure.WSL is usually a Linux guest environment running on a Windows host, not a device pretending to be a USB Ethernet gadget to another host. Even where USB-related workflows exist around Windows and Linux development, the affected
f_eem path is about Linux gadget mode. That makes WSL a less obvious attack surface than embedded systems, test devices, and Linux hardware configured for USB networking.That does not mean WSL users should ignore kernel updates. It means the risk model should be proportional. If Microsoft ships a WSL kernel update that includes the relevant upstream stable patch, take it as part of normal hygiene. But this CVE is not, on its own, evidence that a Windows laptop running WSL is exposed to a practical local DoS path.
The better Windows admin takeaway is about boundaries. WSL has made Linux feel like a Windows feature, but Linux kernel CVEs still need Linux-style triage. Ask whether the subsystem is present, whether the vulnerable code can be reached, whether the module is built or loadable, and whether the environment permits the operations needed to trigger the bug.
Embedded Linux Is Where “Local” Often Means “Physically Nearby”
CVSS says local attack vector, and for servers that often means a shell account or code execution on the box. In gadget-world hardware, “local” can mean something more physical: access to a USB port, the ability to plug into a device, or control over a host interacting with a peripheral. That is one reason embedded Linux vulnerability triage can be awkward.A lab technician, kiosk user, field engineer, attacker with brief physical access, or compromised management station may have opportunities that do not map cleanly to server-side threat models. If a device exposes a USB network gadget during setup, recovery, provisioning, diagnostics, or firmware flashing, then bind and unbind behavior may be reachable in real workflows. An availability-impacting kernel bug may become a way to crash or destabilize equipment at inconvenient moments.
This matters for Windows shops because Windows workstations are often the management hosts for these devices. The vulnerable kernel may be in the thing plugged into the Windows machine, not in the Windows machine itself. The business impact can still land on the Windows team when a provisioning bench fails, a device fleet becomes unreliable, or a support workflow starts producing mysterious USB networking behavior.
Organizations that build products should be especially alert. If your device exposes USB Ethernet for initial configuration, support access, tethering, diagnostics, or factory flashing, you should know which gadget functions are enabled and whether userspace can reconfigure them. If
f_eem is not built, not loadable, and not used, your exposure may be nil. If it is part of a composite gadget profile, the fix deserves attention.The Patch Is Small Because the Lesson Is Large
The notable engineering decision in the fix is to keep the existing allocation model while repairing the parentage transitions. The description notes that thenet_device is allocated during function instance creation and registered during bind. Rather than letting it remain attached to a gadget device that is about to disappear, the patch reparents it with device_move().That approach is pragmatic. Kernel subsystems accumulate compatibility constraints, and USB composite gadget drivers are no exception. The CVE description explicitly calls out legacy composite drivers such as
multi.c, using a bound flag to distinguish shared and pre-registered network devices in older paths. This is the sort of detail that rarely matters to headline readers but matters enormously to maintainers trying not to break hardware that has worked for years.The fix also shows how vulnerabilities can arise from code that is not obviously “security code.” There is no cryptographic error, no authentication bypass, no buffer overflow in a packet parser. The bug is about when an object exists, who its parent is, and what happens when the parent goes away. In kernel space, lifecycle correctness is security engineering.
For defenders, that should temper the reflex to rank vulnerabilities only by drama. Many real outages are caused by boring bugs in edge-case code paths. A USB gadget lifecycle defect may never show up in your SOC dashboard, but it can still matter if the affected code sits inside a medical device, industrial controller, developer board, or appliance in a hard-to-reach location.
Microsoft’s Presence Changes the Audience, Not the Bug
The MSRC source attached to CVE-2026-31724 is why this will land in front of some Windows administrators who otherwise would not read Linux stable mailing lists or kernel patch queues. That is not a bad thing. Microsoft is now a major Linux distributor, cloud operator, container host, WSL maintainer, and security ecosystem participant. Its vulnerability guide inevitably reflects that hybrid reality.But the presence of a CVE in a Microsoft security context should not collapse all distinctions. A Linux kernel CVE is not automatically a Windows CVE. A vulnerability affecting a driver function used by USB gadget devices is not automatically relevant to every Azure VM, every WSL user, or every Windows endpoint. The exact affected product and configuration still matter.
That nuance is especially important for patch management teams. Overbroad interpretation creates needless emergency work; underbroad interpretation leaves real Linux assets unmanaged. The mature response is to treat the CVE as a prompt for targeted discovery. Find Linux kernels under your responsibility, then narrow to systems with USB gadget support and relevant functions enabled.
Microsoft’s own ecosystem makes that harder and more necessary. A Windows-first enterprise may now have Linux in Defender appliances, Azure images, Kubernetes nodes, IoT devices, developer machines, firmware workflows, and vendor-managed hardware. Some of those kernels are updated by Microsoft. Some are updated by Linux distributions. Some are updated by OEMs. Some, uncomfortably, are updated by nobody unless a customer asks.
Admins Should Triage the Reachability, Not the Headline
The most common mistake with a CVE like this is to treat the CVSS score as the whole story. A medium local DoS is low priority on a hardened server where the vulnerable module is absent. It may be high priority on a production line where hundreds of Linux devices depend on USB gadget networking to be provisioned or serviced. Severity is contextual.Start with kernel provenance. Is the kernel upstream stable, distribution-maintained, Android-derived, vendor-modified, or custom? Then check configuration. Is USB gadget support enabled? Is the EEM function available as built-in code or a loadable module? Is the system ever configured to present USB Ethernet to a host? Are bind and unbind cycles part of normal operation?
Next, identify who can trigger those cycles. A locked-down appliance with no accessible USB port and no userspace mechanism to reconfigure gadget functions presents a different risk from a developer board on a shared bench. A device that exposes gadget networking only during recovery mode is different from one that keeps it active during normal operation. The more reachable the state transition, the more urgent the fix becomes.
Finally, look for vendor advisories rather than relying only on generic CPE matching. If your distro or supplier says the fix is backported, document that. If there is no advisory, ask. For internally maintained kernels, treat the referenced stable commits as the start of your code review, then test bind, unbind, and rebind behavior under the gadget profiles you actually ship.
The Patch Queue Is the Real Risk Register
CVE-2026-31724 arrived alongside a cluster of related USB gadget fixes touching lifecycle, unbind behavior, races, and null-pointer hazards. That pattern is worth noticing. A single CVE can be a one-off. A cluster suggests maintainers are hardening an area where object lifetime assumptions have become fragile.This does not mean the USB gadget subsystem is uniquely broken. It means it carries the burden of old hardware expectations, composite-function flexibility, userspace configuration, and kernel device-model complexity. It also sits at a boundary where physical connectivity, networking abstractions, and driver lifetimes meet. Boundaries are where bugs like to hide.
For IT pros, a patch queue can be more informative than a CVSS score. If several fixes land in the same subsystem around the same time, and your estate depends on that subsystem, you should consider testing the whole stable update rather than cherry-picking only the CVE that your scanner yelled about. Kernel stability is often improved by taking coherent backport sets.
That is doubly true for embedded products. Cherry-picking a lifecycle fix without adjacent race fixes may solve one visible symptom while leaving the surrounding code in an untested hybrid state. The safest path is usually to follow the maintained stable branch for your kernel line, then run product-specific regression tests around the gadget configurations you support.
The WindowsForum Reader’s Practical Map Through This CVE
CVE-2026-31724 is not the kind of vulnerability that rewards theatrics. It rewards careful asset scoping, boring version verification, and a clear understanding of whether your Linux systems ever act as USB network gadgets. The details are technical, but the operational decision tree is mercifully concrete.- Systems running ordinary Windows are not directly affected by the Linux kernel
f_eemUSB gadget flaw described in CVE-2026-31724. - Linux devices that expose Ethernet-over-USB gadget functions are the systems most likely to need scrutiny.
- WSL users should keep kernels updated, but this CVE does not obviously map to a typical WSL threat path.
- CPE version ranges should be treated as indicators, not proof, because distribution and vendor kernels often carry backported fixes.
- Embedded devices, lab boards, appliances, and factory provisioning rigs deserve more attention than general-purpose desktops.
- The most reliable remediation is to run a vendor kernel or stable branch that includes the
device_move()lifecycle fix or an equivalent backport.
Source: NVD / Linux Kernel Security Update Guide - Microsoft Security Response Center
