CVE-2026-43342

What it actually does

This is a local race condition in the Linux kernel USB gadget RNDIS function driver. The RNDIS class, subclass, and protocol options can be accessed concurrently through configfs without sufficient locking. A local user with privileges to interact with USB gadget configuration through configfs may be able to trigger inconsistent kernel state, leading primarily to denial of service such as a kernel crash, hang, or loss of availability. The published CVSS vector indicates local access, high attack complexity, low privileges, no user interaction, no confidentiality impact, no integrity impact, and high availability impact.

Why it matters to the business

Successful exploitation can disrupt systems that use the Linux USB gadget framework, particularly embedded devices, appliances, development boards, phones, IoT devices, and systems configured to expose USB networking through RNDIS. The main business risk is operational outage or device instability rather than data theft. Because exploitation requires local access and specific USB gadget configuration permissions, broad remote exploitation is unlikely, and the low EPSS score and lack of known exploited status indicate low immediate mass-exploitation risk. However, affected devices that rely on USB gadget networking for management, provisioning, diagnostics, or field operations may experience meaningful service disruption if crashed or made unstable.

How an attack unfolds

An attacker first needs local access to a Linux system where the USB gadget framework and RNDIS function are available, and they need sufficient privileges to manipulate gadget configuration through configfs. The attacker identifies an RNDIS gadget function and repeatedly performs concurrent reads or writes against the class, subclass, or protocol configuration attributes. By forcing these operations to overlap, the attacker attempts to trigger the race condition in the kernel path that handles RNDIS options. If the timing succeeds, the kernel may enter an inconsistent state and the system can crash, hang, or otherwise become unavailable. There is no public indication that this issue is being exploited in the wild, used by ransomware campaigns, or weaponized into a mature exploit.

How to fix it

Apply a Linux kernel update from the operating system, device, or appliance vendor that includes the upstream fix adding mutex protection around the affected RNDIS option access. No exact fixed package versions were provided in the input, so use vendor advisories and distribution-specific kernel changelogs to identify the corrected kernel build for each supported platform. Where immediate patching is not possible, reduce exposure by disabling unused USB gadget functionality, removing or disabling RNDIS gadget configurations, restricting access to configfs, and ensuring only trusted administrative users can modify USB gadget settings. For embedded or appliance environments, obtain updated firmware or BSP/kernel releases from the device vendor and validate that the fix is included.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package or firmware build includes the vendor fix for the USB gadget RNDIS locking issue. Review distribution or vendor changelogs for references to the RNDIS configfs race fix, the f_rndis mutex protection change, or the relevant kernel stable backport. On systems that do not require USB gadget RNDIS, validate that the module/function is disabled and that no RNDIS gadget function is configured under configfs. Check whether configfs is mounted and whether RNDIS functions exist under the USB gadget hierarchy. After patching or mitigation, reboot if required so the fixed kernel is active, then confirm the running kernel version rather than only the installed package version.

Typical attack path

1. Obtain local access to a Linux system with USB gadget and RNDIS support enabled.
2. Confirm configfs is mounted and USB gadget configuration is accessible.
3. Identify an RNDIS function under the USB gadget configfs hierarchy.
4. Use concurrent processes or threads to read and write RNDIS class, subclass, or protocol attributes repeatedly.
5. Attempt to win the race condition by forcing overlapping configfs access.
6. Cause kernel instability, crash, hang, or device unavailability if the race is triggered successfully.

How to detect it

There are no known public exploitation indicators or malware artifacts specific to this vulnerability. Detection should focus on signs of attempted local abuse and resulting instability. Review kernel logs, system logs, audit logs, and endpoint telemetry for repeated access to USB gadget RNDIS configfs attributes, especially class, subclass, and protocol files. If Linux auditd or an EDR can monitor file activity under configfs, look for unusual bursts of reads or writes by non-standard processes or users. Investigate kernel oops, panic, hang, watchdog reset, or sudden reboot events on systems that have USB gadget RNDIS enabled. Useful log sources include journald, dmesg output, /var/log/kern.log, /var/log/messages, auditd records, EDR process/file telemetry, and embedded device crash or watchdog logs. Because this is a race condition causing denial of service, absence of obvious indicators does not rule out exploitation; a successful attempt may leave only a crash or reboot artifact.

What your security team should do

• Inventory Linux systems and embedded devices that enable USB gadget functionality, especially RNDIS-based USB networking.
• Prioritize patching devices where local users, service accounts, containers, or management workflows can access configfs or USB gadget configuration.
• Apply vendor kernel or firmware updates that include the f_rndis mutex protection fix.
• Disable RNDIS USB gadget functions where they are not operationally required.
• Restrict configfs access to trusted administrators and review whether any non-administrative local users can manipulate USB gadget attributes.
• Monitor for unexpected configfs activity targeting USB gadget RNDIS attributes, especially repeated concurrent writes or reads to class, subclass, or protocol files.
• For appliances and embedded devices, request confirmation from vendors that their shipped kernel includes the fix or that the affected feature is not enabled.
• Treat crashes or watchdog resets on devices with RNDIS gadget enabled as potentially security-relevant until kernel logs and local activity are reviewed.