CVE-2026-93141 in Linux
Summary
by MITRE • 09/18/2026
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: r8a66597: avoid double free of ep0_req in probe error path
If usb_add_gadget_udc() fails, r8a66597_probe() jumps to err_add_udc and frees ep0_req, then falls through to clean_up2 where ep0_req is freed again when it is non-NULL.
Remove the redundant free from err_add_udc and keep the cleanup in clean_up2 so the request is released exactly once.
Issue found using a prototype static analysis tool and confirmed by code review.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/18/2026
The Linux kernel driver for the R8A66597 USB gadget controller contains a resource management flaw within its initialization sequence, specifically during the probe function execution path when hardware or subsystem registration fails. This vulnerability manifests as a double free error, which occurs if the call to usb_add_gadget_udc() returns an error code indicating failure. In this scenario, the driver's error handling logic incorrectly attempts to release resources that have not been fully allocated or are already being managed by another part of the cleanup routine. The flaw stems from redundant deallocation calls where ep0_req is freed in one label and then again in a subsequent cleanup block, leading to undefined behavior due to double freeing of kernel memory.
From a technical perspective, this issue represents a classic control flow error in resource management. When usb_add_gadget_udc() fails, the execution jumps to an intermediate error handling label labeled err_add_udc. Within this path, ep0_req is explicitly freed using kfree or a similar deallocation function. However, instead of returning immediately from the probe function after cleaning up at that stage, the code falls through into another cleanup section designated as clean_up2. This secondary block also checks if ep0_req is non-NULL and proceeds to free it again. Since memory allocated in kernel space cannot be safely freed twice without causing corruption, this sequence violates fundamental principles of safe resource lifecycle management. The vulnerability was identified using a prototype static analysis tool designed to detect such redundant deallocation patterns and subsequently confirmed through manual code review by developers familiar with the driver's architecture.
The operational impact of this double free vulnerability is significant in terms of system stability and security integrity. In kernel space, freeing memory twice typically results in heap corruption because the second free operation attempts to return an already released block back to the allocator. This can corrupt internal data structures maintained by the slab allocator or buddy system, potentially leading to a kernel panic or immediate system crash. Furthermore, sophisticated attackers may exploit such memory corruption vulnerabilities to achieve arbitrary code execution with root privileges. By carefully crafting inputs that trigger this specific error path during device enumeration or driver loading, an attacker could manipulate heap metadata to overwrite function pointers or other critical structures, thereby bypassing standard security mitigations like kernel address space layout randomization and full RELRO protections.
This vulnerability aligns closely with Common Weakness Enumeration identifier CWE-415, which describes Double Free vulnerabilities where a program frees memory more than once without resetting the pointer or ensuring exclusive ownership of the resource at each step. Additionally, in the context of attack patterns, this flaw relates to MITRE ATT&CK technique T1068 Exploitation for Privilege Escalation, as heap corruption is a common vector for escalating from user space to kernel level privileges. The root cause lies in improper error handling logic that fails to maintain exclusive control over resource deallocation across different execution paths within the same function scope.
To mitigate this vulnerability, the redundant free operation located at the err_add_udc label must be removed entirely. The cleanup responsibility for ep0_req should remain exclusively with the clean_up2 block, which ensures that the request is released exactly once regardless of whether usb_add_gadget_udc() succeeds or fails. This correction restores proper resource lifecycle management and prevents heap corruption during driver initialization failures. Developers implementing similar USB gadget drivers should adopt a strict policy where each allocated resource has a single designated cleanup point to avoid such double free scenarios. Static analysis tools integrated into the continuous integration pipeline can help detect these patterns early in development, while code reviews focusing on error paths are essential for verifying that all exit points correctly manage shared resources without duplication or omission.