{"answers":{"affected":"","exploited":"There is no known exploitation of CVE-2026-80569 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2026-80569 is a high-severity memory corruption vulnerability in Linux, published on 26 Aug 2026. It can only be exploited from the same machine or local network, with no action from the victim."},"fix_prompt":"Check this codebase for CVE-2026-80569 and fix it if it is affected.\n\nWhat it is: CVE-2026-80569 is a high-severity memory corruption vulnerability in Linux, published on 26 Aug 2026. It can only be exploited from the same machine or local network, with no action from the victim.\nExploitation: There is no known exploitation of CVE-2026-80569 in the wild and no public exploit code.\n\nAffected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page.\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/CVE-2026-80569/ (Markdown: https://insights.sbomify.com/CVE-2026-80569/index.md)","id":"CVE-2026-80569","markdown":"https://insights.sbomify.com/CVE-2026-80569/index.md","name":"CVE-2026-80569","record":{"aliases":["AZL-97803","BELL-CVE-2026-80569","DEBIAN-CVE-2026-80569","GHSA-3268-6g62-7794","UBUNTU-CVE-2026-80569"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["code_execution","denial_of_service"],"network_reachable":"adjacent_or_local","non_default_config":false,"product_category":"Linux kernel driver","requires_auth":"low_privilege","summary":"A malicious RMI4 device can trigger a buffer overflow in the Synaptics RMI4 driver, potentially leading to code execution or system crash.","user_interaction":"not_required","vuln_class":"memory_corruption"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[],"cvss":{"score":7.8,"severity":"high","source":"cna","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","version":"3.1"},"cwes":[],"description":"In the Linux kernel, the following vulnerability has been resolved:\n\nInput: synaptics-rmi4 - bound the F54 report size to the allocated buffer\n\nrmi_f54_work() reads a diagnostics report from the device into\nf54-\u003ereport_data, sizing the transfer with rmi_f54_get_report_size():\n\n\treport_size = rmi_f54_get_report_size(f54);\n\t...\n\tfor (i = 0; i \u003c report_size; i += F54_REPORT_DATA_SIZE) {\n\t\tint size = min(F54_REPORT_DATA_SIZE, report_size - i);\n\t\t...\n\t\trmi_read_block(.., f54-\u003ereport_data + i, size);\n\t}\n\nreport_data is allocated once at probe from F54's own electrode counts\n(array3_size(f54-\u003enum_tx_electrodes, f54-\u003enum_rx_electrodes, sizeof(u16))),\nbut rmi_f54_get_report_size() computes the size from\ndrv_data-\u003enum_*_electrodes when those are set, i.e. from the F55\nfunction's electrode counts. Both counts come straight from device\nqueries (F54 and F55 each report up to 255 electrodes) and nothing\nconstrains the F55 counts to the F54 ones.\n\nA malicious or malfunctioning RMI4 device that reports larger F55\nelectrode counts than its F54 counts makes report_size exceed the\nallocation, so the read loop writes past report_data (and the V4L2\ndequeue memcpy() then reads past it). On conforming hardware the F55\nconfigured electrodes are a subset of the F54 physical electrodes, so\nreport_size never exceeds the buffer and well-behaved devices are\nunaffected.\n\nRecord the allocation size and reject a report that does not fit,\nmirroring the existing zero-size check.","ecosystems":[],"exploits":{"exploitdb":0,"first_seen":null,"github_poc":0,"max_poc_stars":null,"metasploit":0,"nuclei":0,"refs":[],"tier":"none_known"},"has_fix":true,"headline":"Input: synaptics-rmi4 - bound the F54 report size to the allocated buffer","id":"CVE-2026-80569","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":null,"products":[],"type":"memory_corruption","year":"2026"},"n_packages":0,"n_references":8,"next":{"headline":"Input: synaptics-rmi4 - zero report size on F54 work error","id":"CVE-2026-80570"},"packages":[],"prev":{"headline":"Input: synaptics-rmi4 - block s_input when F54 queue is busy","id":"CVE-2026-80568"},"products":["Linux"],"published":"2026-08-26","related":[],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"},{"class":"attribution","licence":"FIRST CVSS licence","name":"CVSS (FIRST)"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":"PUBLISHED","updated":"2026-08-27","vendors":["Linux"]},"summary":"A malicious RMI4 device can trigger a buffer overflow in the Synaptics RMI4 driver, potentially leading to code execution or system crash.","url":"https://insights.sbomify.com/CVE-2026-80569/"}