Re: [PATCH v1 1/1] pkey: Fix bitsize check in PKEY_VERIFYPROTK ioctl

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [Critical] An integer wrap-around in the key bit-size calculation bypasses length validation, leading to massive out-of-bounds memory accesses during a subsequent memcpy().
--

commit 26c99ec1350980042dcf4518941f9831c98478fc
Author: Holger Dengler <dengler@linux.ibm.com>

pkey: Fix bitsize check in PKEY_VERIFYPROTK ioctl

This commit updates the bit-size calculation for protected keys in the
PKEY_VERIFYPROTK ioctl to account for the wrapping key verification pattern
(WKVP). It subtracts the length of the WKVP from the protected key length to
fix the calculation.

> diff --git a/drivers/s390/crypto/pkey_api.c b/drivers/s390/crypto/pkey_api.c
> --- a/drivers/s390/crypto/pkey_api.c
> +++ b/drivers/s390/crypto/pkey_api.c
> @@ -334,7 +334,8 @@ static int pkey_ioctl_verifyprotk(struct pkey_verifyprotk __user *uvp)
>  	if (copy_from_user(&kvp, uvp, sizeof(kvp)))
>  		return -EFAULT;
>  
> -	keytype = pkey_aes_bitsize_to_keytype(8 * kvp.protkey.len);
> +	keytype = pkey_aes_bitsize_to_keytype(8 * (kvp.protkey.len -
> +						   AES_WK_VP_SIZE));

[Severity: Critical]
This is a pre-existing issue, but does this calculation allow an integer
wrap-around that bypasses length validation?

Because kvp.protkey.len is a user-controlled 32-bit unsigned integer and
there is no explicit bounds check against MAXPROTKEYSIZE, a malicious user
can provide an enormous length. For example, if kvp.protkey.len is
536870960 (0x20000030), subtracting AES_WK_VP_SIZE (32) yields 536870928.
Multiplying by 8 results in 4294967424 (0x100000080), which truncates to
128 in 32-bit arithmetic. 

pkey_aes_bitsize_to_keytype(128) then returns PKEY_KEYTYPE_AES_128, passing
the !keytype check.

Further down in pkey_ioctl_verifyprotk(), the unvalidated oversized length
is passed into memcpy(t->protkey, kvp.protkey.protkey, kvp.protkey.len).
Since kvp.protkey.protkey is a 64-byte array on the kernel stack and t
points to an 80-byte heap allocation, wouldn't this cause catastrophic
out-of-bounds memory accesses?

>  	if (!keytype) {
>  		PKEY_DBF_ERR("%s unknown/unsupported protkey length %u\n",
>  			     __func__, kvp.protkey.len);

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