Zephyr RTOS CVE-2026-19576

Exploitation requires the attacker to control, substitute, or spoof the I2C touch controller that the Zephyr GT9xx driver talks to; the spoofed device must answer the driver's init probes with a supported product ID and a checksum-valid config blob, then report a touch-point count greater than CONFIG_INPUT_GT911_MAX_TOUCH_POINTS (Kconfig range 1..5, default 1) in the status register's low nibble (masked by GT911_TOUCH_POINTS_MSK 0x0F to 0..15). The practical limiting factors are: physical/local hardware access is mandatory (AV:P) with no network, USB, or syscall path; the vulnerable boards are those where the GT9xx panel is a pluggable display module or shield rather than an on-PCB part; and the condition can also be met non-adversarially by a GT9271-class panel that ignores the driver's touch-count programming and reports up to ten points, or by bus corruption of the single status byte - meaning no attacker is strictly required to trigger the overflow.

All signals point to a genuinely high technical impact but a sharply constrained real-world risk. The provided CVSS:3.1 vector (6.8, Medium) encodes the critical limiter: AV:P means physical/local hardware access is required - the description explicitly states there is no network, USB, or syscall path to the defect, which is consistent with AV:P. With AC:L/PR:N/UI:N the attack is easy and needs no authentication once physical hardware access is achieved, and C:H/I:H/A:H reflects a stack out-of-bounds write of fully attacker-chosen content at kernel privilege (control-flow hijack potential). SSVC-style reasoning: technical impact is total, but exploitation is NOT automatable - it requires physically substituting or spoofing the I2C touch controller. EPSS is not provided, there is no CISA KEV listing, and no public exploit is identified in the input, so there is no evidence of active or at-scale exploitation. This is therefore a real but targeted/physical-access priority rather than a widespread remote threat - worth patching on affected embedded devices but not an emergency for fleets lacking the vulnerable touch hardware. One notable nuance the vendor flags: the overflow can also occur NON-adversarially with a GT9271-class panel that reports up to ten points or via bus corruption of the single status byte, raising reliability/robustness risk even absent an attacker. EPSS score is missing, so widespread-exploitation probability cannot be independently confirmed.

An attacker with physical access to an embedded board that uses a pluggable GT9xx touch panel or shield swaps in a malicious or spoofed I2C device that passes the driver's init probes with a supported product ID and a checksum-valid config blob. The spoofed controller then reports more touch points than CONFIG_INPUT_GT911_MAX_TOUCH_POINTS allows, so each per-point 8-byte I2C read writes attacker-chosen data past the end of point_reg[] on the gt911_process() stack frame, enabling control-flow hijack at kernel privilege. No public exploit code is identified at time of analysis, and the physical attack vector (AV:P) with low complexity means the practical barrier is hardware access, not technical skill.