ACK: [SRU][J][PATCH 0/1] CVE-2025-39726

[Andrei Gherzan]

On 2026/09/18 10:53PM, Cengiz Can via kernel-team wrote:
> https://ubuntu.com/security/CVE-2025-39726
> 
> [ Impact ]
> 
> 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.
> 
> [ Fix ]
> 
> jammy/linux: backported from 897e8601b9cf
> 
> The fix serializes command submission in ism_cmd() by introducing a per-device
> cmd_lock spinlock so that only one request-response sequence is in flight for a
> given ISM function at any time.
> 
> In this tree the include/linux/ism.h header does not exist; struct ism_dev
> instead lives in drivers/s390/net/ism.h, so the new cmd_lock member was added
> there and the automatically created include/linux/ism.h was dropped from the
> backport.
> 
> [ Test Plan ]
> 
> Build and boot tested.
> 
> [ Where Problems Could Occur ]
> 
> A bad fix would primarily affect s390x systems that use ISM devices, that is,
> IBM Z machines running SMC-D over Internal Shared Memory; incorrect locking
> could serialize command submission too aggressively and hurt SMC-D connection
> setup and throughput, or in the worst case reintroduce command corruption. All
> other architectures are unaffected, as is s390x hardware that does not have ISM
> functions configured or that does not use SMC-D.
> 
> [ Other Info ]
> 
> Kybele flow-v12-16-g3521c8c5. Reference: 3cd24883/v1

Acked-by: Andrei Gherzan <andrei.gherzan at canonical.com>

-- 
Andrei Gherzan
gpg: rsa4096/D4D94F67AD0E9640
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20260921/0531af08/attachment.sig>