https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Wed, 14 Oct 2026 10:28:06 +0000 https://db.gcve.eu/vuln/fkie_cve-2026-19576 <p>The Goodix GT9xx input driver in drivers/input/input_gt911.c reads the touch point count from the controller&#39;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.</p> <p>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&#39;s touch-count programming and reports up to ten points, or with bus corruption of the single status byte.</p> <p>The impact is an…</p> <p>The Goodix GT9xx input driver in drivers/input/input_gt911.c reads the touch point count from the controller&#39;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.</p> <p>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&#39;s touch-count programming and reports up to ten points, or with bus corruption of the single status byte.</p> <p>The impact is an…</p> https://db.gcve.eu/vuln/fkie_cve-2026-19576