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&#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&#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&#39;t feel confident about<br />
providing an exhaustive list of possible consequences.