[PATCH v3 0/2] Fixes related to domain access and verification

[PATCH v3 0/2] Fixes related to domain access and verification

[Harald Freudenberger]

This is now a combination of the two patch series
"Fix wrong domain value verification with EP11 cards" and
"Close speculative mem read possibility" as there is some
code dependency between the patches.

Changelog for "Fix wrong domain value verification with EP11 cards"

v1: initial version
v2: Resend without any code changes, just Finn's reviewed by added.

Changelog for "Close speculative mem read possibility"

v1: initial version
v2: Resend without any code changes, just Finn's reviewed by added.

Changelog for v3 and further:

v3: Resent without any changes, just this time as a 2-patches series.

Harald Freudenberger (2):
  s390/zcrypt: Fix wrong domain value verification with EP11 CPRBs
  s390/zcrypt: Close speculative mem read possibility

 drivers/s390/crypto/zcrypt_api.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--
2.43.0

[PATCH v3 1/2] s390/zcrypt: Fix wrong domain value verification with EP11 CPRBs

[Harald Freudenberger]

There is a wrong upper limit check for the domain value when an EP11
CPRB is processed for sending to a crypto card. This check is only
active on custom device nodes but may lead to access heap memory
behind perms->adm when an administrative CPRB is sent.
Add correct limit (AP_DOMAINS = 256) checking to fix this.

Fixes: cfd68b33094e ("s390/zcrypt: Filter admin CPRBs on custom devices")
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Reviewed-by: Finn Callies <fcallies@linux.ibm.com>
Cc: stable@vger.kernel.org
---
 drivers/s390/crypto/zcrypt_api.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/s390/crypto/zcrypt_api.c b/drivers/s390/crypto/zcrypt_api.c
index f57189c2b839..81eefdeae248 100644
--- a/drivers/s390/crypto/zcrypt_api.c
+++ b/drivers/s390/crypto/zcrypt_api.c
@@ -1077,7 +1077,7 @@ static long _zcrypt_send_ep11_cprb(u32 xflags, struct ap_perms *perms,
 	print_hex_dump_debug("ep11req: ", DUMP_PREFIX_ADDRESS, 16, 1,
 			     ap_msg.msg, ap_msg.len, false);
 
-	if (perms != &ap_perms && domain < AUTOSEL_DOM) {
+	if (perms != &ap_perms && domain < AP_DOMAINS) {
 		if (ap_msg.flags & AP_MSG_FLAG_ADMIN) {
 			if (!test_bit_inv(domain, perms->adm)) {
 				rc = -ENODEV;
-- 
2.43.0

[PATCH v3 2/2] s390/zcrypt: Close speculative mem read possibility

[Harald Freudenberger]

The domain value is extracted from a given CCA or EP11 ioctl struct
when a CPRB is about to be sent. Thus this is a user controlled value.
Under some special conditions (custom device node used, administrative
load) this value is used as an array index after bounds checking, but
without speculation barrier.

Add the missing array_index_nospec() call to prevent speculative
execution where this domain value is used.

Fixes: cfd68b33094e ("s390/zcrypt: Filter admin CPRBs on custom devices")
Reported-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Reviewed-by: Finn Callies <fcallies@linux.ibm.com>
Cc: stable@vger.kernel.org
---
 drivers/s390/crypto/zcrypt_api.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/s390/crypto/zcrypt_api.c b/drivers/s390/crypto/zcrypt_api.c
index 81eefdeae248..ec6a4c2f9f04 100644
--- a/drivers/s390/crypto/zcrypt_api.c
+++ b/drivers/s390/crypto/zcrypt_api.c
@@ -879,6 +879,7 @@ static long _zcrypt_send_cprb(u32 xflags, struct ap_perms *perms,
 
 	if (perms != &ap_perms && domain < AP_DOMAINS) {
 		if (ap_msg.flags & AP_MSG_FLAG_ADMIN) {
+			domain = array_index_nospec(domain, AP_DOMAINS);
 			if (!test_bit_inv(domain, perms->adm)) {
 				rc = -ENODEV;
 				goto out;
@@ -1079,6 +1080,7 @@ static long _zcrypt_send_ep11_cprb(u32 xflags, struct ap_perms *perms,
 
 	if (perms != &ap_perms && domain < AP_DOMAINS) {
 		if (ap_msg.flags & AP_MSG_FLAG_ADMIN) {
+			domain = array_index_nospec(domain, AP_DOMAINS);
 			if (!test_bit_inv(domain, perms->adm)) {
 				rc = -ENODEV;
 				goto out;
-- 
2.43.0

Re: [PATCH v3 1/2] s390/zcrypt: Fix wrong domain value verification with EP11 CPRBs

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [High] Missing `array_index_nospec()` mitigation leading to a Spectre v1 vulnerability.

Pre-existing issues:
- [Critical] Privilege Escalation / Access Control Bypass in administrative CPRBs.
--

--- Patch [1]: [PATCH v3 1/2] s390/zcrypt: Fix wrong domain value verification with EP11 CPRBs ---
commit 9a314209ce4cb4581d3716a2f6e1c11a24aab46e
Author: Harald Freudenberger <freude@linux.ibm.com>
s390/zcrypt: Fix wrong domain value verification with EP11 CPRBs

This commit fixes an upper limit check for the domain value when an EP11
CPRB is processed for sending to a crypto card. It adjusts the check to use
AP_DOMAINS to prevent heap memory access beyond the permissions array.

> diff --git a/drivers/s390/crypto/zcrypt_api.c b/drivers/s390/crypto/zcrypt_api.c
> index f57189c2b839e..81eefdeae2485 100644
> --- a/drivers/s390/crypto/zcrypt_api.c
> +++ b/drivers/s390/crypto/zcrypt_api.c
> @@ -1077,7 +1077,7 @@ static long _zcrypt_send_ep11_cprb(u32 xflags, struct ap_perms *perms,
>  	print_hex_dump_debug("ep11req: ", DUMP_PREFIX_ADDRESS, 16, 1,
>  			     ap_msg.msg, ap_msg.len, false);
>  
> -	if (perms != &ap_perms && domain < AUTOSEL_DOM) {
> +	if (perms != &ap_perms && domain < AP_DOMAINS) {

[Severity: Critical]
This is a pre-existing issue, but does this logic completely bypass the
administrative permission checks if domain is greater than or equal to
AP_DOMAINS?

If a user provides a domain value like AUTOSEL_DOM (0xFFFF), this condition
evaluates to false, skipping the permission check block entirely. This
appears to allow a user with only usage access to bypass the perms->adm
check.

Since the CCA equivalent _zcrypt_send_cprb() has the same logic, and the
domain can be overwritten later with the dynamically selected queue's domain
before submission:

drivers/s390/crypto/zcrypt_msgtype6.c:zcrypt_msgtype6_send_cprb() {
    ...
    /* update domain field within the CPRB struct */
    msg->cprbx.domain = AP_QID_QUEUE(zq->queue->qid);
    ...
}

Can this lead to regressions by allowing arbitrary administrative commands to
be executed on the queue?

>  		if (ap_msg.flags & AP_MSG_FLAG_ADMIN) {

[Severity: High]
Does this code leave the domain variable vulnerable to speculative execution
attacks?

Since domain is extracted from untrusted user-provided data, the bounds
check could be mispredicted. If the CPU speculatively executes the true
path for an out-of-bounds domain, test_bit_inv() performs a bitwise load
from memory offset by domain.

Would it be appropriate to sanitize the domain variable with
array_index_nospec() before it is used as an index into perms->adm to
prevent potential kernel memory leaks via cache side channels?

>  			if (!test_bit_inv(domain, perms->adm)) {
>  				rc = -ENODEV;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260723095453.127322-1-freude@linux.ibm.com?part=1

Re: [PATCH v3 2/2] s390/zcrypt: Close speculative mem read possibility

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] Authorization bypass for administrative CPRB requests via domain auto-selection.
- [Medium] Incomplete Spectre v1 mitigation for the user-controlled domain value.
--

--- Patch [2]: [PATCH v3 2/2] s390/zcrypt: Close speculative mem read possibility ---
commit 231c807d810ac3d48184d28be474dabc8e020aa9
Author: Harald Freudenberger <freude@linux.ibm.com>

s390/zcrypt: Close speculative mem read possibility

This commit attempts to fix a speculative execution vulnerability in the
s390 zcrypt driver. It adds an array_index_nospec() barrier for the domain
value during administrative CPRB processing to prevent potential
side-channel attacks.

> diff --git a/drivers/s390/crypto/zcrypt_api.c b/drivers/s390/crypto/zcrypt_api.c
> --- a/drivers/s390/crypto/zcrypt_api.c
> +++ b/drivers/s390/crypto/zcrypt_api.c
> @@ -879,12 +879,13 @@ static long _zcrypt_send_cprb(u32 xflags, struct ap_perms *perms,
>  
>  	if (perms != &ap_perms && domain < AP_DOMAINS) {

[Severity: High]
This is a pre-existing issue, but does this check allow an authorization bypass
for administrative requests if the user specifies AUTOSEL_DOM (0xFFFF) as the
domain?

If an administrative CPRB request uses AUTOSEL_DOM, the condition
`domain < AP_DOMAINS` evaluates to false, causing the code to skip the
`test_bit_inv(domain, perms->adm)` administrative permission validation
entirely.

Later in _zcrypt_send_cprb(), the queue selection logic autoselects a queue and
only validates the user's usage permissions via zcrypt_check_queue(). Does this
allow unprivileged users with access to a restricted custom device node to
execute administrative commands on a queue where they only have usage rights?

>  		if (ap_msg.flags & AP_MSG_FLAG_ADMIN) {
> +			domain = array_index_nospec(domain, AP_DOMAINS);
>  			if (!test_bit_inv(domain, perms->adm)) {
>  				rc = -ENODEV;
>  				goto out;
>  			}
>  		} else if ((ap_msg.flags & AP_MSG_FLAG_USAGE) == 0) {
>  			rc = -EOPNOTSUPP;
>  			goto out;
>  		}
>  	}
>  	/*
>  	 * If a valid target domain is set and this domain is NOT a usage
>  	 * domain but a control only domain, autoselect target domain.
>  	 */
>  	if (domain < AP_DOMAINS &&
>  	    !ap_test_config_usage_domain(domain) &&

[Severity: Medium]
This isn't a bug introduced by this patch, but does the un-sanitized domain
value remain vulnerable to speculative out-of-bounds reads here?

The patch adds array_index_nospec() inside the AP_MSG_FLAG_ADMIN check, but
for non-administrative requests, the domain variable is used unmitigated in
ap_test_config_usage_domain() and ap_test_config_ctrl_domain().

Both functions call into ap_test_config(), which uses the domain as an array
index. Since the `domain < AP_DOMAINS` bounds check can be speculatively
bypassed, does this leave a Prime+Probe side-channel attack gadget open for
non-administrative requests?

>  	    ap_test_config_ctrl_domain(domain))
>  		domain = AUTOSEL_DOM;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260723095453.127322-1-freude@linux.ibm.com?part=2