CVE-2025-39726
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-09-05

Last updated on: 2025-11-25

Assigner: kernel.org

Description
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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-09-05
Last Modified
2025-11-25
Generated
2026-05-27
AI Q&A
2025-09-05
EPSS Evaluated
2026-05-25
NVD
CVE-2025-39726
Affected Vendors & Products
Showing 10 associated CPEs
Vendor Product Version / Range
linux linux_kernel 6.16
linux linux_kernel 6.16
linux linux_kernel 6.16
linux linux_kernel 6.16
linux linux_kernel 6.16
linux linux_kernel 6.16
linux linux_kernel 6.16
linux linux_kernel From 5.15.160 (inc) to 5.16 (inc)
linux linux_kernel From 5.15.160 (inc) to 5.16 (inc)
linux linux_kernel From 5.15.160 (inc) to 5.16 (inc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-362 The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability is in the Linux kernel's s390/ism driver, which does not properly manage concurrency for ISM functions. The s390x ISM device requires that only one request-response sequence be active per ISM function at a time, but the driver fails to enforce this. As a result, commands can be corrupted or overwritten when multiple CPUs issue commands simultaneously, leading to errors such as invalid DMA operations and the ISM function entering an error state. This causes connections handled by the function to break and future requests to fail because the device becomes dysfunctional.


How can this vulnerability impact me? :

The impact of this vulnerability includes the ISM function entering an error state, which breaks existing connections and prevents new connections from being handled properly. This can cause system instability or failure in workloads relying on the ISM device, potentially leading to service interruptions or degraded performance due to the device becoming dysfunctional and not recovering automatically.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by monitoring kernel messages for specific error indicators related to the ISM function entering an error state. Look for messages such as: '[timestamp] zpci: [device]: Event 0x2 reports an error for PCI function [function]' which indicates PEC 2 errors, and '[timestamp] zpci: [device]: The ism driver bound to the device does not support error recovery' which indicates the ISM function won't auto-recover. Commands like 'dmesg | grep zpci' or 'journalctl -k | grep zpci' can be used to filter these kernel messages.


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation involves applying the patch that fixes concurrency management in ism_cmd() in the s390/ism driver to ensure only one request-response sequence per ISM function at a time. Until the patch is applied, monitoring for the error messages and avoiding workloads that trigger the issue may help reduce impact. Since the ISM driver currently lacks error recovery support, manual intervention may be required if the device enters an error state.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart