[PATCH v2 0/1] Fix missing mem scrub at clear key import in cca_clr2cipherkey()

[PATCH v2 0/1] Fix missing mem scrub at clear key import in cca_clr2cipherkey()

[Harald Freudenberger]

The helper function _ip_cprb_helper() uses internal buffer memory for
building and processing CPRBs. After use this buffer was never
scrubbed which could lead to leaving for example clear key material in
memory which could be exposed via tricky reuse of this same memory.

Extent the _ip_cprb_helper() function with another parameter 'scrub'
used to steer scrubbing of this buffer. So now the caller has the
opportunity to decide if scrubbing is needed or not.

Extent the clear key to secure key token import process in function
cca_clr2cipherkey() to tell the helper function from above to scrub
the cprb buffer when the clear key value is part of the request data.

Add explicit scrubbing on return from function cca_clr2cipherkey() for
the random EXOR buffer and the cprb buffer.

Overall this cleans the internal used buffer in case of clear key
import to prevent sensitive data to get exposed.

Changelog:
v1: initial version
v2: added explicit scrubbing on return of cca_clr2cipherkey()

Harald Freudenberger (1):
  s390/zcrypt: Fix missing mem scrub at clear key import in
    cca_clr2cipherkey()

 drivers/s390/crypto/zcrypt_ccamisc.c | 19 +++++++++++++------
 1 file changed, 13 insertions(+), 6 deletions(-)

-- 
2.43.0

[PATCH v2 1/1] s390/zcrypt: Fix missing mem scrub at clear key import in cca_clr2cipherkey()

[Harald Freudenberger]

The helper function _ip_cprb_helper() uses internal buffer memory for
building and processing CPRBs. After use this buffer was never
scrubbed which could lead to leaving for example clear key material in
memory which could be exposed via tricky reuse of this same memory.

Extent the _ip_cprb_helper() function with another parameter 'scrub'
used to steer scrubbing of this buffer. So now the caller has the
opportunity to decide if scrubbing is needed or not.

Extent the clear key to secure key token import process in function
cca_clr2cipherkey() to tell the helper function from above to scrub
the cprb buffer when the clear key value is part of the request data.

Add explicit scrubbing on return from function cca_clr2cipherkey() for
the random EXOR buffer and the cprb buffer.

Overall this cleans the internal used buffer in case of clear key
import to prevent sensitive data to get exposed.

Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Cc: stable@vger.kernel.org
---
 drivers/s390/crypto/zcrypt_ccamisc.c | 19 +++++++++++++------
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/drivers/s390/crypto/zcrypt_ccamisc.c b/drivers/s390/crypto/zcrypt_ccamisc.c
index 84936a795b95..9cf268efd4ab 100644
--- a/drivers/s390/crypto/zcrypt_ccamisc.c
+++ b/drivers/s390/crypto/zcrypt_ccamisc.c
@@ -971,7 +971,8 @@ static int _ip_cprb_helper(u16 cardnr, u16 domain,
 			   int clr_key_bit_size,
 			   u8 *key_token,
 			   int *key_token_size,
-			   u32 xflags)
+			   u32 xflags,
+			   bool scrub)
 {
 	int rc, n;
 	u8 *mem, *ptr;
@@ -1111,7 +1112,7 @@ static int _ip_cprb_helper(u16 cardnr, u16 domain,
 	*key_token_size = t->len;
 
 out:
-	free_cprbmem(mem, PARMBSIZE, false, xflags);
+	free_cprbmem(mem, PARMBSIZE, scrub, xflags);
 	return rc;
 }
 
@@ -1162,28 +1163,32 @@ int cca_clr2cipherkey(u16 card, u16 dom, u32 keybitsize, u32 keygenflags,
 	 * 4/4 COMPLETE the secure cipher key import
 	 */
 	rc = _ip_cprb_helper(card, dom, "AES     ", "FIRST   ", "MIN3PART",
-			     exorbuf, keybitsize, token, &tokensize, xflags);
+			     exorbuf, keybitsize, token, &tokensize,
+			     xflags, true);
 	if (rc) {
 		ZCRYPT_DBF_ERR("%s clear key import 1/4 with CSNBKPI2 failed, rc=%d\n",
 			       __func__, rc);
 		goto out;
 	}
 	rc = _ip_cprb_helper(card, dom, "AES     ", "ADD-PART", NULL,
-			     clrkey, keybitsize, token, &tokensize, xflags);
+			     clrkey, keybitsize, token, &tokensize,
+			     xflags, true);
 	if (rc) {
 		ZCRYPT_DBF_ERR("%s clear key import 2/4 with CSNBKPI2 failed, rc=%d\n",
 			       __func__, rc);
 		goto out;
 	}
 	rc = _ip_cprb_helper(card, dom, "AES     ", "ADD-PART", NULL,
-			     exorbuf, keybitsize, token, &tokensize, xflags);
+			     exorbuf, keybitsize, token, &tokensize,
+			     xflags, true);
 	if (rc) {
 		ZCRYPT_DBF_ERR("%s clear key import 3/4 with CSNBKPI2 failed, rc=%d\n",
 			       __func__, rc);
 		goto out;
 	}
 	rc = _ip_cprb_helper(card, dom, "AES     ", "COMPLETE", NULL,
-			     NULL, keybitsize, token, &tokensize, xflags);
+			     NULL, keybitsize, token, &tokensize,
+			     xflags, true);
 	if (rc) {
 		ZCRYPT_DBF_ERR("%s clear key import 4/4 with CSNBKPI2 failed, rc=%d\n",
 			       __func__, rc);
@@ -1200,6 +1205,8 @@ int cca_clr2cipherkey(u16 card, u16 dom, u32 keybitsize, u32 keygenflags,
 	*keybufsize = tokensize;
 
 out:
+	memzero_explicit(exorbuf, sizeof(exorbuf));
+	memzero_explicit(mem, CPRB_MEMPOOL_ITEM_SIZE);
 	mempool_free(mem, cprb_mempool);
 	return rc;
 }
-- 
2.43.0

Re: [PATCH v2 1/1] s390/zcrypt: Fix missing mem scrub at clear key import in cca_clr2cipherkey()

[sashiko-bot]

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

Pre-existing issues:
- [High] Unvalidated length field `t->len` from an untrusted hardware response leads to severe out-of-bounds memory accesses during `memcpy()`.
--

--- Patch [1]: [PATCH v2 1/1] s390/zcrypt: Fix missing mem scrub at clear key import in cca_clr2cipherkey() ---
commit 0678dd664c1b50d9a38dff946d27b4823de1e205
Author: Harald Freudenberger <freude@linux.ibm.com>

s390/zcrypt: Fix missing mem scrub at clear key import in cca_clr2cipherkey()

This commit adds a parameter to _ip_cprb_helper() to scrub the CPRB buffer 
after processing clear key material. It also adds explicit zeroing of the 
buffers before freeing them in cca_clr2cipherkey() to prevent sensitive 
data exposure.

> diff --git a/drivers/s390/crypto/zcrypt_ccamisc.c b/drivers/s390/crypto/zcrypt_ccamisc.c
> index 84936a795b956..9cf268efd4abf 100644
> --- a/drivers/s390/crypto/zcrypt_ccamisc.c
> +++ b/drivers/s390/crypto/zcrypt_ccamisc.c
[ ... ]
> @@ -1111,7 +1112,7 @@ static int _ip_cprb_helper(u16 cardnr, u16 domain,
>  	*key_token_size = t->len;

[Severity: High]
This is a pre-existing issue, but is it possible for a compromised or
malfunctioning hardware device to return a maliciously crafted response
length in t->len?

In _ip_cprb_helper(), the unvalidated t->len from the hardware response is
directly used as the length for copying just before this line:

	t = (struct cipherkeytoken *)prepparm->kb.tlv1.key_token;
	memcpy(key_token, t, t->len);
	*key_token_size = t->len;

Without bounds checking against the actual buffer size, could this lead to an
out-of-bounds read from the device response buffer and an out-of-bounds write
into the key_token buffer?

Also, on subsequent iterations in cca_clr2cipherkey(), the poisoned
*key_token_size is used to construct the next request:

	preq_key_block->tlv1.len = sizeof(preq_key_block->tlv1) + n;
	preq_key_block->tlv1.flag = 0x0030;
	memcpy(preq_key_block->tlv1.key_token, key_token, *key_token_size);

Does this cause another unbounded copy into the smaller parameter buffer during
the next loop iteration?

>  
>  out:
> -	free_cprbmem(mem, PARMBSIZE, false, xflags);
> +	free_cprbmem(mem, PARMBSIZE, scrub, xflags);
>  	return rc;
>  }

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

Re: [PATCH v2 1/1] s390/zcrypt: Fix missing mem scrub at clear key import in cca_clr2cipherkey()

[Harald Freudenberger]

On 2026-07-29 16:12, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential
> issue(s) to consider:
> 
> Pre-existing issues:
> - [High] Unvalidated length field `t->len` from an untrusted hardware
> response leads to severe out-of-bounds memory accesses during
> `memcpy()`.
> --
> 
> --- Patch [1]: [PATCH v2 1/1] s390/zcrypt: Fix missing mem scrub at
> clear key import in cca_clr2cipherkey() ---
> commit 0678dd664c1b50d9a38dff946d27b4823de1e205
> Author: Harald Freudenberger <freude@linux.ibm.com>
> 
> s390/zcrypt: Fix missing mem scrub at clear key import in 
> cca_clr2cipherkey()
> 
> This commit adds a parameter to _ip_cprb_helper() to scrub the CPRB 
> buffer
> after processing clear key material. It also adds explicit zeroing of 
> the
> buffers before freeing them in cca_clr2cipherkey() to prevent sensitive
> data exposure.
> 
>> diff --git a/drivers/s390/crypto/zcrypt_ccamisc.c 
>> b/drivers/s390/crypto/zcrypt_ccamisc.c
>> index 84936a795b956..9cf268efd4abf 100644
>> --- a/drivers/s390/crypto/zcrypt_ccamisc.c
>> +++ b/drivers/s390/crypto/zcrypt_ccamisc.c
> [ ... ]
>> @@ -1111,7 +1112,7 @@ static int _ip_cprb_helper(u16 cardnr, u16 
>> domain,
>>  	*key_token_size = t->len;
> 
> [Severity: High]
> This is a pre-existing issue, but is it possible for a compromised or
> malfunctioning hardware device to return a maliciously crafted response
> length in t->len?
> 
> In _ip_cprb_helper(), the unvalidated t->len from the hardware response 
> is
> directly used as the length for copying just before this line:
> 
> 	t = (struct cipherkeytoken *)prepparm->kb.tlv1.key_token;
> 	memcpy(key_token, t, t->len);
> 	*key_token_size = t->len;
> 
> Without bounds checking against the actual buffer size, could this lead 
> to an
> out-of-bounds read from the device response buffer and an out-of-bounds 
> write
> into the key_token buffer?
> 
> Also, on subsequent iterations in cca_clr2cipherkey(), the poisoned
> *key_token_size is used to construct the next request:
> 
> 	preq_key_block->tlv1.len = sizeof(preq_key_block->tlv1) + n;
> 	preq_key_block->tlv1.flag = 0x0030;
> 	memcpy(preq_key_block->tlv1.key_token, key_token, *key_token_size);
> 
> Does this cause another unbounded copy into the smaller parameter 
> buffer during
> the next loop iteration?
> 
>> 
>>  out:
>> -	free_cprbmem(mem, PARMBSIZE, false, xflags);
>> +	free_cprbmem(mem, PARMBSIZE, scrub, xflags);
>>  	return rc;
>>  }

This is a valid finding but will be addressed with another patch series.

Re: [PATCH v2 1/1] s390/zcrypt: Fix missing mem scrub at clear key import in cca_clr2cipherkey()

[Harald Freudenberger]

On 2026-07-29 16:12, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential
> issue(s) to consider:
> 
> Pre-existing issues:
> - [High] Unvalidated length field `t->len` from an untrusted hardware
> response leads to severe out-of-bounds memory accesses during
> `memcpy()`.
> --
> 
> --- Patch [1]: [PATCH v2 1/1] s390/zcrypt: Fix missing mem scrub at
> clear key import in cca_clr2cipherkey() ---
> commit 0678dd664c1b50d9a38dff946d27b4823de1e205
> Author: Harald Freudenberger <freude@linux.ibm.com>
> 
> s390/zcrypt: Fix missing mem scrub at clear key import in 
> cca_clr2cipherkey()
> 
> This commit adds a parameter to _ip_cprb_helper() to scrub the CPRB 
> buffer
> after processing clear key material. It also adds explicit zeroing of 
> the
> buffers before freeing them in cca_clr2cipherkey() to prevent sensitive
> data exposure.
> 
>> diff --git a/drivers/s390/crypto/zcrypt_ccamisc.c 
>> b/drivers/s390/crypto/zcrypt_ccamisc.c
>> index 84936a795b956..9cf268efd4abf 100644
>> --- a/drivers/s390/crypto/zcrypt_ccamisc.c
>> +++ b/drivers/s390/crypto/zcrypt_ccamisc.c
> [ ... ]
>> @@ -1111,7 +1112,7 @@ static int _ip_cprb_helper(u16 cardnr, u16 
>> domain,
>>  	*key_token_size = t->len;
> 
> [Severity: High]
> This is a pre-existing issue, but is it possible for a compromised or
> malfunctioning hardware device to return a maliciously crafted response
> length in t->len?
> 
> In _ip_cprb_helper(), the unvalidated t->len from the hardware response 
> is
> directly used as the length for copying just before this line:
> 
> 	t = (struct cipherkeytoken *)prepparm->kb.tlv1.key_token;
> 	memcpy(key_token, t, t->len);
> 	*key_token_size = t->len;
> 
> Without bounds checking against the actual buffer size, could this lead 
> to an
> out-of-bounds read from the device response buffer and an out-of-bounds 
> write
> into the key_token buffer?
> 
> Also, on subsequent iterations in cca_clr2cipherkey(), the poisoned
> *key_token_size is used to construct the next request:
> 
> 	preq_key_block->tlv1.len = sizeof(preq_key_block->tlv1) + n;
> 	preq_key_block->tlv1.flag = 0x0030;
> 	memcpy(preq_key_block->tlv1.key_token, key_token, *key_token_size);
> 
> Does this cause another unbounded copy into the smaller parameter 
> buffer during
> the next loop iteration?
> 
>> 
>>  out:
>> -	free_cprbmem(mem, PARMBSIZE, false, xflags);
>> +	free_cprbmem(mem, PARMBSIZE, scrub, xflags);
>>  	return rc;
>>  }

These issues will be addressed with another patch (series)

Re: [PATCH v2 1/1] s390/zcrypt: Fix missing mem scrub at clear key import in cca_clr2cipherkey()

[Holger Dengler]

On 7/29/26 16:01, Harald Freudenberger wrote:
> The helper function _ip_cprb_helper() uses internal buffer memory for
> building and processing CPRBs. After use this buffer was never
> scrubbed which could lead to leaving for example clear key material in
> memory which could be exposed via tricky reuse of this same memory.
> 
> Extent the _ip_cprb_helper() function with another parameter 'scrub'

typo: Extend

> used to steer scrubbing of this buffer. So now the caller has the
> opportunity to decide if scrubbing is needed or not.
> 
> Extent the clear key to secure key token import process in function

typo: Extend

> cca_clr2cipherkey() to tell the helper function from above to scrub
> the cprb buffer when the clear key value is part of the request data.
> 
> Add explicit scrubbing on return from function cca_clr2cipherkey() for
> the random EXOR buffer and the cprb buffer.
> 
> Overall this cleans the internal used buffer in case of clear key
> import to prevent sensitive data to get exposed.
> 
> Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
> Cc: stable@vger.kernel.org

Reviewed-by: Holger Dengler <dengler@linux.ibm.com>

-- 
Mit freundlichen Grüßen / Kind regards
Holger Dengler