[PATCH v4 0/1] Fix buffer over-read in cca_cipher2protkey

[PATCH v4 0/1] Fix buffer over-read in cca_cipher2protkey

[Harald Freudenberger]

Add validation of both the actual key buffer size and token length
fields in all the cca_check_sec*token() functions. Additionally check
in cca_gencipherkey() for possible underflow with returned key size.

The CCA token structures contain user-controlled len fields that
were used in operations without proper validation against both the
actual buffer size and minimum token structure size. An attacker
could set this field larger than the actual buffer size, leading to
reading beyond buffer boundaries. This may result in a kernel crash or
exposure of memory via sending this as part of a request down to the
crypto card. Also an attacker could have used a very small len value
and thus enforce a buffer under-run which may produce similar effects
as a over-read.

So now a key must
- key buf length must be at least sizeof the token struct
- the key len field inside the token must fit into the range of
  sizeof key token struct ... key buf length

Changelog:
v1 - initial version
v2 - extend the length check to all cca_check_sec*token() functions,
     also check for min given buffer length and token length field.
v3 - there was still a possibility to under-run the length checks in
     function  cca_gencipherkey(). Fixed as suggested by Ingo.
v4 - Reviewd-by from Ingo added.

Harald Freudenberger (1):
  s390/zcrypt: Fix buffer over-read in cca_cipher2protkey

 drivers/s390/crypto/pkey_cca.c       | 15 +++----
 drivers/s390/crypto/zcrypt_ccamisc.c | 64 +++++++++++++++++++++++-----
 drivers/s390/crypto/zcrypt_ccamisc.h |  6 +--
 3 files changed, 62 insertions(+), 23 deletions(-)

-- 
2.43.0

[PATCH v4 1/1] s390/zcrypt: Fix buffer over-read in cca_cipher2protkey

[Harald Freudenberger]

Add validation of both the actual key buffer size and token length
fields in all the cca_check_sec*token() functions. Additionally check
in cca_gencipherkey() for possible underflow with returned key size.

The CCA token structures contain user-controlled len fields that
were used in operations without proper validation against both the
actual buffer size and minimum token structure size. An attacker
could set this field larger than the actual buffer size, leading to
reading beyond buffer boundaries. This may result in a kernel crash or
exposure of memory via sending this as part of a request down to the
crypto card. Also an attacker could have used a very small len value
and thus enforce a buffer under-run which may produce similar effects
as a over-read.

So now a key must
- key buf length must be at least sizeof the token struct
- the key len field inside the token must fit into the range of
  sizeof key token struct ... key buf length

Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Reviewed-by: Ingo Franzki <ifranzki@linux.ibm.com>
Cc: stable@vger.kernel.org
---
 drivers/s390/crypto/pkey_cca.c       | 15 +++----
 drivers/s390/crypto/zcrypt_ccamisc.c | 64 +++++++++++++++++++++++-----
 drivers/s390/crypto/zcrypt_ccamisc.h |  6 +--
 3 files changed, 62 insertions(+), 23 deletions(-)

diff --git a/drivers/s390/crypto/pkey_cca.c b/drivers/s390/crypto/pkey_cca.c
index 4bc47952324e..e8dc2f77c137 100644
--- a/drivers/s390/crypto/pkey_cca.c
+++ b/drivers/s390/crypto/pkey_cca.c
@@ -236,22 +236,16 @@ static int cca_key2protkey(const struct pkey_apqn *apqns, size_t nr_apqns,
 	if (hdr->type == TOKTYPE_CCA_INTERNAL &&
 	    hdr->version == TOKVER_CCA_AES) {
 		/* CCA AES data key */
-		if (keylen < sizeof(struct secaeskeytoken))
-			return -EINVAL;
-		if (cca_check_secaeskeytoken(pkey_dbf_info, 3, key, 0))
+		if (cca_check_secaeskeytoken(pkey_dbf_info, 3, key, keylen, 0))
 			return -EINVAL;
 	} else if (hdr->type == TOKTYPE_CCA_INTERNAL &&
 		   hdr->version == TOKVER_CCA_VLSC) {
 		/* CCA AES cipher key */
-		if (keylen < hdr->len)
-			return -EINVAL;
 		if (cca_check_secaescipherkey(pkey_dbf_info,
-					      3, key, 0, 1))
+					      3, key, keylen, 0, 1))
 			return -EINVAL;
 	} else if (hdr->type == TOKTYPE_CCA_INTERNAL_PKA) {
 		/* CCA ECC (private) key */
-		if (keylen < sizeof(struct eccprivkeytoken))
-			return -EINVAL;
 		if (cca_check_sececckeytoken(pkey_dbf_info, 3, key, keylen, 1))
 			return -EINVAL;
 	} else {
@@ -484,7 +478,7 @@ static int cca_verifykey(const u8 *key, u32 keylen,
 	    hdr->version == TOKVER_CCA_AES) {
 		struct secaeskeytoken *t = (struct secaeskeytoken *)key;
 
-		rc = cca_check_secaeskeytoken(pkey_dbf_info, 3, key, 0);
+		rc = cca_check_secaeskeytoken(pkey_dbf_info, 3, key, keylen, 0);
 		if (rc)
 			goto out;
 		*keytype = PKEY_TYPE_CCA_DATA;
@@ -512,7 +506,8 @@ static int cca_verifykey(const u8 *key, u32 keylen,
 		   hdr->version == TOKVER_CCA_VLSC) {
 		struct cipherkeytoken *t = (struct cipherkeytoken *)key;
 
-		rc = cca_check_secaescipherkey(pkey_dbf_info, 3, key, 0, 1);
+		rc = cca_check_secaescipherkey(pkey_dbf_info, 3,
+					       key, keylen, 0, 1);
 		if (rc)
 			goto out;
 		*keytype = PKEY_TYPE_CCA_CIPHER;
diff --git a/drivers/s390/crypto/zcrypt_ccamisc.c b/drivers/s390/crypto/zcrypt_ccamisc.c
index 322677a8d320..f797786107b9 100644
--- a/drivers/s390/crypto/zcrypt_ccamisc.c
+++ b/drivers/s390/crypto/zcrypt_ccamisc.c
@@ -62,12 +62,18 @@ static DEFINE_MUTEX(dev_status_mem_mutex);
  * also checked. Returns 0 on success or errno value on failure.
  */
 int cca_check_secaeskeytoken(debug_info_t *dbg, int dbflvl,
-			     const u8 *token, int keybitsize)
+			     const u8 *token, u32 keysize, int keybitsize)
 {
 	struct secaeskeytoken *t = (struct secaeskeytoken *)token;
 
 #define DBF(...) debug_sprintf_event(dbg, dbflvl, ##__VA_ARGS__)
 
+	if (keysize < sizeof(*t)) {
+		if (dbg)
+			DBF("%s keysize %u < min token size %zu\n",
+			    __func__, keysize, sizeof(*t));
+		return -EINVAL;
+	}
 	if (t->type != TOKTYPE_CCA_INTERNAL) {
 		if (dbg)
 			DBF("%s token check failed, type 0x%02x != 0x%02x\n",
@@ -101,14 +107,20 @@ EXPORT_SYMBOL(cca_check_secaeskeytoken);
  * Returns 0 on success or errno value on failure.
  */
 int cca_check_secaescipherkey(debug_info_t *dbg, int dbflvl,
-			      const u8 *token, int keybitsize,
-			      int checkcpacfexport)
+			      const u8 *token, u32 keysize,
+			      int keybitsize, int checkcpacfexport)
 {
 	struct cipherkeytoken *t = (struct cipherkeytoken *)token;
 	bool keybitsizeok = true;
 
 #define DBF(...) debug_sprintf_event(dbg, dbflvl, ##__VA_ARGS__)
 
+	if (keysize < sizeof(*t)) {
+		if (dbg)
+			DBF("%s keysize %u < min token size %zu\n",
+			    __func__, keysize, sizeof(*t));
+		return -EINVAL;
+	}
 	if (t->type != TOKTYPE_CCA_INTERNAL) {
 		if (dbg)
 			DBF("%s token check failed, type 0x%02x != 0x%02x\n",
@@ -121,6 +133,18 @@ int cca_check_secaescipherkey(debug_info_t *dbg, int dbflvl,
 			    __func__, (int)t->version, TOKVER_CCA_VLSC);
 		return -EINVAL;
 	}
+	if (t->len > keysize) {
+		if (dbg)
+			DBF("%s token check failed, len %d > keysize %u\n",
+			    __func__, (int)t->len, keysize);
+		return -EINVAL;
+	}
+	if (t->len < sizeof(*t)) {
+		if (dbg)
+			DBF("%s token check failed, len %d < min token size %zu\n",
+			    __func__, (int)t->len, sizeof(*t));
+		return -EINVAL;
+	}
 	if (t->algtype != 0x02) {
 		if (dbg)
 			DBF("%s token check failed, algtype 0x%02x != 0x02\n",
@@ -195,6 +219,12 @@ int cca_check_sececckeytoken(debug_info_t *dbg, int dbflvl,
 
 #define DBF(...) debug_sprintf_event(dbg, dbflvl, ##__VA_ARGS__)
 
+	if (keysize < sizeof(*t)) {
+		if (dbg)
+			DBF("%s keysize %u < min token size %zu\n",
+			    __func__, keysize, sizeof(*t));
+		return -EINVAL;
+	}
 	if (t->type != TOKTYPE_CCA_INTERNAL_PKA) {
 		if (dbg)
 			DBF("%s token check failed, type 0x%02x != 0x%02x\n",
@@ -207,6 +237,12 @@ int cca_check_sececckeytoken(debug_info_t *dbg, int dbflvl,
 			    __func__, (int)t->len, keysize);
 		return -EINVAL;
 	}
+	if (t->len < sizeof(*t)) {
+		if (dbg)
+			DBF("%s token check failed, len %d < min token size %zu\n",
+			    __func__, (int)t->len, sizeof(*t));
+		return -EINVAL;
+	}
 	if (t->secid != 0x20) {
 		if (dbg)
 			DBF("%s token check failed, secid 0x%02x != 0x20\n",
@@ -443,7 +479,8 @@ int cca_genseckey(u16 cardnr, u16 domain,
 
 	/* check secure key token */
 	rc = cca_check_secaeskeytoken(zcrypt_dbf_info, DBF_ERR,
-				      prepparm->lv3.keyblock.tok, 8 * keysize);
+				      prepparm->lv3.keyblock.tok,
+				      seckeysize, 8 * keysize);
 	if (rc) {
 		rc = -EIO;
 		goto out;
@@ -582,7 +619,8 @@ int cca_clr2seckey(u16 cardnr, u16 domain, u32 keybitsize,
 
 	/* check secure key token */
 	rc = cca_check_secaeskeytoken(zcrypt_dbf_info, DBF_ERR,
-				      prepparm->lv3.keyblock.tok, 8 * keysize);
+				      prepparm->lv3.keyblock.tok,
+				      seckeysize, 8 * keysize);
 	if (rc) {
 		rc = -EIO;
 		goto out;
@@ -842,6 +880,7 @@ int cca_gencipherkey(u16 cardnr, u16 domain, u32 keybitsize, u32 keygenflags,
 		} kb;
 	} __packed * prepparm;
 	struct cipherkeytoken *t;
+	u32 keybuflen;
 
 	/* get already prepared memory for 2 cprbs with param block each */
 	rc = alloc_and_prep_cprbmem(PARMBSIZE, &mem,
@@ -936,23 +975,28 @@ int cca_gencipherkey(u16 cardnr, u16 domain, u32 keybitsize, u32 keygenflags,
 	}
 
 	/* and some checks on the generated key */
+	t = (struct cipherkeytoken *)prepparm->kb.tlv1.gen_key;
+	if (prepparm->kb.tlv1.len < 2 * sizeof(uint16_t) + sizeof(*t)) {
+		rc = -EIO;
+		goto out;
+	}
+	keybuflen = prepparm->kb.tlv1.len - 2 * sizeof(uint16_t);
 	rc = cca_check_secaescipherkey(zcrypt_dbf_info, DBF_ERR,
 				       prepparm->kb.tlv1.gen_key,
-				       keybitsize, 1);
+				       keybuflen, keybitsize, 1);
 	if (rc) {
 		rc = -EIO;
 		goto out;
 	}
 
 	/* copy the generated vlsc key token */
-	t = (struct cipherkeytoken *)prepparm->kb.tlv1.gen_key;
 	if (keybuf) {
-		if (*keybufsize >= t->len)
-			memcpy(keybuf, t, t->len);
+		if (*keybufsize >= keybuflen)
+			memcpy(keybuf, t, keybuflen);
 		else
 			rc = -EINVAL;
 	}
-	*keybufsize = t->len;
+	*keybufsize = keybuflen;
 
 out:
 	free_cprbmem(mem, PARMBSIZE, false, xflags);
diff --git a/drivers/s390/crypto/zcrypt_ccamisc.h b/drivers/s390/crypto/zcrypt_ccamisc.h
index 07bbb1c20022..a4534f8b2f1d 100644
--- a/drivers/s390/crypto/zcrypt_ccamisc.h
+++ b/drivers/s390/crypto/zcrypt_ccamisc.h
@@ -136,7 +136,7 @@ struct eccprivkeytoken {
  * also checked. Returns 0 on success or errno value on failure.
  */
 int cca_check_secaeskeytoken(debug_info_t *dbg, int dbflvl,
-			     const u8 *token, int keybitsize);
+			     const u8 *token, u32 keysize, int keybitsize);
 
 /*
  * Simple check if the token is a valid CCA secure AES cipher key
@@ -146,8 +146,8 @@ int cca_check_secaeskeytoken(debug_info_t *dbg, int dbflvl,
  * Returns 0 on success or errno value on failure.
  */
 int cca_check_secaescipherkey(debug_info_t *dbg, int dbflvl,
-			      const u8 *token, int keybitsize,
-			      int checkcpacfexport);
+			      const u8 *token, u32 keysize,
+			      int keybitsize, int checkcpacfexport);
 
 /*
  * Simple check if the token is a valid CCA secure ECC private
-- 
2.43.0

Re: [PATCH v4 1/1] s390/zcrypt: Fix buffer over-read in cca_cipher2protkey

[sashiko-bot]

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

Pre-existing issues:
- [Critical] Unbounded token length allows heap buffer overflow in `cca_cipher2protkey` and `cca_ecc2protkey` when building CPRB requests.
- [High] Unvalidated firmware-provided length in `cca_gencipherkey` can lead to a massive out-of-bounds read and memory leak to user-space.
- [High] Unbounded `t->len` in `_ip_cprb_helper` can cause a heap buffer overflow when copying a response from the crypto card.
--

--- Patch [1]: [PATCH v4 1/1] s390/zcrypt: Fix buffer over-read in cca_cipher2protkey ---
commit df110319f8dcc4a61962c0699f5ad1038f1b9085
Author: Harald Freudenberger <freude@linux.ibm.com>

s390/zcrypt: Fix buffer over-read in cca_cipher2protkey

This commit adds validation of the actual key buffer size and token length
fields in the cca_check_sec*token functions. It prevents buffer over-reads
and under-runs that could lead to kernel crashes or memory exposure.

> diff --git a/drivers/s390/crypto/zcrypt_ccamisc.c b/drivers/s390/crypto/zcrypt_ccamisc.c
> --- a/drivers/s390/crypto/zcrypt_ccamisc.c
> +++ b/drivers/s390/crypto/zcrypt_ccamisc.c
[ ... ]
> @@ -936,23 +975,28 @@ int cca_gencipherkey(u16 cardnr, u16 domain, u32 keybitsize, u32 keygenflags,
>  	}
>  
>  	/* and some checks on the generated key */
> +	t = (struct cipherkeytoken *)prepparm->kb.tlv1.gen_key;
> +	if (prepparm->kb.tlv1.len < 2 * sizeof(uint16_t) + sizeof(*t)) {
> +		rc = -EIO;
> +		goto out;
> +	}
> +	keybuflen = prepparm->kb.tlv1.len - 2 * sizeof(uint16_t);
>  	rc = cca_check_secaescipherkey(zcrypt_dbf_info, DBF_ERR,
>  				       prepparm->kb.tlv1.gen_key,
> -				       keybitsize, 1);
> +				       keybuflen, keybitsize, 1);
>  	if (rc) {
>  		rc = -EIO;
>  		goto out;
>  	}
>  
>  	/* copy the generated vlsc key token */
> -	t = (struct cipherkeytoken *)prepparm->kb.tlv1.gen_key;
>  	if (keybuf) {
> -		if (*keybufsize >= t->len)
> -			memcpy(keybuf, t, t->len);
> +		if (*keybufsize >= keybuflen)
> +			memcpy(keybuf, t, keybuflen);

[Severity: High]
This isn't a bug introduced by this patch, but can an unvalidated firmware
response lead to an out-of-bounds read here?

The hardware returns a response containing a tlv1.len field which is
used to calculate keybuflen. If a compromised or buggy crypto card firmware
sets an abnormally large tlv1.len, does this memcpy read past the 512-byte
parameter block into adjacent kernel heap memory and leak it to userspace?

Could we add a bounds check against the 512-byte allocation limit before
performing the memcpy?

>  		else
>  			rc = -EINVAL;
>  	}
> -	*keybufsize = t->len;
> +	*keybufsize = keybuflen;
>  
>  out:

[Severity: Critical]
This is a pre-existing issue, but I noticed a potential regression involving
buffer overflows in cca_cipher2protkey and cca_ecc2protkey when building
request blocks.

In cca_cipher2protkey, if a user issues an ioctl providing a malicious token
with a large len field, does this overwrite the 512-byte buffer?

drivers/s390/crypto/zcrypt_ccamisc.c:cca_cipher2protkey() {
    ...
    preqparm->kb.len = keytoklen + 3 * sizeof(uint16_t);
    preqparm->kb.cca_key_token_len = keytoklen + 2 * sizeof(uint16_t);
    memcpy(preqparm->kb.cca_key_token, ckey, keytoklen);
    ...
}

The cca_check_secaescipherkey function ensures t->len is less than or equal
to keysize, where keysize is the user-provided size that can be up to
8192 bytes. If keytoklen is larger than the 512-byte limit, could this memcpy
overwrite the allocation?

A similar pattern exists in cca_ecc2protkey:

drivers/s390/crypto/zcrypt_ccamisc.c:cca_ecc2protkey() {
    ...
    preqparm->kb.len = keylen + 3 * sizeof(uint16_t);
    preqparm->kb.cca_key_token_len = keylen + 2 * sizeof(uint16_t);
    memcpy(preqparm->kb.cca_key_token, key, keylen);
    ...
}

[Severity: High]
This is also a pre-existing issue, but I observed a similar unbounded length
usage in _ip_cprb_helper that might cause an out-of-bounds read and write.

When copying a response from the crypto card, the t->len field is trusted
directly from the hardware:

drivers/s390/crypto/zcrypt_ccamisc.c:_ip_cprb_helper() {
    ...
    t = (struct cipherkeytoken *)prepparm->kb.tlv1.key_token;
    memcpy(key_token, t, t->len);
    *key_token_size = t->len;
    ...
}

If the hardware provides a malformed response with a large t->len, does this
memcpy read out-of-bounds from the 512-byte parameter block?

Additionally, if this corrupted length is returned to cca_clr2cipherkey,
could it be used to write back into a new 512-byte request block and cause
another overflow?

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

Re: [PATCH v4 1/1] s390/zcrypt: Fix buffer over-read in cca_cipher2protkey

[Harald Freudenberger]

On 2026-07-29 14:06, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 3 potential
> issue(s) to consider:
> 
> Pre-existing issues:
> - [Critical] Unbounded token length allows heap buffer overflow in
> `cca_cipher2protkey` and `cca_ecc2protkey` when building CPRB
> requests.
> - [High] Unvalidated firmware-provided length in `cca_gencipherkey`
> can lead to a massive out-of-bounds read and memory leak to
> user-space.
> - [High] Unbounded `t->len` in `_ip_cprb_helper` can cause a heap
> buffer overflow when copying a response from the crypto card.
> --
> 
> --- Patch [1]: [PATCH v4 1/1] s390/zcrypt: Fix buffer over-read in
> cca_cipher2protkey ---
> commit df110319f8dcc4a61962c0699f5ad1038f1b9085
> Author: Harald Freudenberger <freude@linux.ibm.com>
> 
> s390/zcrypt: Fix buffer over-read in cca_cipher2protkey
> 
> This commit adds validation of the actual key buffer size and token 
> length
> fields in the cca_check_sec*token functions. It prevents buffer 
> over-reads
> and under-runs that could lead to kernel crashes or memory exposure.
> 
>> diff --git a/drivers/s390/crypto/zcrypt_ccamisc.c 
>> b/drivers/s390/crypto/zcrypt_ccamisc.c
>> --- a/drivers/s390/crypto/zcrypt_ccamisc.c
>> +++ b/drivers/s390/crypto/zcrypt_ccamisc.c
> [ ... ]
>> @@ -936,23 +975,28 @@ int cca_gencipherkey(u16 cardnr, u16 domain, u32 
>> keybitsize, u32 keygenflags,
>>  	}
>> 
>>  	/* and some checks on the generated key */
>> +	t = (struct cipherkeytoken *)prepparm->kb.tlv1.gen_key;
>> +	if (prepparm->kb.tlv1.len < 2 * sizeof(uint16_t) + sizeof(*t)) {
>> +		rc = -EIO;
>> +		goto out;
>> +	}
>> +	keybuflen = prepparm->kb.tlv1.len - 2 * sizeof(uint16_t);
>>  	rc = cca_check_secaescipherkey(zcrypt_dbf_info, DBF_ERR,
>>  				       prepparm->kb.tlv1.gen_key,
>> -				       keybitsize, 1);
>> +				       keybuflen, keybitsize, 1);
>>  	if (rc) {
>>  		rc = -EIO;
>>  		goto out;
>>  	}
>> 
>>  	/* copy the generated vlsc key token */
>> -	t = (struct cipherkeytoken *)prepparm->kb.tlv1.gen_key;
>>  	if (keybuf) {
>> -		if (*keybufsize >= t->len)
>> -			memcpy(keybuf, t, t->len);
>> +		if (*keybufsize >= keybuflen)
>> +			memcpy(keybuf, t, keybuflen);
> 
> [Severity: High]
> This isn't a bug introduced by this patch, but can an unvalidated 
> firmware
> response lead to an out-of-bounds read here?
> 
> The hardware returns a response containing a tlv1.len field which is
> used to calculate keybuflen. If a compromised or buggy crypto card 
> firmware
> sets an abnormally large tlv1.len, does this memcpy read past the 
> 512-byte
> parameter block into adjacent kernel heap memory and leak it to 
> userspace?
> 
> Could we add a bounds check against the 512-byte allocation limit 
> before
> performing the memcpy?
> 
>>  		else
>>  			rc = -EINVAL;
>>  	}
>> -	*keybufsize = t->len;
>> +	*keybufsize = keybuflen;
>> 
>>  out:
> 
> [Severity: Critical]
> This is a pre-existing issue, but I noticed a potential regression 
> involving
> buffer overflows in cca_cipher2protkey and cca_ecc2protkey when 
> building
> request blocks.
> 
> In cca_cipher2protkey, if a user issues an ioctl providing a malicious 
> token
> with a large len field, does this overwrite the 512-byte buffer?
> 
> drivers/s390/crypto/zcrypt_ccamisc.c:cca_cipher2protkey() {
>     ...
>     preqparm->kb.len = keytoklen + 3 * sizeof(uint16_t);
>     preqparm->kb.cca_key_token_len = keytoklen + 2 * sizeof(uint16_t);
>     memcpy(preqparm->kb.cca_key_token, ckey, keytoklen);
>     ...
> }
> 
> The cca_check_secaescipherkey function ensures t->len is less than or 
> equal
> to keysize, where keysize is the user-provided size that can be up to
> 8192 bytes. If keytoklen is larger than the 512-byte limit, could this 
> memcpy
> overwrite the allocation?
> 
> A similar pattern exists in cca_ecc2protkey:
> 
> drivers/s390/crypto/zcrypt_ccamisc.c:cca_ecc2protkey() {
>     ...
>     preqparm->kb.len = keylen + 3 * sizeof(uint16_t);
>     preqparm->kb.cca_key_token_len = keylen + 2 * sizeof(uint16_t);
>     memcpy(preqparm->kb.cca_key_token, key, keylen);
>     ...
> }
> 
> [Severity: High]
> This is also a pre-existing issue, but I observed a similar unbounded 
> length
> usage in _ip_cprb_helper that might cause an out-of-bounds read and 
> write.
> 
> When copying a response from the crypto card, the t->len field is 
> trusted
> directly from the hardware:
> 
> drivers/s390/crypto/zcrypt_ccamisc.c:_ip_cprb_helper() {
>     ...
>     t = (struct cipherkeytoken *)prepparm->kb.tlv1.key_token;
>     memcpy(key_token, t, t->len);
>     *key_token_size = t->len;
>     ...
> }
> 
> If the hardware provides a malformed response with a large t->len, does 
> this
> memcpy read out-of-bounds from the 512-byte parameter block?
> 
> Additionally, if this corrupted length is returned to 
> cca_clr2cipherkey,
> could it be used to write back into a new 512-byte request block and 
> cause
> another overflow?

These issues are valid but are already addressed with another patch 
series.