From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by passt.top (Postfix) with ESMTP id A7D7B5A004E for ; Thu, 25 Jul 2024 11:15:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1721898944; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=GNtcaF/fDxHN4/kV0ZvwNKZTbqOWgmboHJDWdMu37WQ=; b=ZN5tARRAyU9ceh477sGAFmghzuii41X+auhVT330KYsRr4NJjlXmV/6iKuGfz9ePWg1k4/ gq2L6KEfjY1UFmfj5Dq+ibPNM0hpEh+27y3VG/OQG2u9hAGOecHiCFuTiWJBqmlR6NCrCv AIMBDgZeL5t0r3j1b9FdSuhrUOLES0w= Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-561-0n8W-RQIPha4fH3XbwbYhA-1; Thu, 25 Jul 2024 05:15:40 -0400 X-MC-Unique: 0n8W-RQIPha4fH3XbwbYhA-1 Received: by mail-qt1-f197.google.com with SMTP id d75a77b69052e-44f2e97d2c7so9818161cf.0 for ; Thu, 25 Jul 2024 02:15:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721898939; x=1722503739; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=GNtcaF/fDxHN4/kV0ZvwNKZTbqOWgmboHJDWdMu37WQ=; b=epI58/S5sBoRHcnugMv+cKJjMCtq3FLcAox/neA4XA7hc4QmZkFlZF2+PNCsYXC5Zr sSz6v0ESUA9sL6fbDj6UCvUkjBH8lsneUGYqyXwbG0YJrHuseRy+DagS13L76my7jzb3 5z0jZsCrzFGgk4yKSm+xaAkY1+szWIEdP4PCpooEbJAtPKbEYnWMElZLmYJ/NxZTw15b bfEPU3eaHPWtK84amvDkgKdxE2f/16ai2P1fIfu8mSFDW9lUv50qJHrFYSiW2ytzS0J0 /HI9ot5RxvK/3S593yk0RzLh06OB7NVGEjedVN9CmIPmuLSPEnaojJ1qAo/S1ImtBMdr nbxA== X-Gm-Message-State: AOJu0YzYxVTXMOnNYRR0vk7dwmV09TzYPVrSgcBK+i+F7PwqJI9ma7PR w/Clwiiga8/dM9lFCPJYrytJGSf5SngjOYAFm2d6pdOWtRUmCyO5ky8hdPkrbv4VeWrwZggd8NV R3zgtstqUfknFrulzbXB+7CJ1VoeK2BYORGRIBe06fINk/us06VWtgR7tDQVk X-Received: by 2002:a05:622a:6113:b0:446:395a:37d2 with SMTP id d75a77b69052e-44fe91b6488mr11728761cf.25.1721898939088; Thu, 25 Jul 2024 02:15:39 -0700 (PDT) X-Google-Smtp-Source: AGHT+IETYeS0+9Blo8ML7XmIPOSHMbZMfn36lNBtvlJWb/fC4zoSd6jKllQCA2ZSANtBfS90gd6vMg== X-Received: by 2002:a05:622a:6113:b0:446:395a:37d2 with SMTP id d75a77b69052e-44fe91b6488mr11728561cf.25.1721898938571; Thu, 25 Jul 2024 02:15:38 -0700 (PDT) Received: from maya.cloud.tilaa.com (maya.cloud.tilaa.com. [164.138.29.33]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-44fe8147958sm4446031cf.32.2024.07.25.02.15.37 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jul 2024 02:15:38 -0700 (PDT) Date: Thu, 25 Jul 2024 11:15:03 +0200 From: Stefano Brivio To: David Gibson Subject: Re: [PATCH 10/11] tap: Discard guest data on length descriptor mismatch Message-ID: <20240725111456.47c37d6f@elisabeth> In-Reply-To: References: <20240724215021.3366863-1-sbrivio@redhat.com> <20240724215021.3366863-11-sbrivio@redhat.com> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.41; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: 6QC5EGNE3BXEM227JCW4MTLEYXMJY4J4 X-Message-ID-Hash: 6QC5EGNE3BXEM227JCW4MTLEYXMJY4J4 X-MailFrom: sbrivio@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: passt-dev@passt.top X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Thu, 25 Jul 2024 14:37:43 +1000 David Gibson wrote: > On Wed, Jul 24, 2024 at 11:50:16PM +0200, Stefano Brivio wrote: > > This was reported by Matej a while ago, but we forgot to fix it. Even > > if the hypervisor is necessarily trusted by passt, as it can in any > > case terminate the guest or disrupt guest connectivity, it's a good > > idea to be robust against possible issues. > > > > Instead of resetting the connection to the hypervisor, just discard > > the data we read with a single recv(), as we had a few cases where > > QEMU would get the length descriptor wrong, in the past. > > > > While at it, change l2len in tap_handler_passt() to uint32_t, as the > > length descriptor is logically unsigned and 32-bit wide. > > > > Reported-by: Matej Hrica > > Suggested-by: Matej Hrica > > Signed-off-by: Stefano Brivio > > --- > > tap.c | 10 ++++++---- > > 1 file changed, 6 insertions(+), 4 deletions(-) > > > > diff --git a/tap.c b/tap.c > > index 44bd444..62ba6a4 100644 > > --- a/tap.c > > +++ b/tap.c > > @@ -1011,15 +1011,18 @@ redo: > > } > > > > while (n > (ssize_t)sizeof(uint32_t)) { > > - ssize_t l2len = ntohl(*(uint32_t *)p); > > + uint32_t l2len = ntohl(*(uint32_t *)p); > > > > p += sizeof(uint32_t); > > n -= sizeof(uint32_t); > > > > + if (l2len > (ssize_t)TAP_BUF_BYTES - n) > > + return; > > Neither the condition nor the action makes much sense to me here. > We're testing if the frame can fit in the the remaining buffer space. Not really, we're just checking that the length descriptor fits the remaining buffer space. We're using this in the second recv() below, that's why it matters here. > But we may have already read part (or all) of the frame - i.e. it's > included in 'n'. So I don't see how that condition is useful. ...that is, it has nothing to do with exceeding or not exceeding the buffer on recv(), that's already taken care of by the recv() call, implicitly. > Then, simply returning doesn't seem right under pretty much any > circumstances - that discards some amount of data, and leaves us in an > unsynchronized state w.r.t. the frame boundaries. That might happen, of course, but it might also happen that the hypervisor sent us *one* corrupted buffer, and the next recv() will read consistent data. > If this is just supposed to be a sanity check on the frame length, > then I think we'd be better off with a fixed limit - 64kiB is the > obvious choice. That's already checked below (l2len > ETH_MAX_MTU), and... > If we hit that, we can warn() and discard data up to > the end of the too-large frame. That at least has a chance of letting > us recover and move on to future acceptable frames. that's exactly what we do in that case (goto next). > > /* At most one packet might not fit in a single read, and this > > * needs to be blocking. > > */ > > - if (l2len > n) { > > + if (l2len > (size_t)n) { > > rem = recv(c->fd_tap, p + n, l2len - n, 0); ^^^^^^^^^^^^^^^^ This the reason why the check above is relevant. > > if ((n += rem) != l2len) > > return; > > Pre-existing, but a 'return' here basically lands us in a situation we > have no meaningful chance of recovering from. A die() would be > preferable. Better yet would be continuing to re-recv() until we have > the whole frame, similar to what we do for write_remainder(). Same as above, it depends on what failure you're assuming. If it's just one botched recv(), instead, we recv() again the next time and we recover. But yes, the first attempt should probably be to recv() the rest of the frame. I didn't implement this because it adds complexity and I think that, eventually, we should turn this into a proper ringbuffer anyway. > > @@ -1028,8 +1031,7 @@ redo: > > /* Complete the partial read above before discarding a malformed > > * frame, otherwise the stream will be inconsistent. > > */ > > - if (l2len < (ssize_t)sizeof(struct ethhdr) || > > - l2len > (ssize_t)ETH_MAX_MTU) > > + if (l2len < sizeof(struct ethhdr) || l2len > ETH_MAX_MTU) > > goto next; > > tap_add_packet(c, l2len, p); -- Stefano