CVE-2026-80570: Input: synaptics-rmi4 - zero report size on F54 work error
In the Linux kernel, the following vulnerability has been resolved:
Input: synaptics-rmi4 - zero report size on F54 work error
In rmif54work(), if an error occurs during report request or command verification, the code jumped directly to the 'error' label, bypassing the 'abort' label where f54->reportsize was normally zeroed out.
This left f54->reportsize containing its previous successful payload size. If a user then altered the V4L2 format to a smaller size, and a subsequent run failed, rmif54bufferqueue() would copy the stale, larger payload size into the shrunken V4L2 buffer, causing a heap buffer overflow.
Fix this by merging the 'abort' and 'error' labels into a single 'out' exit path, and ensuring that f54->reportsize is always set to 0 on failure by checking for error and zeroing the local reportsize first.
Affected Software
Event History
Frequently Asked Questions
What conditions are required to trigger the overflow?
A prior F54 report request must have succeeded so that a nonzero report size is retained. A user must then change the V4L2 format to a smaller buffer size, followed by a report request or command-verification failure that leaves the stale larger size in place.
Which systems are exposed?
Systems using the Linux kernel's synaptics-rmi4 input driver and its F54 reporting path are relevant. The issue specifically involves V4L2 buffer handling, so exposure depends on use of that interface and the required sequence of report operations and format changes.
What is the impact of a successful trigger?
The driver can copy a stale report payload larger than the current V4L2 buffer into that buffer, resulting in a heap buffer overflow.
What does the fix change?
The fix routes failure handling through a common exit path and clears the report size whenever an error occurs. This prevents a failed operation from reusing the size of an earlier successful payload.