CVE-2026-31728

What it actually does

This is a Linux kernel race condition in the USB gadget Ethernet implementation, specifically between gether_disconnect() tearing down USB endpoints and eth_stop() stopping the associated network interface. Under a narrow timing window, eth_stop() can attempt to enable or access a USB endpoint after its descriptor has already been cleared, causing a kernel NULL pointer dereference. Because the crash can occur while holding dev->lock, the disconnect path may then spin indefinitely waiting for the same lock, producing a hard lockup. The practical technical impact is local denial of service through kernel crash or system hang on systems using USB gadget Ethernet functions such as NCM, ECM, or related gadget networking modes.

Why it matters to the business

Affected systems can be forced to crash or become unresponsive, causing service interruption, device resets, or manual recovery requirements. The issue is most relevant to embedded Linux devices, appliances, mobile/IoT platforms, development boards, and systems that expose USB gadget Ethernet functionality. Exploitation requires local access and precise race timing, and current public signals indicate low exploitation likelihood: it is not listed in CISA KEV, is not associated with ransomware use, has no known mature exploit, and has a very low, flat EPSS trend. However, for operational technology, kiosks, field devices, or appliances where uptime matters and physical or local access is plausible, the availability impact can still be significant.

How an attack unfolds

An attacker first needs local interaction with an affected Linux system that has USB gadget Ethernet enabled or configurable. The attacker then causes USB gadget disconnect or alternate-setting activity while concurrently triggering shutdown of the gadget network interface. If the timing aligns, gether_disconnect() clears or tears down USB endpoint state while eth_stop() still assumes the endpoint descriptor is valid. eth_stop() then dereferences a NULL endpoint-related pointer, causing a kernel fault. Because the crashing path can hold the device spinlock, the parallel disconnect path can become stuck attempting to acquire the same lock, escalating the fault into a hard lockup. The end result is denial of service rather than data theft or privilege escalation based on currently available information.

How to fix it

Apply a Linux kernel update from the relevant distribution, device vendor, or kernel maintainer that includes the fix for the USB gadget u_ether race between gether_disconnect() and eth_stop(). If exact fixed package versions are not provided by the upstream data source, track vendor advisories for the affected kernel branch and confirm that the patch moves clearing of dev->port_usb to the beginning of gether_disconnect() while holding dev->lock. Where immediate patching is not possible, reduce exposure by disabling unused USB gadget Ethernet functions, removing unnecessary NCM/ECM/RNDIS gadget configurations, restricting access to configfs and network interface administration, limiting local shell access, and controlling physical USB access to affected devices. For appliance and embedded fleets, prioritize vendor firmware updates that contain the corrected kernel.

How to confirm the fix worked

Confirm the running kernel or firmware build includes the vendor patch for the u_ether gether_disconnect()/eth_stop() race. Validate through distribution changelogs, kernel package metadata, firmware release notes, or source inspection for the corrected gether_disconnect() ordering that clears dev->port_usb at the start of teardown under dev->lock. On systems where source or debug symbols are available, verify the patched USB gadget Ethernet code path is present rather than relying only on version strings. Confirm whether USB gadget Ethernet modules or configurations are enabled by checking loaded modules, gadget configfs entries, and active USB gadget network interfaces. Avoid stress-testing the race on production systems because successful reproduction may crash or hard-lock the host.

Typical attack path

1. Identify a Linux system using USB gadget Ethernet functionality such as USB NCM, ECM, RNDIS, or composite USB gadget networking.
2. Obtain local ability to influence USB gadget state, network interface state, or gadget configuration paths.
3. Trigger USB gadget disconnect, reconfiguration, or alternate-setting changes while simultaneously stopping or cycling the associated Ethernet gadget interface.
4. Race gether_disconnect() against eth_stop() so endpoint state is cleared while eth_stop() still attempts to use it.
5. Cause a NULL pointer dereference in the kernel USB gadget path.
6. Leave the system crashed, hung, or requiring reboot due to kernel panic or hard lockup.

How to detect it

Look for evidence of prior kernel crashes, panics, hard lockups, or watchdog resets involving Linux USB gadget Ethernet code. Useful sources include dmesg, journald, /var/log/kern.log, /var/log/messages, serial console logs, pstore/ramoops, kdump/vmcore analysis, hypervisor console captures, device management telemetry, and watchdog reset records. Search for call traces that include eth_stop(), gether_disconnect(), usb_ep_enable(), dwc3_gadget_ep_enable(), ncm_set_alt(), composite_setup(), or queued_spin_lock_slowpath. Also correlate events where a USB gadget network interface was stopped, reset, disconnected, or reconfigured immediately before a kernel NULL pointer dereference or hardlockup. There are no known public attacker-specific network indicators for this vulnerability; detection is primarily host- and crash-artifact-based.

• Unable to handle kernel NULL pointer dereference
• NULL pointer dereference
• Call trace:
• __dwc3_gadget_ep_enable
• dwc3_gadget_ep_enable
• usb_ep_enable
• eth_stop
• gether_disconnect
• queued_spin_lock_slowpath
• _raw_spin_lock
• ncm_set_alt
• composite_setup
• hardlockup
• Hardlockup
• watchdog: BUG: soft lockup
• watchdog: BUG: hard LOCKUP
• u_ether
• usb_f_ncm
• usb_f_ecm
• g_ether
• configfs-gadget

What your security team should do

• Inventory Linux systems and embedded devices that enable USB gadget Ethernet features, especially NCM, ECM, RNDIS, or composite USB gadget networking.
• Prioritize remediation for devices where local users, field technicians, exposed USB ports, kiosks, lab users, or untrusted physical access can influence USB gadget or network interface state.
• Apply vendor kernel or firmware updates containing the u_ether race-condition fix as part of normal availability-risk patching.
• Disable USB gadget Ethernet functionality where it is not required for business operations.
• Restrict administrative capabilities that can stop network interfaces, modify gadget configfs entries, or reconfigure USB gadget functions.
• Monitor kernel logs for NULL pointer dereferences, USB gadget endpoint enable failures, and hardlockup messages involving gether_disconnect(), eth_stop(), u_ether, dwc3, or ncm_set_alt.
• Treat unexplained kernel panics or hard lockups on USB gadget-capable devices as potential exploitation or triggering events and preserve kernel logs, pstore, ramoops, crash dumps, and serial console output.
• Because this issue is not currently in KEV and has very low EPSS, balance urgency against broader patch priorities, but do not defer on high-availability embedded or physically accessible devices.