On 20.06.2018 11:21, Georgi Guninski wrote: > I don't have s390 arch so can't verify these. > > They look like classical buffer overflows, are they really? > > In 4.9.109: > > ---snippets > drivers/s390/crypto/zcrypt_cca_key.h > > * @mex: pointer to user input data > * @p: pointer to memory area for the key > > memset(key, 0, sizeof(*key)); > temp = key->pvtMeSec.exponent + > sizeof(key->pvtMeSec.exponent) - mex->inputdatalength; > if (copy_from_user(temp, mex->b_key, mex->inputdatalength)) > return -EFAULT; > > **** > > drivers/s390/crypto/zcrypt_msgtype6.c > > static int ICAMEX_msg_to_type6MEX_msgX(struct zcrypt_device *zdev, > > msg->length = mex->inputdatalength + 2; > if (copy_from_user(msg->text, mex->inputdata, mex->inputdatalength)) > return -EFAULT; > > > ---end snippets > I don't see any checks on "inputdatalength" and it appears to come > from userspace. > Ok, I found the check. These functions are not called at all because there is a validation of the inputdatalength in zcrypt_api.c. The dispatcher functions zcrypt_rsa_modexpo and zcrypt_rsa_crt both check like this: /* Check for size limits */ if (zc->min_mod_size > mex->inputdatalength || zc->max_mod_size < mex->inputdatalength) continue; Which in the end results in not finding any card which is able to handle the (out of range) input data length and thus returning -ENODEV. I also wrote some tests which trigger such invalid messages and the device driver rejects them as expected before any copy_from_user is called. Also verified this on the 4.9 kernel. The code is slightly different but the length check is there and invalid length values are rejected. :-) Thanks Georgi -- To unsubscribe from this list: send the line "unsubscribe linux-s390" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
