linux-stable.git/drivers/s390, branch linux-rolling-lts

s390/monwriter: Reject buffer reuse with different data length

2026-07-24T14:17:15+00:00

commit 2995ccec260caa9e85b3301a4aba1e66ed80ad74 upstream.

When data buffers are reused, e.g. for interval sample records, the
first record determines the data length, and the size of the buffer for
user copy. Current monwriter code does not check if the data length was
changed for subsequent records, which also would never happen for valid
user programs.

However, a malicious user could change the data length, resulting in out
of bounds user copy to the kernel buffer, and memory corruption. By
default, the monwriter misc device is created with root-only permissions,
so practical impact is typically low.

Fix this by checking for changed data length and rejecting such records.

Cc: stable@vger.kernel.org
Signed-off-by: Gerald Schaefer 
Reviewed-by: Christian Borntraeger 
Signed-off-by: Vasily Gorbik 
Signed-off-by: Greg Kroah-Hartman

pkey: Move keytype check from pkey api to handler

2026-07-24T14:17:05+00:00

commit 754e9e49b76fd5be339172aa98544182ed3ca75e upstream.

The PKEY_VERIFYPROTK ioctl takes data from user-space and verifies the
contained protected key. While checking the integrity of the ioctl
request structure is the responsibility of the generic pkey_api code,
the verification of the contained protected key is the responsibility
of the pkey handler.

The keytype verification (based on the calculated bitsize of the key)
is part of the protected key verification and therefore the
responsibility of the pkey handler (which already verifies
it). Therefore the keytype verification is removed from the generic
pkey_api code.

As the calculation of the key bitsize is currently wrong, the removal
of the keytype check in pkey_api also removes this wrong
calculation. For this reason, the commit is flagged with the Fixes:
tag.

Cc: stable@kernel.org # 6.12+
Fixes: 8fcc231ce3be ("s390/pkey: Introduce pkey base with handler registry and handler modules")
Reviewed-by: Ingo Franzki 
Reviewed-by: Harald Freudenberger 
Signed-off-by: Holger Dengler 
Signed-off-by: Alexander Gordeev 
Signed-off-by: Vasily Gorbik 
Signed-off-by: Greg Kroah-Hartman

s390/pkey: Check length in pkey_pckmo handler implementation

2026-07-24T14:17:03+00:00

commit 1ac287e2af9a9112fe271427ef45eceb26bce8b4 upstream.

Explicitly check the length of the target buffer in the pkey_pckmo
implementation of the key_to_protkey() handler function. The handler
function fails, if the generated output data exceeds the length of the
provided target buffer.

Cc: stable@vger.kernel.org
Fixes: 8fcc231ce3be ("s390/pkey: Introduce pkey base with handler registry and handler modules")
Reported-by: Christian Borntraeger 
Reviewed-by: Harald Freudenberger 
Signed-off-by: Holger Dengler 
Signed-off-by: Alexander Gordeev 
Signed-off-by: Greg Kroah-Hartman

s390/pkey: Check length in PKEY_VERIFYPROTK ioctl

2026-07-24T14:17:03+00:00

commit b3d4ab2d7df9426f7f1d3671d7e2108f2ca6e970 upstream.

Explicitly check the buffer length request structure provided by
user-space and fail, if it exceeds the buffer size.

Cc: stable@vger.kernel.org
Fixes: 8fcc231ce3be ("s390/pkey: Introduce pkey base with handler registry and handler modules")
Reported-by: Christian Borntraeger 
Reviewed-by: Harald Freudenberger 
Reviewed-by: Ingo Franzki 
Signed-off-by: Holger Dengler 
Signed-off-by: Alexander Gordeev 
Signed-off-by: Greg Kroah-Hartman

s390/zcrypt: Remove the empty file

2026-07-24T14:16:50+00:00

[ Upstream commit 575f87b9d4882b0d621192fdd754d7e09dbd5789 ]

The files has no real user because CEX2 and CEX3 device drivers
are removed, also remove these empty files.

Fixes: 5ac8c72462cd ("s390/zcrypt: remove CEX2 and CEX3 device drivers")
Signed-off-by: Rongguang Wei 
Reviewed-by: Holger Dengler 
Signed-off-by: Vasily Gorbik 
Signed-off-by: Sasha Levin

s390/cio: Restore GFP_DMA for CHSC allocation

2026-06-09T10:28:32+00:00

[ Upstream commit ea34567db0a6b3a7ce78ba421592344315c8f90e ]

Re-add GFP_DMA when allocating memory for CHSC control blocks.
On some supported machines, CHSC cannot access memory outside
the DMA zone, causing CHSC command failures.

Cc: stable@vger.kernel.org
Fixes: a3a64a4def8d ("s390/cio: remove unneeded DMA zone allocation")
Signed-off-by: Peter Oberparleiter 
Reviewed-by: Heiko Carstens 
Signed-off-by: Alexander Gordeev 
[ adjusted context to account for missing commit bf4afc53b77ae ]
Signed-off-by: Peter Oberparleiter 
Signed-off-by: Sasha Levin

s390/cio: use generic driver_override infrastructure

2026-05-23T11:06:24+00:00

[ Upstream commit ac4d8bb6e2e13e8684a76ea48d13ebaaaf5c24c4 ]

When a driver is probed through __driver_attach(), the bus' match()
callback is called without the device lock held, thus accessing the
driver_override field without a lock, which can cause a UAF.

Fix this by using the driver-core driver_override infrastructure taking
care of proper locking internally.

Note that calling match() from __driver_attach() without the device lock
held is intentional. [1]

Link: https://lore.kernel.org/driver-core/DGRGTIRHA62X.3RY09D9SOK77P@kernel.org/ [1]
Reported-by: Gui-Dong Han 
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220789
Fixes: ebc3d1791503 ("s390/cio: introduce driver_override on the css bus")
Reviewed-by: Vineeth Vijayan 
Link: https://patch.msgid.link/20260324005919.2408620-10-dakr@kernel.org
Signed-off-by: Danilo Krummrich 
Signed-off-by: Sasha Levin

s390/zcrypt: Fix memory leak with CCA cards used as accelerator

2026-04-11T12:26:45+00:00

commit c8d46f17c2fc7d25c18e60c008928aecab26184d upstream.

Tests showed that there is a memory leak if CCA cards are used as
accelerator for clear key RSA requests (ME and CRT). With the last
rework for the memory allocation the AP messages are allocated by
ap_init_apmsg() but for some reason on two places (ME and CRT) the
older allocation was still in place. So the first allocation simple
was never freed.

Fixes: 57db62a130ce ("s390/ap/zcrypt: Rework AP message buffer allocation")
Reported-by: Yi Zhang 
Closes: https://lore.kernel.org/linux-s390/CAHj4cs9H67Uz0iVaRQv447p7JFPRPy3TKAT4=Y6_e=wSHCZM5w@mail.gmail.com/
Reported-by: Nadja Hariz 
Cc: stable@vger.kernel.org
Reviewed-by: Ingo Franzki 
Reviewed-by: Holger Dengler 
Acked-by: Heiko Carstens 
Signed-off-by: Harald Freudenberger 
Signed-off-by: Vasily Gorbik 
Signed-off-by: Greg Kroah-Hartman

s390/dasd: Copy detected format information to secondary device

2026-03-19T15:08:43+00:00

commit 4c527c7e030672efd788d0806d7a68972a7ba3c1 upstream.

During online processing for a DASD device an IO operation is started to
determine the format of the device. CDL format contains specifically
sized blocks at the beginning of the disk.

For a PPRC secondary device no real IO operation is possible therefore
this IO request can not be started and this step is skipped for online
processing of secondary devices. This is generally fine since the
secondary is a copy of the primary device.

In case of an additional partition detection that is run after a swap
operation the format information is needed to properly drive partition
detection IO.

Currently the information is not passed leading to IO errors during
partition detection and a wrongly detected partition table which in turn
might lead to data corruption on the disk with the wrong partition table.

Fix by passing the format information from primary to secondary device.

Fixes: 413862caad6f ("s390/dasd: add copy pair swap capability")
Cc: stable@vger.kernel.org #6.1
Reviewed-by: Jan Hoeppner 
Acked-by: Eduard Shishkin 
Signed-off-by: Stefan Haberland 
Link: https://patch.msgid.link/20260310142330.4080106-3-sth@linux.ibm.com
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

s390/dasd: Move quiesce state with pprc swap

2026-03-19T15:08:43+00:00

commit 40e9cd4ae8ec43b107ed2bff422a8fa39dcf4e4b upstream.

Quiesce and resume is a mechanism to suspend operations on DASD devices.
In the context of a controlled copy pair swap operation, the quiesce
operation is usually issued before the actual swap and a resume
afterwards.

During the swap operation, the underlying device is exchanged. Therefore,
the quiesce flag must be moved to the secondary device to ensure a
consistent quiesce state after the swap.

The secondary device itself cannot be suspended separately because there
is no separate block device representation for it.

Fixes: 413862caad6f ("s390/dasd: add copy pair swap capability")
Cc: stable@vger.kernel.org #6.1
Reviewed-by: Jan Hoeppner 
Signed-off-by: Stefan Haberland 
Link: https://patch.msgid.link/20260310142330.4080106-2-sth@linux.ibm.com
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman