CVE-2026-80569Patch

LOWCVSS 7.8 · HIGH

Signal is active with 2 mentions in latest observed window

Immediate actions

  • Patch affected systems immediately

Recommended action window: Monitor and triage in normal cycle

NVD description

In the Linux kernel, the following vulnerability has been resolved: Input: synaptics-rmi4 - bound the F54 report size to the allocated buffer rmi_f54_work() reads a diagnostics report from the device into f54->report_data, sizing the transfer with rmi_f54_get_report_size(): report_size = rmi_f54_get_report_size(f54); ... for (i = 0; i < report_size; i += F54_REPORT_DATA_SIZE) { int size = min(F54_REPORT_DATA_SIZE, report_size - i); ... rmi_read_block(.., f54->report_data + i, size); } report_data is allocated once at probe from F54's own electrode counts (array3_size(f54->num_tx_electrodes, f54->num_rx_electrodes, sizeof(u16))), but rmi_f54_get_report_size() computes the size from drv_data->num_*_electrodes when those are set, i.e. from the F55 function's electrode counts. Both counts come straight from device queries (F54 and F55 each report up to 255 electrodes) and nothing constrains the F55 counts to the F54 ones. A malicious or malfunctioning RMI4 device that reports larger F55 electrode counts than its F54 counts makes report_size exceed the allocation, so the read loop writes past report_data (and the V4L2 dequeue memcpy() then reads past it). On conforming hardware the F55 configured electrodes are a subset of the F54 physical electrodes, so report_size never exceeds the buffer and well-behaved devices are unaffected. Record the allocation size and reject a report that does not fit, mirroring the existing zero-size check.

0.5/ 10 priority

Sources & remediation

Priority

LOW

Exploitation

NONE

PoC

NONE

Patch

AVAILABLE

Momentum

STABLE

Threat summary

  • Patch or workaround signal is available
  • 3 mentions across 2 observed days
  • Momentum state: stable

What's happening

  • Patch or workaround mentioned in 2 signals
  • Technical details provided in 2 signals
  • General: 1 classified signal
  • Peaked at 2 mentions on most recent observed day (2026-08-28)
  • 3 total mentions across 2 days

Deep dive

Activity timeline3 mentions / 2d
01122Mentions · 2026-08-26: 1Mentions · 2026-08-28: 2Patch / Workaround · 2026-08-28: 2Technical Details · 2026-08-28: 208-2608-28
Signal classification2 categories
Patch
266.7%
General
133.3%
Referenced assets3 URLs
Classification over time
DateTotalLabels
2026-08-261
General1
2026-08-282
Patch2
Full discourse3 posts
  • Vulmon Vulnerability Feed@VulmonFeeds
    General

    CVE-2026-80569 Linux Kernel Vulnerability https://vulmon.com/vulnerabilitydetails?qid=CVE-2026-80569

    Post summary

    The text merely references CVE-2026-80569 and points to a vulnerability details page, offering no additional technical, exploitation, or remediation information.

    00010114
    4.1K followersView on X
  • Infoflowcloud@infoflowcloud
    Patch

    🚨*CVE* CVE-2026-80569 In the Linux kernel, the following vulnerability has been resolved: Input: synaptics-rmi4 - bound the F54 report size to the allocated buffer rmi_f54_work() reads a… https://www.cve.org/CVERecord?id=CVE-2026-80569 ----- Traducción: CVE-2026-80569 En … https://infoflow.cloud`

    Post summary

    The post notes that CVE-2026-80569 has been resolved in the Linux kernel, linking to the official CVE record, but provides no Exploit or PoC details.

    0000039
    102 followersView on X
  • CVE@CVEnew
    Patch

    CVE-2026-80569 In the Linux kernel, the following vulnerability has been resolved: Input: synaptics-rmi4 - bound the F54 report size to the allocated buffer rmi_f54_work() reads a… https://www.cve.org/CVERecord?id=CVE-2026-80569

    Post summary

    CVE‑2026‑80569 in the Linux kernel was fixed by bounding the F54 report size; no proof‑of‑concept, exploit, or active use is reported.

    000001.1K
    58.0K followersView on X

Explore more