CVE-2026-19576: Zephyr GT911: stack overflow via rogue touch controller

MEDIUM
Published October 11, 2026
CISO Take

Zephyr's Goodix GT911 touch driver trusts the touch-point count reported by the I2C controller and uses it as a loop bound for a small stack array, so a controller reporting more points than configured (up to 15 versus a Kconfig maximum of 5) overwrites up to 112 bytes of kernel stack with attacker-chosen data. The CVSS is 6.8 (medium) because exploitation needs physical access to the bus or the ability to swap in a spoofed touch module. Impact is potentially full control-flow hijack on the MCU. The AI link is marginal: it is an embedded RTOS input driver, not an ML component, and it matters only for edge-AI devices (smart displays, kiosks, HMI panels) built on Zephyr. There is no EPSS score, no KEV listing, no public exploit and no scanner template, so near-term exploitation likelihood is low. Teams shipping Zephyr products with pluggable GT911/GT9xx display modules should pull in the upstream fix, which clamps the count with min() against CONFIG_INPUT_GT911_MAX_TOUCH_POINTS, and treat user-replaceable display modules as an untrusted boundary.

Sources:NVDGitHub AdvisoryATLAS

What is the risk?

Low-to-medium overall. Severity is capped by the physical attack vector (AV:P): the attacker must control or replace the I2C touch controller, which is plausible for pluggable display modules and shields but not for on-PCB parts. Once reached, the primitive is strong (out-of-bounds stack write with fully controlled content at kernel privilege, plus out-of-bounds reads), giving high confidentiality, integrity and availability impact. The overflow can also be triggered non-adversarially by GT9271-class panels that ignore the count programming, or by bus corruption, so field crashes are possible without any attacker. No exploitation evidence, EPSS data, public PoC or SSVC decision exists. AI relevance is indirect: only edge-AI products using Zephyr and this driver are exposed.

How does the attack unfold?

Physical Access
Attacker replaces or taps the pluggable I2C touch controller with a spoofed GT911 that passes init probes.
AML.T0041
Exploitation
The rogue controller reports up to 15 touch points, causing gt911_process() to write past the end of the stack array.
Control-Flow Hijack
Attacker-chosen bytes overwrite the stack frame in the system workqueue thread, redirecting execution at kernel privilege.
AML.T0112
Impact
Arbitrary code execution or crash on the MCU lets the attacker tamper with on-device AI inference, data and firmware.

What systems are affected?

PackageEcosystemVulnerable RangePatched
zephyr——No patch

Do you use zephyr? You're affected.

How severe is it?

CVSS 3.1
6.8 / 10
EPSS
0.2%
chance of exploitation in 30 days
Higher than 6% of all CVEs
Exploitation Status
No known exploitation
Sophistication
Advanced

What is the attack surface?

AVACPRUISCIA
AVPhysical
ACLow
PRNone
UINone
SUnchanged
CHigh
IHigh
AHigh

What should I do?

1 step
  1. 1) Apply the upstream Zephyr fix (commit 42b52d571eb2113012c135276693042fd372fdea) and review GHSA-p7qh-fvwx-f7vr for affected and patched releases. 2) As an interim workaround, set CONFIG_INPUT_GT911_MAX_TOUCH_POINTS to the maximum the panel can report (up to 5 allowed) or backport the min() clamp. 3) Use only vetted display modules in production and consider tamper-evident enclosures or locked connectors for the touch controller bus. 4) Enable stack protection and MPU or memory-isolation features where the SoC supports them to make the overflow harder to turn into code execution. 5) Detection: watch for unexplained watchdog resets or workqueue crashes on touch input and for unexpected touch controller product IDs at init. 6) Add the Zephyr version and enabled drivers to the firmware SBOM so affected products can be found quickly.

What does CISA's SSVC say?

DecisionTrack
Exploitationnone
AutomatableNo
Technical Impacttotal

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Art. 15-Accuracy, robustness and cybersecurity
ISO 42001
A.7.4-Quality of data for AI systems
NIST AI RMF
MANAGE 2.3-Procedures to respond to and recover from unknown risks

Frequently Asked Questions

What is CVE-2026-19576?

Zephyr's Goodix GT911 touch driver trusts the touch-point count reported by the I2C controller and uses it as a loop bound for a small stack array, so a controller reporting more points than configured (up to 15 versus a Kconfig maximum of 5) overwrites up to 112 bytes of kernel stack with attacker-chosen data. The CVSS is 6.8 (medium) because exploitation needs physical access to the bus or the ability to swap in a spoofed touch module. Impact is potentially full control-flow hijack on the MCU. The AI link is marginal: it is an embedded RTOS input driver, not an ML component, and it matters only for edge-AI devices (smart displays, kiosks, HMI panels) built on Zephyr. There is no EPSS score, no KEV listing, no public exploit and no scanner template, so near-term exploitation likelihood is low. Teams shipping Zephyr products with pluggable GT911/GT9xx display modules should pull in the upstream fix, which clamps the count with min() against CONFIG_INPUT_GT911_MAX_TOUCH_POINTS, and treat user-replaceable display modules as an untrusted boundary.

Is CVE-2026-19576 actively exploited?

No confirmed active exploitation of CVE-2026-19576 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-19576?

1) Apply the upstream Zephyr fix (commit 42b52d571eb2113012c135276693042fd372fdea) and review GHSA-p7qh-fvwx-f7vr for affected and patched releases. 2) As an interim workaround, set CONFIG_INPUT_GT911_MAX_TOUCH_POINTS to the maximum the panel can report (up to 5 allowed) or backport the min() clamp. 3) Use only vetted display modules in production and consider tamper-evident enclosures or locked connectors for the touch controller bus. 4) Enable stack protection and MPU or memory-isolation features where the SoC supports them to make the overflow harder to turn into code execution. 5) Detection: watch for unexplained watchdog resets or workqueue crashes on touch input and for unexpected touch controller product IDs at init. 6) Add the Zephyr version and enabled drivers to the firmware SBOM so affected products can be found quickly.

What systems are affected by CVE-2026-19576?

This vulnerability affects the following AI/ML architecture patterns: Edge AI devices, Embedded RTOS firmware, TinyML / on-device inference HMIs, IoT devices with touchscreens.

What is the CVSS score for CVE-2026-19576?

CVE-2026-19576 has a CVSS v3.1 base score of 6.8 (MEDIUM). The EPSS exploitation probability is 0.17%.

What is the AI security impact?

Affected AI Architectures

Edge AI devicesEmbedded RTOS firmwareTinyML / on-device inference HMIsIoT devices with touchscreens

MITRE ATLAS Techniques

AML.T0010.000Hardware
AML.T0041Physical Environment Access
AML.T0112Machine Compromise

Compliance Controls Affected

EU AI Act: Art. 15
ISO 42001: A.7.4
NIST AI RMF: MANAGE 2.3

What are the technical details?

Original Advisory

The Goodix GT9xx input driver in drivers/input/input_gt911.c reads the touch point count from the controller's status register and masks it with GT911_TOUCH_POINTS_MSK (0x0F), yielding a value of 0..15. In gt911_process() that value is used directly as the loop bound for filling point_reg[], a stack array sized to CONFIG_INPUT_GT911_MAX_TOUCH_POINTS, whose Kconfig range is 1..5 with a default of 1. No other check constrains the count; the driver relied only on a comment asserting that the controller had been programmed at init to report no more points than configured. Each loop iteration issues an I2C read of eight bytes straight into point_reg[i], so a controller that reports more points than the array holds causes up to 112 bytes of peer-supplied data to be written past the end of the array, over the stack frame of gt911_process() in the system workqueue thread. Two further loops then read out of bounds from the same array. Triggering it requires control of, or the ability to substitute, the I2C touch controller — plausible on the many supported boards where the GT9xx panel is a pluggable display module or shield rather than an on-PCB part; a spoofed device need only answer the init probes with a supported product ID and a checksum-valid config blob. The same overflow can also occur non-adversarially, with a GT9271-class panel that ignores the driver's touch-count programming and reports up to ten points, or with bus corruption of the single status byte. The impact is an out-of-bounds stack write with fully attacker-chosen content executing at kernel privilege, i.e. potential control-flow hijack on the host MCU, in addition to out-of-bounds reads and crashes. The attack vector is physical/local hardware access only; there is no network, USB, or syscall path to the defect. The fix clamps the reported count with min() against CONFIG_INPUT_GT911_MAX_TOUCH_POINTS before any array indexing.

Exploitation Scenario

An adversary with brief physical access to an edge-AI kiosk or industrial HMI replaces the pluggable display module with a rogue board that mimics a GT911. It answers the init probes with a supported product ID and a checksum-valid config blob, then reports 15 touch points in the status register. The driver loops 15 times, writing 8 bytes per iteration past the end of the stack array in gt911_process() in the system workqueue thread. The attacker uses crafted data to overwrite the return address and gain code execution on the MCU. From there they can tamper with the on-device model or its inputs and outputs, extract credentials or keys, or persist in firmware.

Weaknesses (CWE)

CWE-787 — Out-of-bounds Write: The product writes data past the end, or before the beginning, of the intended buffer.

  • [Requirements] Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, many languages that perform their own memory management, such as Java and Perl, are not subject to buffer overflows. Other languages, such as Ada and C#, typically provide overflow protection, but the protection can be disabled by the programmer. Be wary that a language's interface to native code may still be subject to overflows, even if the language itself is theoretically safe.
  • [Architecture and Design] Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. Examples include the Safe C String Library (SafeStr) by Messier and Viega [REF-57], and the Strsafe.h library from Microsoft [REF-56]. These libraries provide safer versions of overflow-prone string-handling functions.

Source: MITRE CWE corpus.

CVSS Vector

CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Timeline

Published
October 11, 2026
Last Modified
October 15, 2026
First Seen
October 11, 2026

Related Vulnerabilities