PULSE
EN VIVO0señales / 24h
FEED
vulnKEV agrega CVE-2026-86060 — MikroTik / RouterOSvulnKEV agrega CVE-2026-67277 — MikroTik / RouterOSvulnKEV agrega CVE-2026-19490 — Citrix / NetScalervulnKEV agrega CVE-2025-25249 — Fortinet / Multiple ProductsvulnKEV agrega CVE-2026-87491 — Google / Chromium V8vulnKEV agrega CVE-2026-20079 — Cisco / Secure Firewall Management Center (FMC) and Security Cloud Control (SCC) Firewall ManagementvulnKEV agrega CVE-2026-75650 — Adobe / Commerce and MagentovulnKEV agrega CVE-2026-81963 — Microsoft / WindowsvulnKEV agrega CVE-2026-86218 — N-able / N-centralvulnKEV agrega CVE-2026-85880 — Microsoft / WindowsvulnKEV agrega CVE-2026-85046 — Google / Chromium V8vulnKEV agrega CVE-2026-59822 — BerriAI / LiteLLMvulnKEV agrega CVE-2026-48710 — Kludex / StarlettevulnKEV agrega CVE-2026-49869 — Kestra / Kestra OSSvulnKEV agrega CVE-2026-86060 — MikroTik / RouterOSvulnKEV agrega CVE-2026-67277 — MikroTik / RouterOSvulnKEV agrega CVE-2026-19490 — Citrix / NetScalervulnKEV agrega CVE-2025-25249 — Fortinet / Multiple ProductsvulnKEV agrega CVE-2026-87491 — Google / Chromium V8vulnKEV agrega CVE-2026-20079 — Cisco / Secure Firewall Management Center (FMC) and Security Cloud Control (SCC) Firewall ManagementvulnKEV agrega CVE-2026-75650 — Adobe / Commerce and MagentovulnKEV agrega CVE-2026-81963 — Microsoft / WindowsvulnKEV agrega CVE-2026-86218 — N-able / N-centralvulnKEV agrega CVE-2026-85880 — Microsoft / WindowsvulnKEV agrega CVE-2026-85046 — Google / Chromium V8vulnKEV agrega CVE-2026-59822 — BerriAI / LiteLLMvulnKEV agrega CVE-2026-48710 — Kludex / StarlettevulnKEV agrega CVE-2026-49869 — Kestra / Kestra OSS
← Todos los CVEs
CVE Watch11 sept 2026

CVE-2026-80975

In the Linux kernel, the following vulnerability has been resolved: mfd: qnap-mcu: keep the reply buffer alive past a command timeout qnap

CVSS

Sin CVSS

EPSS

KEV

Exploit Today

0-100

Publicado: 11 sept 2026 · Última mod.: 11 sept 2026

EPSS · 30d

Sin historial EPSS suficiente todavía.

Descripción técnica

In the Linux kernel, the following vulnerability has been resolved: mfd: qnap-mcu: keep the reply buffer alive past a command timeout qnap_mcu_exec() publishes an on-stack buffer to the receive path: unsigned char rx[QNAP_MCU_RX_BUFFER_SIZE]; ... reply->data = rx; reply->length = length; and qnap_mcu_receive_buf() writes into it from the serdev receive path, which runs out of flush_to_ldisc() and is not serialized against qnap_mcu_exec() at all. bus_lock cannot cover it, because qnap_mcu_exec() holds that mutex across wait_for_completion_timeout(). On a timeout qnap_mcu_exec() returns with reply->data still pointing at its own frame. A reply that arrives late, or an unsolicited message from the MCU, is then written into a stack frame that has been left, corrupting whatever runs next on that stack. The same applies when qnap_mcu_write() fails, since that path returns without touching the reply state either. Move the receive buffer into struct qnap_mcu. It is 37 bytes and the structure is devm_kzalloc()ed, so it lives as long as the driver, and a late write lands in memory that is still valid and is reinitialized by the next command. bus_lock keeps commands from sharing it. This deliberately does not clear reply->data or reply->length on the timeout path. Doing so races with qnap_mcu_receive_buf(), which reads both after its if (!reply->length) return size; check: clearing reply->data gives a NULL dereference, and clearing reply->length alone removes the reply->received == reply->length exit condition, so the copy loop runs until the uart chunk is consumed and overruns the buffer. Leaving both set keeps the write bounded by reply->length, which qnap_mcu_exec() has already checked against sizeof(mcu->rx).

Referencias oficiales
CVEs relacionados

Sin CVEs relacionados por CWE o producto.