CVE-2026-98645: HID: winwing: fix use-after-free in force feedback teardown
In the Linux kernel, the following vulnerability has been resolved:
HID: winwing: fix use-after-free in force feedback teardown
winwinginitff() passes the driver's private data, allocated with devmkzalloc() in winwingprobe(), as the effect context to inputffcreatememless(). The memoryless force-feedback core takes ownership of that pointer and frees it with kfree() from inputffdestroy() (mlffdestroy()) 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 inputffdestroy Allocated by task N: winwingprobe
Pass NULL as the memless context instead and fetch the driver data from the input device in winwingplayeffect(): the HID core already stores the hiddevice as the input device's drvdata. The force-feedback core then owns nothing that it must not free.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel Winwing HID driver with force-feedback functionality are exposed. The failure occurs during device or driver teardown rather than during ordinary force-feedback use.
What events can trigger the memory corruption?
The issue can trigger when the device is unbound, the driver module is removed, the device is hot-unplugged, or the system enters suspend. During teardown, the force-feedback core frees driver-private memory that is also managed by devres, leading to a subsequent double free and corrupted slab memory.
What can be done if the fix cannot be deployed immediately?
Avoid teardown events for affected Winwing HID devices where possible: do not unbind the device, remove the driver module, hot-unplug the device, or suspend the system while it is attached. This reduces exposure to the affected teardown path but does not correct the underlying memory-management flaw.