CVE-2026-64274 in Linux
Summary
by MITRE • 07/25/2026
In the Linux kernel, the following vulnerability has been resolved:
Input: goodix - clamp the device-reported contact count
goodix_ts_read_input_report() copies the number of touch points reported by the device into an on-stack buffer
u8 point_data[2 + GOODIX_MAX_CONTACT_SIZE * GOODIX_MAX_CONTACTS];
which is sized for at most GOODIX_MAX_CONTACTS (10) contacts. The only runtime check bounds the per-interrupt count against ts->max_touch_num, but that value is taken verbatim from a 4-bit field of the device configuration block and is never clamped:
ts->max_touch_num = ts->config[MAX_CONTACTS_LOC] & 0x0f;
The nibble can be 0..15, so a malfunctioning, malicious or counterfeit controller (or an attacker tampering with the I2C bus) can advertise up to 15 contacts. goodix_ts_read_input_report() then accepts a touch_num of up to 15 and the second goodix_i2c_read() writes ts->contact_size * (touch_num - 1) bytes past the one-contact header into point_data - up to 30 bytes (45 with the 9-byte report format) beyond the 92-byte buffer: a stack out-of-bounds write.
Clamp max_touch_num to GOODIX_MAX_CONTACTS, the number of contacts point_data[] is sized for, when reading it from the configuration.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 07/25/2026
The vulnerability in question involves a stack-based buffer overflow within the Linux kernel's Goodix touchscreen driver implementation. This security flaw exists in the goodix_ts_read_input_report() function where the driver processes input reports from touchscreen hardware devices. The core issue stems from inadequate bounds checking when handling device-reported contact counts, creating an exploitable condition that could lead to arbitrary code execution or system compromise.
The technical implementation of this vulnerability occurs through a combination of improper input validation and buffer sizing constraints. The driver allocates an on-stack buffer named point_data with dimensions calculated for a maximum of GOODIX_MAX_CONTACTS (10) contacts, specifically sized as 2 + GOODIX_MAX_CONTACT_SIZE * GOODIX_MAX_CONTACTS bytes. However, the driver retrieves the actual contact count from a 4-bit field within the device configuration block without applying any upper bounds enforcement. This 4-bit field can theoretically contain values ranging from 0 to 15, allowing malicious or faulty hardware to report contact counts that exceed the buffer capacity.
The operational impact of this vulnerability becomes apparent when examining how the driver processes these malformed contact counts during interrupt handling. When a device reports more than the expected maximum contacts, the code performs only a single runtime check against ts->max_touch_num but fails to validate that this value remains within the buffer's allocated bounds. The function then proceeds to execute a second i2c_read operation that writes data into point_data using an offset calculated as ts->contact_size * (touch_num - 1) bytes past the initial header. This calculation can result in writing up to 30 bytes beyond the intended buffer boundaries when using standard report formats, or even 45 bytes with 9-byte report format configurations.
This vulnerability directly corresponds to CWE-121 Stack-based Buffer Overflow, which specifically addresses conditions where data is written beyond the bounds of stack-allocated buffers. The attack vector through this flaw aligns with ATT&CK technique T1068, involving privilege escalation through kernel exploits, and could potentially enable attackers to gain unauthorized system access. The vulnerability presents a particularly concerning threat because it can be triggered through physical I2C bus manipulation or by deploying counterfeit touchscreen controllers that deliberately report excessive contact counts.
The recommended mitigation strategy involves implementing proper input clamping mechanisms when reading device configuration parameters. Specifically, the code should clamp ts->max_touch_num to GOODIX_MAX_CONTACTS (10) whenever this value is extracted from the configuration block, ensuring that the maximum contact count never exceeds the buffer capacity. This approach directly addresses the root cause by preventing any possibility of exceeding the predefined buffer boundaries during data processing operations. The fix must be applied at the point where ts->max_touch_num is initialized from the device configuration, ensuring all subsequent calculations and memory operations remain within safe bounds.
This vulnerability demonstrates a classic example of insufficient input validation combined with inadequate buffer management in embedded driver code. It highlights the critical importance of enforcing strict bounds checking for all externally-provided parameters, particularly in kernel-level drivers where such flaws can lead to complete system compromise. The solution represents a straightforward defensive programming approach that prevents the exploitation of boundary condition errors while maintaining full compatibility with legitimate device operation within expected parameter ranges.
The broader implications of this vulnerability extend beyond immediate security concerns to highlight systemic issues in embedded device driver development practices. Many kernel drivers face similar challenges when processing hardware-reported data without proper validation, making this a common pattern that requires consistent attention through defensive programming principles and comprehensive input sanitization across all kernel subsystems handling external device data.