Look up another CVE · open CVE-2026-80754 in the interactive tracker
CVE-2026-80754
Input: synaptics-rmi4 - fix F55 transmitter electrode count typo
Published 2026-09-03 (2 months ago) by the Linux kernel CNA. Subsystem drivers/input. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-80754 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixedDLA-4777-1 · 2026-09-08 · text | 6.1.187-1 | Update the kernel and reboot. DLA-4777-1 shipped the fix on 2026-09-08, in 6.1.187-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixed | 6.12.105-1 | Update the kernel and reboot. Fixed in 6.12.105-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.1.10-1 | Update the kernel and reboot. Fixed in 7.1.10-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.10-1 | Update the kernel and reboot. Fixed in 7.1.10-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4788-1 · 2026-09-19 · text | 6.12.107-1~deb12u1 | Update the kernel and reboot. DLA-4788-1 shipped the fix on 2026-09-19, in 6.12.107-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
During F55 sensor detection, the transmitter (TX) electrode count was incorrectly assigned the value of the receiver (RX) electrode count due to copy-paste typos. This incorrect value was then propagated to the driver data and used by F54 to determine the diagnostics report size. On devices with more RX than TX electrodes, this inflated the perceived TX count, leading to incorrect report size calculations and potential out-of-bounds buffer accesses. Fix the typos by correctly assigning the TX electrode counts.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/input/rmi4/rmi_f55.c
- What this is
- INPUT (KEYBOARD, MOUSE, JOYSTICK, TOUCHSCREEN) DRIVERSMAINTAINERS section matched on drivers/input/ · linux-input@vger.kernel.org · Maintained
- Kernel module
- rmi_core
Check it on the machine
grep -wE 'CONFIG_INPUT|CONFIG_RMI4_CORE|CONFIG_RMI4_F55' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w rmi_corePrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.
- bookworm, trixie, forky, sid, bookworm · linux-6.12Mnot built on arm64/cloud-arm64
- M
- a module where it is built at all; some flavours do not build it
- Build switches
- CONFIG_INPUT, CONFIG_RMI4_CORE, CONFIG_RMI4_F55
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-09-03 (2 months ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.12%, higher than 1.7% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- drivers/input
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 4.10 | 5.10.266 | 6484e00d6778 |
| 4.10 | 5.15.217 | db4e20265ebd |
| 4.10 | 6.1.184 | a6d9646e77da |
| 4.10 | 6.6.153 | 0739c65e799d |
| 4.10 | 6.12.105 | 9759502f5cd7 |
| 4.10 | 6.18.46 | 9b184c8337c6 |
| 4.10 | 7.1.10 | a81cafe3c3c2 |
| 4.10 | 7.2 | 6058f0fea10f |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4788-1 | 2026-09-19 | bookworm 6.12.107-1~deb12u1 | tracker |
| DLA-4777-1 | 2026-09-08 | bookworm 6.1.187-1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- Exploitation requires local V4L2 ioctls (STREAMON/QBUF) on the synaptics-rmi4 F54 diagnostics node (/dev/video* or /dev/v4l-touch*) that drive rmi_f54_buffer_queue() into rmi_f54_work(); the touch controller is on-board I2C/SPI/SMBus, not reachable over a network protocol.
- AC:LAttack complexity, low
- On affected Synaptics hardware with more RX than TX electrodes and CONFIG_RMI4_F54 enabled, the inflated F55 TX count makes rmi_f54_get_report_size() exceed the F54-probe allocation deterministically; an attacker with device access can queue capture buffers without races or layout-dependent conditions.
- PR:LPrivileges required, low
- No kernel capability is required beyond permission to open the registered VFL_TYPE_TOUCH video device and issue standard V4L2 capture ioctls; on typical laptops, kiosks, and Android builds this is granted to unprivileged local users via video/input device policy without init-namespace root.
- UI:NUser interaction, none
- No cooperative victim action is needed; the attacker opens the diagnostics node, selects a 16-bit F54 report type, and streams capture buffers to trigger the overflow without requiring another user to plug hardware, mount filesystems, or interact with the system.
- S:UScope, unchanged
- Impact is confined to host kernel heap memory within the same security boundary; this is a kmalloc buffer overflow in the input driver and does not inherently provide VM escape, IOMMU bypass, or cross-sandbox authority change.
- C:HConfidentiality impact, high
- The inflated report_size causes rmi_f54_work() to read past the end of report_data and rmi_f54_buffer_queue() memcpy() copies that oversized payload into userspace, leaking adjacent kernel heap/slab contents that can include sensitive pointers and kernel memory.
- I:HIntegrity impact, high
- The device read loop writes attacker-influenced diagnostic bytes up to tens of kilobytes past the devm-allocated report_data buffer, corrupting adjacent heap objects and enabling control-flow hijacking or privilege-escalation primitives typical of kernel heap overflows.
- A:HAvailability impact, high
- Corrupting adjacent slab objects via the out-of-bounds write can immediately panic or oops the kernel; the overflow is repeatable on each queued V4L2 buffer while the mis-probed F55 electrode counts remain in drv_data on affected hardware.