CVE-2026-80568 in Linux
Summary
by MITRE • 08/26/2026
In the Linux kernel, the following vulnerability has been resolved:
Input: synaptics-rmi4 - block s_input when F54 queue is busy
Changing the input (diagnostic report type) mid-stream changes the report size. Since V4L2 buffers are allocated based on the size at stream start, changing the input while streaming could lead to a heap buffer overflow if the new size is larger than the allocated buffers.
Prevent this by blocking VIDIOC_S_INPUT with -EBUSY if the V4L2 queue is busy (streaming).
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/26/2026
The Linux kernel contains a vulnerability within the synaptics-rmi4 input driver that arises from improper handling of dynamic changes to diagnostic report types during active streaming sessions. This specific flaw involves the interaction between the device's firmware interface and the V4L2 buffer management subsystem, where changing the input type mid-stream alters the expected size of data reports generated by the hardware. The core technical issue stems from the fact that Video for Linux 2 buffers are allocated based on the report size determined at the moment the stream is initialized. When a user space application attempts to switch the input source while the device is actively streaming, it may request a diagnostic report type with a larger payload than what was originally anticipated and allocated by the kernel driver.
This discrepancy between the initially allocated buffer size and the potentially larger new report size creates a critical heap buffer overflow condition. As the hardware begins generating data according to the new, larger format, the driver attempts to write this excess data into memory regions that are too small to accommodate it. This out-of-bounds write operation corrupts adjacent kernel memory structures, which can lead to system instability, crashes, or potentially allow a local attacker with access to the device node to execute arbitrary code within the kernel context by overwriting critical function pointers or control flow data. The vulnerability is classified under CWE-120, Buffer Copy without Checking Size of Input, and aligns with ATT&CK technique T1059, Command and Scripting Interpreter, as it could be leveraged for privilege escalation if exploited successfully through local access to the input device interface.
The operational impact of this vulnerability is significant because it affects systems relying on synaptics RMI4 devices, such as certain touchpads or touchscreen controllers that support diagnostic reporting features. An attacker with physical access or the ability to execute code within a user space environment can trigger this condition by opening the relevant device node and issuing an ioctl call to change the input while streaming is active. This does not require high privileges initially but allows for escalation once the kernel memory corruption occurs, potentially granting full control over the operating system. The flaw highlights the risks associated with dynamic reconfiguration of hardware interfaces without adequate bounds checking or synchronization mechanisms in place during active data transfer phases.
To mitigate this vulnerability, the Linux kernel developers have implemented a safeguard that blocks the VIDIOC_S_INPUT ioctl call when the V4L2 queue is busy and currently streaming. By returning an -EBUSY error code instead of allowing the input change to proceed, the driver prevents any attempt to alter report types while buffers are in use, thereby eliminating the possibility of mismatched buffer sizes leading to heap overflows. System administrators should ensure that their systems are updated with kernel patches containing this fix. Additionally, developers integrating similar drivers should enforce strict state checks before allowing configuration changes during active streams and consider implementing dynamic reallocation logic or fixed-size reporting modes if such flexibility is required for specific use cases without compromising memory safety.