Instituto Nacional de ciberseguridad. Sección Incibe
Instituto Nacional de Ciberseguridad. Sección INCIBE-CERT

CVE-2025-39726

Gravedad:
Pendiente de análisis
Tipo:
No Disponible / Otro tipo
Fecha de publicación:
05/09/2025
Última modificación:
08/09/2025

Descripción

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/ism: fix concurrency management in ism_cmd()<br /> <br /> The s390x ISM device data sheet clearly states that only one<br /> request-response sequence is allowable per ISM function at any point in<br /> time. Unfortunately as of today the s390/ism driver in Linux does not<br /> honor that requirement. This patch aims to rectify that.<br /> <br /> This problem was discovered based on Aliaksei&amp;#39;s bug report which states<br /> that for certain workloads the ISM functions end up entering error state<br /> (with PEC 2 as seen from the logs) after a while and as a consequence<br /> connections handled by the respective function break, and for future<br /> connection requests the ISM device is not considered -- given it is in a<br /> dysfunctional state. During further debugging PEC 3A was observed as<br /> well.<br /> <br /> A kernel message like<br /> [ 1211.244319] zpci: 061a:00:00.0: Event 0x2 reports an error for PCI function 0x61a<br /> is a reliable indicator of the stated function entering error state<br /> with PEC 2. Let me also point out that a kernel message like<br /> [ 1211.244325] zpci: 061a:00:00.0: The ism driver bound to the device does not support error recovery<br /> is a reliable indicator that the ISM function won&amp;#39;t be auto-recovered<br /> because the ISM driver currently lacks support for it.<br /> <br /> On a technical level, without this synchronization, commands (inputs to<br /> the FW) may be partially or fully overwritten (corrupted) by another CPU<br /> trying to issue commands on the same function. There is hard evidence that<br /> this can lead to DMB token values being used as DMB IOVAs, leading to<br /> PEC 2 PCI events indicating invalid DMA. But this is only one of the<br /> failure modes imaginable. In theory even completely losing one command<br /> and executing another one twice and then trying to interpret the outputs<br /> as if the command we intended to execute was actually executed and not<br /> the other one is also possible. Frankly, I don&amp;#39;t feel confident about<br /> providing an exhaustive list of possible consequences.

Impacto