Re: [PATCH v7 5/5] s390/zcrypt: Pad trailing CCA or EP11 message with zeros

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Missing bounds check on `offset1` and `count1` in `zcrypt_msgtype6_receive` when `count2` is present, leading to an arbitrary kernel memory disclosure to userspace.
--

--- Patch [5]: [PATCH v7 5/5] s390/zcrypt: Pad trailing CCA or EP11 message with zeros ---
commit d39d55b2525dc84382b638f22d1bbcec3350871f
Author: Harald Freudenberger <freude@linux.ibm.com>

s390/zcrypt: Pad trailing CCA or EP11 message with zeros

This commit pads the gap between the user space copied message and the
message buffer length with zeros. This prevents up to 3 bytes of
uninitialized kernel memory from being exposed to the crypto card firmware.

> diff --git a/drivers/s390/crypto/zcrypt_msgtype6.c b/drivers/s390/crypto/zcrypt_msgtype6.c
> index 59e182d1bddf9..0269c92a84bd4 100644
> --- a/drivers/s390/crypto/zcrypt_msgtype6.c
> +++ b/drivers/s390/crypto/zcrypt_msgtype6.c

[ ... ]

[Severity: High]
This is a pre-existing issue, but while looking at this file, does this code
in zcrypt_msgtype6_receive() lack a bounds check for offset1 and count1 when
count2 is present?

drivers/s390/crypto/zcrypt_msgtype6.c:zcrypt_msgtype6_receive() {
    ...
			if (t86r->fmt2.count2)
				len = t86r->fmt2.offset2 + t86r->fmt2.count2;
			else
				len = t86r->fmt2.offset1 + t86r->fmt2.count1;
			if (len > reply->bufsize || len > msg->bufsize ||
			    len != reply->len) {
    ...
}

If a faulty or compromised crypto card firmware returns a response where
count2 != 0 but offset1 + count1 is maliciously large, len is calculated
entirely from offset2 + count2. This skips bounds checking for offset1 +
count1 against the buffer bounds.

Later, in convert_type86_xcrb(), the unvalidated offset1 and count1 are used
to copy kernel memory to userspace:

drivers/s390/crypto/zcrypt_msgtype6.c:convert_type86_xcrb() {
    ...
	if (z_copy_to_user(userspace, xcrb->reply_control_blk_addr,
			   data + msg->fmt2.offset1, msg->fmt2.count1))
		return -EFAULT;
    ...
}

Could this lead to an out-of-bounds read that leaks uninitialized slab
memory or unrelated kernel memory to userspace?

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