Re: [PATCH 2/2] s390/sclp: Implement resize for sclp-vt220 console

[Christian Borntraeger <borntraeger@linux.ibm.com>]

Am 21.09.26 um 14:54 schrieb Maximilian Immanuel Brandtner:
> On Mon, 2026-09-21 at 12:28 +0000, sashiko-bot@kernel.org wrote:
>> Thank you for your contribution! Sashiko AI review found 3 potential
>> issue(s) to consider:
>> - [High] tty: UAPI breakage due to asynchronous winsize
>> initialization in open()
>> - [High] s390/sclp: out-of-bounds read in SCLP_VT220_SESSION_RESIZE
>> parsing
>> - [Medium] s390/sclp: data race when reading shared terminal
>> dimensions
>> --
>>
>> commit 13e18fecbfc8440743cc8dff7c08364db9a637bf
>> Author: Maximilian Immanuel Brandtner <maxbr@linux.ibm.com>
>>
>> s390/sclp: Implement resize for sclp-vt220 console
>>
>> This patch adds support for sclp vt220 resize events to enable host-
>> initiated
>> terminal resizing when using the sclp-vt220 console. This allows QEMU
>> to
>> dynamically resize the console.
>>
>>> diff --git a/drivers/s390/char/sclp_vt220.c
>>> b/drivers/s390/char/sclp_vt220.c
>>> index 7c168a66e4afe..d140617846a2d 100644
>>> --- a/drivers/s390/char/sclp_vt220.c
>>> +++ b/drivers/s390/char/sclp_vt220.c
>>
>> [ ... ]
>>
>>> @@ -543,6 +588,9 @@ static void sclp_vt220_receiver_fn(struct
>>> evbuf_header *evbuf)
>>>   	case SCLP_VT220_SESSION_DATA:
>>>   		/* Send input to line discipline */
>>>   		sclp_vt220_handle_input(buffer->data, count);
>>>   		tty_flip_buffer_push(&sclp_vt220_port);
>>>   		break;
>>> +	case SCLP_VT220_SESSION_RESIZE:
>>> +		sclp_vt220_resize_sched(buffer->data);
>>
>> [Severity: High]
>> If the hypervisor sends an SCLP_VT220_SESSION_RESIZE event with an
>> evbuf->length smaller than expected, is there a risk of reading out
>> of bounds
>> when the data is accessed?
>>
>> This path delegates to sclp_vt220_resize_sched() without verifying if
>> evbuf->length is large enough to contain the 4-byte resize payload.
>> Since the
>> event length is controlled by the hypervisor, could this result in an
>> out-of-bounds memory read when sclp_vt220_resize_sched() reads the
>> rows and
>> cols fields?
> 
> Yes, but a guest needs to trust the hypervisor or firmware anyways to
> provide it with correct data, so I don't see the point in verifying
> data from a trusted source. (Eg what if the hypervisor implemented
> load/store instructions incorrectly -- at that point there is nothing
> the guest can do to operate correctly.) I could add a check here, but I
> don't see the point in it.

There is a point for secure execution / confidential computing. Lets validate
the data.