qemu-kvm/kvm-chardev-char-socket-Fix-TLS-io-channels-sending-too-.patch

From 95b2ffc5f01dc4309c2e747ed883d22cd1d26347 Mon Sep 17 00:00:00 2001
From: Thomas Huth <thuth@redhat.com>
Date: Sat, 2 Mar 2024 17:00:23 +0100
Subject: [PATCH 2/2] chardev/char-socket: Fix TLS io channels sending too much
 data to the backend
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

RH-Author: Thomas Huth <thuth@redhat.com>
RH-MergeRequest: 227: Fix TLS io channels sending too much data to the backend
RH-Jira: RHEL-24614
RH-Acked-by: Cédric Le Goater <clg@redhat.com>
RH-Acked-by: Daniel P. Berrangé <berrange@redhat.com>
RH-Commit: [1/1] fce871914e0ce52e16a6edae0e007513f9fec1ae (thuth/qemu-kvm-cs9)

JIRA: https://issues.redhat.com/browse/RHEL-24614

commit 462945cd22d2bcd233401ed3aa167d83a8e35b05
Author: Thomas Huth <thuth@redhat.com>
Date:   Thu Feb 29 11:43:37 2024 +0100

    chardev/char-socket: Fix TLS io channels sending too much data to the backend

    Commit ffda5db65a ("io/channel-tls: fix handling of bigger read buffers")
    changed the behavior of the TLS io channels to schedule a second reading
    attempt if there is still incoming data pending. This caused a regression
    with backends like the sclpconsole that check in their read function that
    the sender does not try to write more bytes to it than the device can
    currently handle.

    The problem can be reproduced like this:

     1) In one terminal, do this:

      mkdir qemu-pki
      cd qemu-pki
      openssl genrsa 2048 > ca-key.pem
      openssl req -new -x509 -nodes -days 365000 -key ca-key.pem -out ca-cert.pem
      # enter some dummy value for the cert
      openssl genrsa 2048 > server-key.pem
      openssl req -new -x509 -nodes -days 365000 -key server-key.pem \
        -out server-cert.pem
      # enter some other dummy values for the cert

      gnutls-serv --echo --x509cafile ca-cert.pem --x509keyfile server-key.pem \
                  --x509certfile server-cert.pem -p 8338

     2) In another terminal, do this:

      wget https://download.fedoraproject.org/pub/fedora-secondary/releases/39/Cloud/s390x/images/Fedora-Cloud-Base-39-1.5.s390x.qcow2

      qemu-system-s390x -nographic -nodefaults \
        -hda Fedora-Cloud-Base-39-1.5.s390x.qcow2 \
        -object tls-creds-x509,id=tls0,endpoint=client,verify-peer=false,dir=$PWD/qemu-pki \
        -chardev socket,id=tls_chardev,host=localhost,port=8338,tls-creds=tls0 \
        -device sclpconsole,chardev=tls_chardev,id=tls_serial

    QEMU then aborts after a second or two with:

      qemu-system-s390x: ../hw/char/sclpconsole.c:73: chr_read: Assertion
       `size <= SIZE_BUFFER_VT220 - scon->iov_data_len' failed.
     Aborted (core dumped)

    It looks like the second read does not trigger the chr_can_read() function
    to be called before the second read, which should normally always be done
    before sending bytes to a character device to see how much it can handle,
    so the s->max_size in tcp_chr_read() still contains the old value from the
    previous read. Let's make sure that we use the up-to-date value by calling
    tcp_chr_read_poll() again here.

    Fixes: ffda5db65a ("io/channel-tls: fix handling of bigger read buffers")
    Buglink: https://issues.redhat.com/browse/RHEL-24614
    Reviewed-by: "Daniel P. Berrangé" <berrange@redhat.com>
    Message-ID: <20240229104339.42574-1-thuth@redhat.com>
    Reviewed-by: Antoine Damhet <antoine.damhet@blade-group.com>
    Tested-by: Antoine Damhet <antoine.damhet@blade-group.com>
    Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
    Signed-off-by: Thomas Huth <thuth@redhat.com>

Signed-off-by: Thomas Huth <thuth@redhat.com>
---
 chardev/char-socket.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/chardev/char-socket.c b/chardev/char-socket.c
index 73947da188..034840593d 100644
--- a/chardev/char-socket.c
+++ b/chardev/char-socket.c
@@ -492,9 +492,9 @@ static gboolean tcp_chr_read(QIOChannel *chan, GIOCondition cond, void *opaque)
         s->max_size <= 0) {
         return TRUE;
     }
-    len = sizeof(buf);
-    if (len > s->max_size) {
-        len = s->max_size;
+    len = tcp_chr_read_poll(opaque);
+    if (len > sizeof(buf)) {
+        len = sizeof(buf);
     }
     size = tcp_chr_recv(chr, (void *)buf, len);
     if (size == 0 || (size == -1 && errno != EAGAIN)) {
-- 
2.39.3