[PATCH v1 0/2] s390/zcrypt: Validate length in CCA key requests

[PATCH v1 0/2] s390/zcrypt: Validate length in CCA key requests

[Holger Dengler]

The series contains two missing length field validations for requests
with CCA AES cipher keys and CCA ECC private keys. In both cases, the
length information is used to copy the payload to the request block
without checking the available space. Malformed requests can so cause
out-of-band writes on the heap.

This series applies on top of Linus' master branch.

Holger Dengler (2):
  s390/zcrypt: Validate length for CCA AES cipher key requests
  s390/zcrypt: Validate length for CCA ECC private key requests

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


base-commit: fc02acf6ac0ccde0c805c2daa9148683cdd01ba8
-- 
2.55.0

[PATCH v1 1/2] s390/zcrypt: Validate length for CCA AES cipher key requests

[Holger Dengler]

cca_cipher2protkey() derives the copy length for the CPRB parameter
block directly from the length field in the key token. Reject the
request early if the token length exceeds the available space in the
parameter block.

Fixes: 4bc123b18ce6 ("s390/zcrypt: Add low level functions for CCA AES cipher keys")
Signed-off-by: Holger Dengler <dengler@linux.ibm.com>
Cc: stable@vger.kernel.org # 5.4+
---
 drivers/s390/crypto/zcrypt_ccamisc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/s390/crypto/zcrypt_ccamisc.c b/drivers/s390/crypto/zcrypt_ccamisc.c
index 84936a795b95..db6a4211a97e 100644
--- a/drivers/s390/crypto/zcrypt_ccamisc.c
+++ b/drivers/s390/crypto/zcrypt_ccamisc.c
@@ -1261,6 +1261,9 @@ int cca_cipher2protkey(u16 cardnr, u16 domain, const u8 *ckey,
 	} __packed * prepparm;
 	int keytoklen = ((struct cipherkeytoken *)ckey)->len;
 
+	if (keytoklen > PARMBSIZE - sizeof(struct aureqparm))
+		return -EINVAL;
+
 	/* get already prepared memory for 2 cprbs with param block each */
 	rc = alloc_and_prep_cprbmem(PARMBSIZE, &mem,
 				    &preqcblk, &prepcblk, xflags);
-- 
2.55.0

Re: [PATCH v1 1/2] s390/zcrypt: Validate length for CCA AES cipher key requests

[sashiko-bot]

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

Pre-existing issues:
- [Critical] Heap buffer overflow in `cca_ecc2protkey` when copying a user-provided ECC key token into a fixed-size buffer.
--

--- Patch [1]: [PATCH v1 1/2] s390/zcrypt: Validate length for CCA AES cipher key requests ---
commit 7b35c8aa05e7fb7c7837b88e5f3b7fc85f721c98
Author: Holger Dengler <dengler@linux.ibm.com>

s390/zcrypt: Validate length for CCA AES cipher key requests

This commit adds a bounds check in cca_cipher2protkey() to ensure the copy
length derived from the key token does not exceed the available space in the
CPRB parameter block. If the length is too large, the request is rejected
early with -EINVAL.

> diff --git a/drivers/s390/crypto/zcrypt_ccamisc.c b/drivers/s390/crypto/zcrypt_ccamisc.c
> index 84936a795b956..db6a4211a97e0 100644
> --- a/drivers/s390/crypto/zcrypt_ccamisc.c
> +++ b/drivers/s390/crypto/zcrypt_ccamisc.c
> @@ -1261,6 +1261,9 @@ int cca_cipher2protkey(u16 cardnr, u16 domain, const u8 *ckey,
>  	} __packed * prepparm;
>  	int keytoklen = ((struct cipherkeytoken *)ckey)->len;
>  
> +	if (keytoklen > PARMBSIZE - sizeof(struct aureqparm))
> +		return -EINVAL;
> +

[Severity: Critical]
This is a pre-existing issue, but does a similar heap buffer overflow exist in
cca_ecc2protkey()?

It appears cca_ecc2protkey() also copies a user-provided ECC key token into a
fixed-size buffer without a similar bounds check. A user with access to
/dev/pkey could call the PKEY_KBLOB2PROTK2 ioctl, passing an
eccprivkeytoken with a large len field.

This would be passed down through cca_key2protkey() to cca_ecc2protkey(),
where it allocates a 512-byte parameter block via
alloc_and_prep_cprbmem() and copies the token:

drivers/s390/crypto/zcrypt_ccamisc.c:cca_ecc2protkey() {
    ...
	int keylen = ((struct eccprivkeytoken *)key)->len;

	/* get already prepared memory for 2 cprbs with param block each */
	rc = alloc_and_prep_cprbmem(PARMBSIZE, &mem,
				    &preqcblk, &prepcblk, xflags);
    ...
	/* kb, cca token */
	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);
    ...
}

Since the parameter block header consumes 90 bytes, any keylen > 422 bytes
could overflow the allocated memory. Is a similar check needed there?

>  	/* get already prepared memory for 2 cprbs with param block each */
>  	rc = alloc_and_prep_cprbmem(PARMBSIZE, &mem,
>  				    &preqcblk, &prepcblk, xflags);

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

Re: [PATCH v1 1/2] s390/zcrypt: Validate length for CCA AES cipher key requests

[Holger Dengler]

This is fixed by patch 2/2 of this series.

On 7/29/26 11:58, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> 
> Pre-existing issues:
> - [Critical] Heap buffer overflow in `cca_ecc2protkey` when copying a user-provided ECC key token into a fixed-size buffer.
> --
> 
> --- Patch [1]: [PATCH v1 1/2] s390/zcrypt: Validate length for CCA AES cipher key requests ---
> commit 7b35c8aa05e7fb7c7837b88e5f3b7fc85f721c98
> Author: Holger Dengler <dengler@linux.ibm.com>
> 
> s390/zcrypt: Validate length for CCA AES cipher key requests
> 
> This commit adds a bounds check in cca_cipher2protkey() to ensure the copy
> length derived from the key token does not exceed the available space in the
> CPRB parameter block. If the length is too large, the request is rejected
> early with -EINVAL.
> 
>> diff --git a/drivers/s390/crypto/zcrypt_ccamisc.c b/drivers/s390/crypto/zcrypt_ccamisc.c
>> index 84936a795b956..db6a4211a97e0 100644
>> --- a/drivers/s390/crypto/zcrypt_ccamisc.c
>> +++ b/drivers/s390/crypto/zcrypt_ccamisc.c
>> @@ -1261,6 +1261,9 @@ int cca_cipher2protkey(u16 cardnr, u16 domain, const u8 *ckey,
>>  	} __packed * prepparm;
>>  	int keytoklen = ((struct cipherkeytoken *)ckey)->len;
>>  
>> +	if (keytoklen > PARMBSIZE - sizeof(struct aureqparm))
>> +		return -EINVAL;
>> +
> 
> [Severity: Critical]
> This is a pre-existing issue, but does a similar heap buffer overflow exist in
> cca_ecc2protkey()?
> 
> It appears cca_ecc2protkey() also copies a user-provided ECC key token into a
> fixed-size buffer without a similar bounds check. A user with access to
> /dev/pkey could call the PKEY_KBLOB2PROTK2 ioctl, passing an
> eccprivkeytoken with a large len field.
> 
> This would be passed down through cca_key2protkey() to cca_ecc2protkey(),
> where it allocates a 512-byte parameter block via
> alloc_and_prep_cprbmem() and copies the token:
> 
> drivers/s390/crypto/zcrypt_ccamisc.c:cca_ecc2protkey() {
>     ...
> 	int keylen = ((struct eccprivkeytoken *)key)->len;
> 
> 	/* get already prepared memory for 2 cprbs with param block each */
> 	rc = alloc_and_prep_cprbmem(PARMBSIZE, &mem,
> 				    &preqcblk, &prepcblk, xflags);
>     ...
> 	/* kb, cca token */
> 	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);
>     ...
> }
> 
> Since the parameter block header consumes 90 bytes, any keylen > 422 bytes
> could overflow the allocated memory. Is a similar check needed there?
> 
>>  	/* get already prepared memory for 2 cprbs with param block each */
>>  	rc = alloc_and_prep_cprbmem(PARMBSIZE, &mem,
>>  				    &preqcblk, &prepcblk, xflags);
> 

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

Re: [PATCH v1 1/2] s390/zcrypt: Validate length for CCA AES cipher key requests

[Harald Freudenberger]

On 2026-07-29 11:36, Holger Dengler wrote:
> cca_cipher2protkey() derives the copy length for the CPRB parameter
> block directly from the length field in the key token. Reject the
> request early if the token length exceeds the available space in the
> parameter block.
> 
> Fixes: 4bc123b18ce6 ("s390/zcrypt: Add low level functions for CCA AES
> cipher keys")
> Signed-off-by: Holger Dengler <dengler@linux.ibm.com>
> Cc: stable@vger.kernel.org # 5.4+
> ---
>  drivers/s390/crypto/zcrypt_ccamisc.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/s390/crypto/zcrypt_ccamisc.c
> b/drivers/s390/crypto/zcrypt_ccamisc.c
> index 84936a795b95..db6a4211a97e 100644
> --- a/drivers/s390/crypto/zcrypt_ccamisc.c
> +++ b/drivers/s390/crypto/zcrypt_ccamisc.c
> @@ -1261,6 +1261,9 @@ int cca_cipher2protkey(u16 cardnr, u16 domain,
> const u8 *ckey,
>  	} __packed * prepparm;
>  	int keytoklen = ((struct cipherkeytoken *)ckey)->len;
> 
> +	if (keytoklen > PARMBSIZE - sizeof(struct aureqparm))
> +		return -EINVAL;
> +
>  	/* get already prepared memory for 2 cprbs with param block each */
>  	rc = alloc_and_prep_cprbmem(PARMBSIZE, &mem,
>  				    &preqcblk, &prepcblk, xflags);

Reviewed-by: Harald Freudenberger <freude@linux.ibm.com>

[PATCH v1 2/2] s390/zcrypt: Validate length for CCA ECC private key requests

[Holger Dengler]

cca_ecc2protkey() derives the copy length for the CPRB parameter
block directly from the length field in the key token. Reject the
request early if the token length exceeds the available space in the
parameter block.

Fixes: fa6999e326fe ("s390/pkey: support CCA and EP11 secure ECC private keys")
Signed-off-by: Holger Dengler <dengler@linux.ibm.com>
Cc: stable@vger.kernel.org # 5.10+
---
 drivers/s390/crypto/zcrypt_ccamisc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/s390/crypto/zcrypt_ccamisc.c b/drivers/s390/crypto/zcrypt_ccamisc.c
index db6a4211a97e..322677a8d320 100644
--- a/drivers/s390/crypto/zcrypt_ccamisc.c
+++ b/drivers/s390/crypto/zcrypt_ccamisc.c
@@ -1428,6 +1428,9 @@ int cca_ecc2protkey(u16 cardnr, u16 domain, const u8 *key,
 	} __packed * prepparm;
 	int keylen = ((struct eccprivkeytoken *)key)->len;
 
+	if (keylen > PARMBSIZE - sizeof(struct aureqparm))
+		return -EINVAL;
+
 	/* get already prepared memory for 2 cprbs with param block each */
 	rc = alloc_and_prep_cprbmem(PARMBSIZE, &mem,
 				    &preqcblk, &prepcblk, xflags);
-- 
2.55.0

Re: [PATCH v1 2/2] s390/zcrypt: Validate length for CCA ECC private key requests

[Harald Freudenberger]

On 2026-07-29 11:36, Holger Dengler wrote:
> cca_ecc2protkey() derives the copy length for the CPRB parameter
> block directly from the length field in the key token. Reject the
> request early if the token length exceeds the available space in the
> parameter block.
> 
> Fixes: fa6999e326fe ("s390/pkey: support CCA and EP11 secure ECC 
> private keys")
> Signed-off-by: Holger Dengler <dengler@linux.ibm.com>
> Cc: stable@vger.kernel.org # 5.10+
> ---
>  drivers/s390/crypto/zcrypt_ccamisc.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/s390/crypto/zcrypt_ccamisc.c
> b/drivers/s390/crypto/zcrypt_ccamisc.c
> index db6a4211a97e..322677a8d320 100644
> --- a/drivers/s390/crypto/zcrypt_ccamisc.c
> +++ b/drivers/s390/crypto/zcrypt_ccamisc.c
> @@ -1428,6 +1428,9 @@ int cca_ecc2protkey(u16 cardnr, u16 domain, const 
> u8 *key,
>  	} __packed * prepparm;
>  	int keylen = ((struct eccprivkeytoken *)key)->len;
> 
> +	if (keylen > PARMBSIZE - sizeof(struct aureqparm))
> +		return -EINVAL;
> +
>  	/* get already prepared memory for 2 cprbs with param block each */
>  	rc = alloc_and_prep_cprbmem(PARMBSIZE, &mem,
>  				    &preqcblk, &prepcblk, xflags);

Reviewed-by: Harald Freudenberger <freude@linux.ibm.com>

Re: [PATCH v1 2/2] s390/zcrypt: Validate length for CCA ECC private key requests

[sashiko-bot]

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

Pre-existing issues:
- [High] Missing bounds validation on user-provided keys leads to Slab Out-of-Bounds Reads.
- [High] Unvalidated token length from hardware reply causes Heap Buffer Overflow and Out-of-Bounds Read.
--

--- Patch [2]: [PATCH v1 2/2] s390/zcrypt: Validate length for CCA ECC private key requests ---
commit dd9e9a635152d7bae8edba05dc9b9aad02d9a1e9
Author: Holger Dengler <dengler@linux.ibm.com>

s390/zcrypt: Validate length for CCA ECC private key requests

This patch adds a length validation check for CCA ECC private key requests in
cca_ecc2protkey(). It ensures the key token length does not exceed the
available space in the parameter block before proceeding with CPRB memory
allocation.

> diff --git a/drivers/s390/crypto/zcrypt_ccamisc.c b/drivers/s390/crypto/zcrypt_ccamisc.c
> index db6a4211a97e0..322677a8d3200 100644
> --- a/drivers/s390/crypto/zcrypt_ccamisc.c
> +++ b/drivers/s390/crypto/zcrypt_ccamisc.c
> @@ -1428,6 +1428,9 @@ int cca_ecc2protkey(u16 cardnr, u16 domain, const u8 *key,
>  	} __packed * prepparm;
>  	int keylen = ((struct eccprivkeytoken *)key)->len;
>  
> +	if (keylen > PARMBSIZE - sizeof(struct aureqparm))
> +		return -EINVAL;
> +
>  	/* get already prepared memory for 2 cprbs with param block each */
>  	rc = alloc_and_prep_cprbmem(PARMBSIZE, &mem,
>  				    &preqcblk, &prepcblk, xflags);

[Severity: High]
This is a pre-existing issue, but since we are adding length validations in 
this subsystem, is it possible for unprivileged users to trigger slab 
out-of-bounds reads in other functions like cca_apqns4key(), 
cca_verifykey(), and cca_key2protkey() in drivers/s390/crypto/pkey_cca.c?

If a user triggers an ioctl like PKEY_APQNS4K with an 8-byte buffer and sets 
keylen=8, _copy_key_from_user() will allocate exactly 8 bytes. The code only 
verifies that keylen is at least 8 bytes, but then casts the buffer to 
larger structures.

In drivers/s390/crypto/pkey_cca.c:cca_apqns4key():

    if (flags & PKEY_FLAGS_MATCH_CUR_MKVP)
        ptr_cur_mkvp = t->mkvp;

Could this access t->mkvp well beyond the 8-byte allocation?

Similarly, in drivers/s390/crypto/pkey_cca.c:cca_key2protkey():

    if (cca_check_secaescipherkey(pkey_dbf_info,
                  3, key, 0, 1))

Does this pass the key buffer to a function that reads up to 60 bytes, 
without verifying the key is actually large enough (since checking against 
hdr->len could be bypassed if the user sets hdr->len = 8)?

And in drivers/s390/crypto/pkey_cca.c:cca_verifykey():

    *keybitsize = t->bitsize;

Does this access t->bitsize at offset 56 directly after only verifying the 
8-byte header?

[Severity: High]
This is also a pre-existing issue, but I noticed there might be another spot 
in zcrypt_ccamisc.c where we trust token lengths without sufficient bounds 
checking. 

If a malfunctioning or compromised APQN crypto device returns a CPRB hardware 
reply with a large t->len value, could this lead to an out-of-bounds read or 
heap buffer overflow?

In drivers/s390/crypto/zcrypt_ccamisc.c:_ip_cprb_helper():

    memcpy(key_token, t, t->len);

Does this trust the t->len value from the hardware response blindly, 
potentially causing an unbounded write to the destination buffer?

Also, in drivers/s390/crypto/zcrypt_ccamisc.c:cca_gencipherkey():

    if (*keybufsize >= t->len)
        memcpy(keybuf, t, t->len);

Since *keybufsize is user-controlled (up to 8192) but the CPRB parameter 
block backing t is strictly allocated to PARMBSIZE (512 bytes), could an 
oversized t->len bypass this check? Would this cause memcpy() to read 
beyond the 512-byte allocation and leak kernel memory back to userspace?

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

Re: [PATCH v1 2/2] s390/zcrypt: Validate length for CCA ECC private key requests

[Holger Dengler]

The findings will be covered in a separate series.

On 7/29/26 12:16, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> 
> Pre-existing issues:
> - [High] Missing bounds validation on user-provided keys leads to Slab Out-of-Bounds Reads.
> - [High] Unvalidated token length from hardware reply causes Heap Buffer Overflow and Out-of-Bounds Read.
> --
> 
> --- Patch [2]: [PATCH v1 2/2] s390/zcrypt: Validate length for CCA ECC private key requests ---
> commit dd9e9a635152d7bae8edba05dc9b9aad02d9a1e9
> Author: Holger Dengler <dengler@linux.ibm.com>
> 
> s390/zcrypt: Validate length for CCA ECC private key requests
> 
> This patch adds a length validation check for CCA ECC private key requests in
> cca_ecc2protkey(). It ensures the key token length does not exceed the
> available space in the parameter block before proceeding with CPRB memory
> allocation.
> 
>> diff --git a/drivers/s390/crypto/zcrypt_ccamisc.c b/drivers/s390/crypto/zcrypt_ccamisc.c
>> index db6a4211a97e0..322677a8d3200 100644
>> --- a/drivers/s390/crypto/zcrypt_ccamisc.c
>> +++ b/drivers/s390/crypto/zcrypt_ccamisc.c
>> @@ -1428,6 +1428,9 @@ int cca_ecc2protkey(u16 cardnr, u16 domain, const u8 *key,
>>  	} __packed * prepparm;
>>  	int keylen = ((struct eccprivkeytoken *)key)->len;
>>  
>> +	if (keylen > PARMBSIZE - sizeof(struct aureqparm))
>> +		return -EINVAL;
>> +
>>  	/* get already prepared memory for 2 cprbs with param block each */
>>  	rc = alloc_and_prep_cprbmem(PARMBSIZE, &mem,
>>  				    &preqcblk, &prepcblk, xflags);
> 
> [Severity: High]
> This is a pre-existing issue, but since we are adding length validations in 
> this subsystem, is it possible for unprivileged users to trigger slab 
> out-of-bounds reads in other functions like cca_apqns4key(), 
> cca_verifykey(), and cca_key2protkey() in drivers/s390/crypto/pkey_cca.c?
> 
> If a user triggers an ioctl like PKEY_APQNS4K with an 8-byte buffer and sets 
> keylen=8, _copy_key_from_user() will allocate exactly 8 bytes. The code only 
> verifies that keylen is at least 8 bytes, but then casts the buffer to 
> larger structures.
> 
> In drivers/s390/crypto/pkey_cca.c:cca_apqns4key():
> 
>     if (flags & PKEY_FLAGS_MATCH_CUR_MKVP)
>         ptr_cur_mkvp = t->mkvp;
> 
> Could this access t->mkvp well beyond the 8-byte allocation?
> 
> Similarly, in drivers/s390/crypto/pkey_cca.c:cca_key2protkey():
> 
>     if (cca_check_secaescipherkey(pkey_dbf_info,
>                   3, key, 0, 1))
> 
> Does this pass the key buffer to a function that reads up to 60 bytes, 
> without verifying the key is actually large enough (since checking against 
> hdr->len could be bypassed if the user sets hdr->len = 8)?
> 
> And in drivers/s390/crypto/pkey_cca.c:cca_verifykey():
> 
>     *keybitsize = t->bitsize;
> 
> Does this access t->bitsize at offset 56 directly after only verifying the 
> 8-byte header?
> 
> [Severity: High]
> This is also a pre-existing issue, but I noticed there might be another spot 
> in zcrypt_ccamisc.c where we trust token lengths without sufficient bounds 
> checking. 
> 
> If a malfunctioning or compromised APQN crypto device returns a CPRB hardware 
> reply with a large t->len value, could this lead to an out-of-bounds read or 
> heap buffer overflow?
> 
> In drivers/s390/crypto/zcrypt_ccamisc.c:_ip_cprb_helper():
> 
>     memcpy(key_token, t, t->len);
> 
> Does this trust the t->len value from the hardware response blindly, 
> potentially causing an unbounded write to the destination buffer?
> 
> Also, in drivers/s390/crypto/zcrypt_ccamisc.c:cca_gencipherkey():
> 
>     if (*keybufsize >= t->len)
>         memcpy(keybuf, t, t->len);
> 
> Since *keybufsize is user-controlled (up to 8192) but the CPRB parameter 
> block backing t is strictly allocated to PARMBSIZE (512 bytes), could an 
> oversized t->len bypass this check? Would this cause memcpy() to read 
> beyond the 512-byte allocation and leak kernel memory back to userspace?
> 

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

Re: [PATCH v1 0/2] s390/zcrypt: Validate length in CCA key requests

[Vasily Gorbik]

On Wed, Jul 29, 2026 at 11:36:14AM +0200, Holger Dengler wrote:
> The series contains two missing length field validations for requests
> with CCA AES cipher keys and CCA ECC private keys. In both cases, the
> length information is used to copy the payload to the request block
> without checking the available space. Malformed requests can so cause
> out-of-band writes on the heap.
> 
> This series applies on top of Linus' master branch.
> 
> Holger Dengler (2):
>   s390/zcrypt: Validate length for CCA AES cipher key requests
>   s390/zcrypt: Validate length for CCA ECC private key requests
> 
>  drivers/s390/crypto/zcrypt_ccamisc.c | 6 ++++++
>  1 file changed, 6 insertions(+)

Applied, thank you!