{"dataType":"CVE_RECORD","dataVersion":"5.2","cveMetadata":{"cveId":"CVE-2025-39726","assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","state":"PUBLISHED","assignerShortName":"Linux","dateReserved":"2025-04-16T07:20:57.117Z","datePublished":"2025-09-05T17:27:19.818Z","dateUpdated":"2026-08-05T12:04:53.432Z"},"containers":{"cna":{"providerMetadata":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-08-05T12:04:53.432Z"},"descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\ns390/ism: fix concurrency management in ism_cmd()\n\nThe s390x ISM device data sheet clearly states that only one\nrequest-response sequence is allowable per ISM function at any point in\ntime.  Unfortunately as of today the s390/ism driver in Linux does not\nhonor that requirement. This patch aims to rectify that.\n\nThis problem was discovered based on Aliaksei's bug report which states\nthat for certain workloads the ISM functions end up entering error state\n(with PEC 2 as seen from the logs) after a while and as a consequence\nconnections handled by the respective function break, and for future\nconnection requests the ISM device is not considered -- given it is in a\ndysfunctional state. During further debugging PEC 3A was observed as\nwell.\n\nA kernel message like\n[ 1211.244319] zpci: 061a:00:00.0: Event 0x2 reports an error for PCI function 0x61a\nis a reliable indicator of the stated function entering error state\nwith PEC 2. Let me also point out that a kernel message like\n[ 1211.244325] zpci: 061a:00:00.0: The ism driver bound to the device does not support error recovery\nis a reliable indicator that the ISM function won't be auto-recovered\nbecause the ISM driver currently lacks support for it.\n\nOn a technical level, without this synchronization, commands (inputs to\nthe FW) may be partially or fully overwritten (corrupted) by another CPU\ntrying to issue commands on the same function. There is hard evidence that\nthis can lead to DMB token values being used as DMB IOVAs, leading to\nPEC 2 PCI events indicating invalid DMA. But this is only one of the\nfailure modes imaginable. In theory even completely losing one command\nand executing another one twice and then trying to interpret the outputs\nas if the command we intended to execute was actually executed and not\nthe other one is also possible.  Frankly, I don't feel confident about\nproviding an exhaustive list of possible consequences."}],"metrics":[{"cvssV3_1":{"version":"3.1","vectorString":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H","baseScore":9.8,"baseSeverity":"CRITICAL"},"scenarios":[{"lang":"en","value":"AV:N - Every path into `ism_cmd()` is driven by the SMC protocol stack — a remote TCP peer connecting to an SMC-enabled listener causes `smc_listen_work` to issue ISM QUERY_RGID/ADD_VLAN_ID/REG_DMB commands using values from the peer's CLC Proposal, and closing the connection issues SIGNAL_IEQ/UNREG_DMB/DEL_VLAN_ID from the unserialized lgr-free work. The attacker never needs local access.\nAC:L - The attacker controls both sides of the race by churning concurrent SMC-D connection setups and teardowns, which execute `ism_cmd()` in parallel on different CPUs (setup under `smc_*_lgr_pending`, teardown under no serialization at all). The commit confirms ordinary workloads already hit this \"after a while,\" so deliberate hammering is reliable.\nPR:N - The SMC CLC handshake has no authentication and `af_smc.c` contains no capability checks, so `smc_ism_cantalk()` reaches `ism_cmd()` with peer-supplied GID/CHID before any credential is ever presented. Locally the equivalent path needs only an unprivileged AF_SMC socket or `TCP_ULP=smc`.\nUI:N - Triggering requires only that the attacker open and close connections; no action by any local user or administrator is needed. The victim host merely has to have an ISM device and SMC-D in use, which is configuration, not interaction.\nS:U - The corrupted commands and misrouted DMB registrations affect resources managed by the same kernel/ISM-function security authority, and bad DMA is contained by the zPCI translation hardware. No hypervisor, LPAR, or IOMMU boundary is escaped.\nC:H - A response read back for the wrong command makes `ism_register_dmb()` store another command's `dmb_tok`, and that token is advertised to the remote peer in the CLC message, so the local socket ends up reading a different connection's DMB contents — cross-connection, cross-user, cross-LPAR payload disclosure. Corrupted `REG_DMB.rgid` similarly exposes a buffer to an unintended remote GID.\nI:H - With a misassigned DMB token the remote peer's ISM move writes application data directly into a different connection's receive buffer, and a corrupted `UNREG_DMB.dmb_tok` unregisters the wrong DMB in firmware while the driver's view diverges. The maintainer states commands may be partially overwritten or executed twice with outputs misinterpreted, and declines to bound the consequences.\nA:H - Command corruption puts the ISM PCI function into error state (PEC 2/3A), breaking every SMC-D connection on it, and the ISM driver implements no error recovery so the device is permanently excluded from future connections until manual intervention. This is a persistent denial of service affecting all users of the adapter."}]}],"affected":[{"product":"Linux","vendor":"Linux","defaultStatus":"unaffected","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["drivers/s390/net/ism_drv.c","include/linux/ism.h"],"versions":[{"version":"684b89bc39ce4f204b1a2b180f39f2eb36a6b695","lessThan":"faf44487dfc80817f178dc8de7a0b73f960d019b","status":"affected","versionType":"git"},{"version":"684b89bc39ce4f204b1a2b180f39f2eb36a6b695","lessThan":"1194ad0d44d66b273a02a3a22882dc863a68d764","status":"affected","versionType":"git"},{"version":"684b89bc39ce4f204b1a2b180f39f2eb36a6b695","lessThan":"fafaa4982bedb5532f5952000f714a3e63023f40","status":"affected","versionType":"git"},{"version":"684b89bc39ce4f204b1a2b180f39f2eb36a6b695","lessThan":"897e8601b9cff1d054cdd53047f568b0e1995726","status":"affected","versionType":"git"}]},{"product":"Linux","vendor":"Linux","defaultStatus":"affected","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["drivers/s390/net/ism_drv.c","include/linux/ism.h"],"versions":[{"version":"4.19","status":"affected"},{"version":"0","lessThan":"4.19","status":"unaffected","versionType":"semver"},{"version":"6.6.101","lessThanOrEqual":"6.6.*","status":"unaffected","versionType":"semver"},{"version":"6.12.41","lessThanOrEqual":"6.12.*","status":"unaffected","versionType":"semver"},{"version":"6.15.9","lessThanOrEqual":"6.15.*","status":"unaffected","versionType":"semver"},{"version":"6.16","lessThanOrEqual":"*","status":"unaffected","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"operator":"OR","negate":false,"cpeMatch":[{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"4.19","versionEndExcluding":"6.6.101"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"4.19","versionEndExcluding":"6.12.41"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"4.19","versionEndExcluding":"6.15.9"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"4.19","versionEndExcluding":"6.16"}]}]}],"references":[{"url":"https://git.kernel.org/stable/c/faf44487dfc80817f178dc8de7a0b73f960d019b"},{"url":"https://git.kernel.org/stable/c/1194ad0d44d66b273a02a3a22882dc863a68d764"},{"url":"https://git.kernel.org/stable/c/fafaa4982bedb5532f5952000f714a3e63023f40"},{"url":"https://git.kernel.org/stable/c/897e8601b9cff1d054cdd53047f568b0e1995726"}],"title":"s390/ism: fix concurrency management in ism_cmd()","x_generator":{"engine":"bippy-1.2.0"}}}}