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 D4EA55A004F for ; Fri, 26 Jul 2024 13:26:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1721993218; 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=jxNofsLE9Qht+FaEM4ZwcsG38Q4g3bQIKlNhq87UP0E=; b=NZTJ0ar/oy5I2/l20d6ZdW3J5P/M5FqSFFSha9bLexfNIxK1sXe3T1VEdt3wqb5dmhAFcR UvzYP7DmfkTJ+SgQDAxvrdiit5buRUzHIbzs0alWRUD78UTmmgv7f7mxzdYN5GYmI22Bxg I61TlSDzgCll/wXu/QpbcB0lFZmHaeU= Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-637-Ldmn4r09ND2ahSiFRV9vXg-1; Fri, 26 Jul 2024 07:26:57 -0400 X-MC-Unique: Ldmn4r09ND2ahSiFRV9vXg-1 Received: by mail-qv1-f72.google.com with SMTP id 6a1803df08f44-6b5e4073c5fso7565776d6.2 for ; Fri, 26 Jul 2024 04:26:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721993216; x=1722598016; 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=jxNofsLE9Qht+FaEM4ZwcsG38Q4g3bQIKlNhq87UP0E=; b=Oln1uIBM8y5ct1j/JPt5XQjuhYUCG8DXntD9md8xZC4okyPlKoWS2LaP9qQnZrmhCR 7sH0gHRKZKKftZkfF4F9X3Vnrw+1qJTRgWnY2oTbzQG6Zq4PwlU6+tr4CBEY0hTO39lM 9tGwgj549jD/dnG4c9KY7/OYajR3z4jG3Bd44i+yaKmkjfAXjUfvNpjlp9w03YX562gH XbuadgN3rLeDFyAIjVcpalQd+UkMbiVrNl2uwZizct76LZBgtelAkSZiPha2i7efG0aV nFpDO7XnVvBJTU61gr46oe2mMqJfL30kYDMe6RAnQ4D6GyAqZgJuQfRVYK9BvNxN/Geo ABdA== X-Gm-Message-State: AOJu0YzzU2rtee1iIwO2lbyce2qaIBU/yfmjeBaN17eMrkZ11dq5rr+U ePIoni7vnzejzgjK3RM4REogwWlizrCHnchBa6yV2SeePZe49WbeAh418WX+3HkVJuJsH5brtse d9xBmRA0nVyZwWNn9+pFnqqKhkeTnJbcf6iNXNZfRSBk4aSpaKrwylCaZtIR9 X-Received: by 2002:a05:6214:1c46:b0:6b0:90d8:b698 with SMTP id 6a1803df08f44-6bb4086f8eemr48477956d6.45.1721993215979; Fri, 26 Jul 2024 04:26:55 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFQRA5l7QTt8QQvgt7hrFxHsLrW7emwT34zImexg+tw60bQpCjJAG5JtXymKW38JUZa580n0A== X-Received: by 2002:a05:6214:1c46:b0:6b0:90d8:b698 with SMTP id 6a1803df08f44-6bb4086f8eemr48477806d6.45.1721993215658; Fri, 26 Jul 2024 04:26:55 -0700 (PDT) Received: from maya.cloud.tilaa.com (maya.cloud.tilaa.com. [164.138.29.33]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6bb3f8d8269sm15580146d6.20.2024.07.26.04.26.54 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Jul 2024 04:26:54 -0700 (PDT) Date: Fri, 26 Jul 2024 13:26:20 +0200 From: Stefano Brivio To: David Gibson Subject: Re: [PATCH 2/5] tap: Don't attempt to carry on if we get a bad frame length from qemu Message-ID: <20240726132620.6cda96e9@elisabeth> In-Reply-To: <20240726072031.3941305-3-david@gibson.dropbear.id.au> References: <20240726072031.3941305-1-david@gibson.dropbear.id.au> <20240726072031.3941305-3-david@gibson.dropbear.id.au> 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: 4P2NBEJBKN5LAYJ5HQT2YSCGPS73K3SV X-Message-ID-Hash: 4P2NBEJBKN5LAYJ5HQT2YSCGPS73K3SV 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 Fri, 26 Jul 2024 17:20:28 +1000 David Gibson wrote: > If we receive a too-short or too-long frame from the QEMU socket, currently > we try to skip it and carry on. That sounds sensible on first blush, but > probably isn't wise in practice. If this happens, either (a) qemu has done > something seriously unexpected, or (b) we've received corrupt data over a > Unix socket. Or more likely (c), we have a bug elswhere which has put us > out of sync with the stream, so we're trying to read something that's not a > frame length as a frame length. > > Neither (b) nor (c) is really salvageable with the same stream. Case (a) > might be ok, but we can no longer be confident qemu won't do something else > we can't cope with. > > So, instead of just skipping the frame and trying to carry on, log an error > and close the socket. As a bonus, establishing firm bounds on l2len early > will allow simplifications to how we deal with the case where a partial > frame is recv()ed. > > Signed-off-by: David Gibson > --- > tap.c | 16 +++++++--------- > 1 file changed, 7 insertions(+), 9 deletions(-) > > diff --git a/tap.c b/tap.c > index a2ae7c2a..08700f65 100644 > --- a/tap.c > +++ b/tap.c > @@ -1013,7 +1013,13 @@ redo: > } > > while (n > (ssize_t)sizeof(uint32_t)) { > - ssize_t l2len = ntohl(*(uint32_t *)p); > + uint32_t l2len = ntohl(*(uint32_t *)p); > + > + if (l2len < sizeof(struct ethhdr) || l2len > ETH_MAX_MTU) { > + err("Invalid frame size from QEMU (corrupt stream?)"); Same as my comment to 1/5, let me change this to: err("Bad frame size from guest, resetting connection"); -- Stefano