CVE-2025-39726: s390/ism: fix concurrency management in ism_cmd()
In the Linux kernel, the following vulnerability has been resolved:
s390/ism: fix concurrency management in ism_cmd()
The s390x ISM device data sheet clearly states that only one
request-response sequence is allowable per ISM function at any point in
time. Unfortunately as of today the s390/ism driver in Linux does not
honor that requirement. This patch aims to rectify that.
This problem was discovered based on Aliaksei's bug report which states
that for certain workloads the ISM functions end up entering error state
(with PEC 2 as seen from the logs) after a while and as a consequence
connections handled by the respective function break, and for future
connection requests the ISM device is not considered -- given it is in a
dysfunctional state. During further debugging PEC 3A was observed as
well.
A kernel message like
[ 1211.244319] zpci: 061a:00:00.0: Event 0x2 reports an error for PCI function 0x61a
is a reliable indicator of the stated function entering error state
with PEC 2. Let me also point out that a kernel message like
[ 1211.244325] zpci: 061a:00:00.0: The ism driver bound to the device does not support error recovery
is a reliable indicator that the ISM function won't be auto-recovered
because the ISM driver currently lacks support for it.
On a technical level, without this synchronization, commands (inputs to
the FW) may be partially or fully overwritten (corrupted) by another CPU
trying to issue commands on the same function. There is hard evidence that
this can lead to DMB token values being used as DMB IOVAs, leading to
PEC 2 PCI events indicating invalid DMA. But this is only one of the
failure modes imaginable. In theory even completely losing one command
and executing another one twice and then trying to interpret the outputs
as if the command we intended to execute was actually executed and not
the other one is also possible. Frankly, I don't feel confident about
providing an exhaustive list of possible consequences.
Security readout for executives and security teams
Plain-English summary
A race condition in the Linux s390x ISM driver can corrupt commands sent to device firmware. Under certain workloads, an ISM function may enter an error state, break associated connections, and remain unavailable because the driver lacks automatic error recovery. The issue is important but applies specifically to systems using this architecture, device, and driver.
Executive priority
Treat remediation as urgent for production s390x systems relying on ISM-backed connections, particularly where device failure would interrupt critical services. Prioritize exposure confirmation first because applicability is narrow. The critical rating warrants attention, but the sources do not substantiate active attacks or confirmed confidentiality and integrity compromise.
Technical view
ism_cmd() failed to serialize request-response sequences even though firmware permits only one active sequence per ISM function. Concurrent CPUs could overwrite command inputs or mismatch commands and responses. Confirmed consequences include DMB tokens being treated as DMB IOVAs, invalid DMA, PCI PEC 2 events, and connection failures. The referenced stable commits add synchronization.
Likely exposure
Exposure is limited to Linux s390x hosts using an ISM function and an affected kernel revision. Other architectures and systems without the ISM driver are not identified as exposed. The supplied version data includes 4.19, 6.6.101, 6.12.41, 6.15.9, 6.16, and an ambiguous “0”; verify distribution backports and kernel provenance.
Exploitation context
The CVE is not listed in KEV, and the supplied sources provide no evidence of active exploitation or public weaponization. The documented trigger arose under certain concurrent workloads. Although the supplied CVSS vector specifies a network attack vector, the technical narrative does not establish how an unauthenticated remote attacker could reliably trigger the condition.
Researcher notes
Hard evidence covers command corruption, invalid DMA, device error states, and availability loss. Other outcomes are explicitly described as possible but not exhaustively established. The 9.8 CVSS vector assigns high confidentiality, integrity, and availability impact, yet the narrative provides no confirmed confidentiality or integrity compromise. No CWE is supplied.
Mitigation direction
Identify s390x systems using the ISM driver and inventory their running kernel versions.
Upgrade to a vendor-supported kernel containing the applicable referenced stable fix.
If upgrading is delayed, seek vendor guidance; the sources name no separate workaround.
Validation and detection
Confirm whether each host is s390x and has an ISM function bound to the ism driver.
Compare kernel provenance against the applicable referenced stable commit or vendor advisory.
Review kernel logs for zpci PEC 2 or PEC 3A events and ISM recovery-limitation messages.
After remediation, monitor affected connection workloads for recurring ISM function errors or broken connections.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
description · low confidence lookup
Credential and access behavior lookup
The CVE wording references authentication or credential exposure, so valid-account and credential-access review may help. This is a Glexia inferred lookup path, not an official MITRE, ATT&CK, or CVE Program mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
0ADP providers
5Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.