CVE-2026-98645 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
HID: winwing: fix use-after-free in force feedback teardown
winwing_init_ff() passes the driver's private data, allocated with devm_kzalloc() in winwing_probe(), as the effect context to input_ff_create_memless(). The memoryless force-feedback core takes ownership of that pointer and frees it with kfree() from input_ff_destroy() (ml_ff_destroy()) when the input device is destroyed.
Freeing a devm-managed allocation with kfree() is an invalid free, and the same object is then released again by devres when the HID device is torn down, a double free. As the allocation also embeds the LED class devices, their timers and work item live on freed memory and the slab gets corrupted. This triggers on unbind, rmmod, hot-unplug and on system suspend, where the firmware cache walks the now-corrupt devres list. KASAN reports:
BUG: KASAN: invalid-free in input_ff_destroy Allocated by task N: winwing_probe
Pass NULL as the memless context instead and fetch the driver data from the input device in winwing_play_effect(): the HID core already stores the hid_device as the input device's drvdata. The force-feedback core then owns nothing that it must not free.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/18/2026
The vulnerability identified within the Linux kernel’s Human Interface Device subsystem, specifically affecting the WinWing driver implementation, represents a critical memory management error known as an invalid-free leading to double-free conditions and subsequent heap corruption. This flaw arises from a fundamental misunderstanding of resource ownership between the device manager framework and the input force-feedback core. During the initialization phase via winwing_init_ff(), the driver allocates private data structures using devm_kzalloc, which ties the memory lifecycle directly to the HID device’s managed resources. However, this allocated pointer is subsequently passed as the effect context to input_ff_create_memless(). The Linux kernel’s memoryless force-feedback core assumes full ownership of this context pointer and proceeds to free it using standard kfree() calls within its teardown routine, specifically inside ml_ff_destroy when triggered by input_ff_destroy during device destruction.
This sequence creates a fatal conflict in resource management because the same memory block is now subject to two independent deallocation mechanisms. When the HID device undergoes cleanup operations such as unbinding from the driver, module removal via rmmod, hot-unplug events, or system suspend where firmware caches traverse the devres list, the kernel attempts to free the already-released memory again through the standard devm release path. This double-free scenario corrupts the slab allocator metadata, leading to unpredictable behavior and potential privilege escalation vectors if an attacker can influence allocation patterns in adjacent heap regions. The corruption is particularly severe because the allocated structure embeds LED class devices along with their associated timers and work items; these kernel objects continue to operate on freed memory addresses until they are accessed or scheduled for execution, resulting in use-after-free conditions that compromise system stability and security integrity.
From a technical classification perspective, this vulnerability aligns closely with CWE-415 Double Free and CWE-416 Use After Free, which describe scenarios where resources are released multiple times or accessed after their lifetime has ended. In the context of the MITRE ATT&CK framework for enterprise environments, such memory corruption flaws can be leveraged in post-exploitation phases to achieve arbitrary code execution by manipulating heap structures, although this specific instance primarily manifests as a denial-of-service condition through kernel panics triggered by KASAN reports during normal operational lifecycle events like suspend or unplug. The root cause lies not in complex logic errors but in improper API usage regarding ownership semantics within the driver’s probe and teardown functions.
The resolution involves correcting the pointer handling strategy to ensure clear separation of resource lifecycles. Instead of passing the devm-managed private data directly as the memless context, the fix dictates that NULL should be passed for this parameter. This prevents the force-feedback core from attempting to free memory it does not own. To maintain functionality, the driver must retrieve its specific device data by accessing the hid_device stored in the input device’s drvdata field during effect playback operations via winwing_play_effect(). Since the HID core already manages the association between the hid_device and the input device through drvdata, this approach allows the driver to access necessary context without violating memory management rules. This adjustment ensures that only one entity is responsible for freeing each allocated resource, thereby eliminating the double-free condition and preventing heap corruption during device teardown sequences.