Description

In the Linux kernel, the following vulnerability has been resolved: Input: synaptics-rmi4 - zero report size on F54 work error In rmi_f54_work(), if an error occurs during report request or command verification, the code jumped directly to the 'error' label, bypassing the 'abort' label where f54->report_size was normally zeroed out. This left f54->report_size containing its previous successful payload size. If a user then altered the V4L2 format to a smaller size, and a subsequent run failed, rmi_f54_buffer_queue() 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->report_size is always set to 0 on failure by checking for error and zeroing the local report_size first.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-08-26T15:17:12.880Z",
  "pubdate": "2026-08-26T15:17:12.880Z",
  "executiveSummary": "This vulnerability is a heap-based buffer overflow located within the Linux kernel's synaptics-rmi4 driver, specifically affecting the F54 function component. The flaw arises from improper error handling during report request or command verification sequences, which leads to a stale report size being retained in memory. An attacker capable of interacting with the V4L2 interface can exploit this logic error to trigger a memory corruption event. Successful exploitation can lead to a crash (Denial of Service) or potentially arbitrary code execution by overwriting adjacent heap memory. The impact is significant as it affects the stability and security of the kernel memory space. Exploitation requires local access to the device where the Synaptics RMI4 hardware is exposed to the user-space via the V4L2 subsystem.",
  "technicalDetails": "The vulnerability is rooted in the control flow of the rmi_f54_work() function within the Linux kernel's synaptics-rmi4 driver. During normal operation, the driver manages report data requests and command verifications for the F54 sensor functional unit. Historically, the function utilized two distinct exit paths: an 'abort' label, which correctly reset the internal f54->report_size to zero, and an 'error' label, which did not perform this cleanup. When a failure occurs during the command verification process, the driver execution branches to the 'error' label, bypassing the reset mechanism.\nBecause the f54->report_size member persists with the value from the previous successful payload operation, a stale state is maintained. The vulnerability manifests when a user-space application modifies the V4L2 format to a smaller buffer size. If a subsequent command execution fails, the rmi_f54_buffer_queue() function erroneously trusts the stale f54->report_size value. This value, which is now larger than the newly allocated, shrunken V4L2 destination buffer, is passed to the copy routine.\nThe attack flow follows a predictable sequence: First, the attacker initiates a valid transaction to set a large report size. Second, the attacker interacts with the V4L2 interface to reconfigure the buffer to a smaller dimension. Third, the attacker triggers an intentional error during the rmi_f54_work() routine. Because the error handling path fails to zero out the report size, the kernel driver retains the previous large size. Finally, the rmi_f54_buffer_queue() function attempts to copy the cached, large report data into the undersized V4L2 buffer, resulting in a heap-based buffer overflow. This corruption can overwrite critical kernel structures located on the heap, leading to kernel panic or providing a primitive for privilege escalation. The issue highlights a failure in state management within the kernel's error handling paths, specifically where stateful data (report sizes) must be synchronized with current buffer allocation parameters."
}