From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by passt.top (Postfix) with ESMTPS id F421B5A004E for ; Thu, 25 Jul 2024 06:37:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202312; t=1721882271; bh=jMCPS5odvkdJfqqlZZDTLzGR2HeG9dHZHAOusvkF9fs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=h3YfhStHktJ2smMb1YhFNEbSFCqkl8h2qZMPZ5k0PNq+JDebaeiWEz/h6//TgmZOE TiBFnk5lTkxC/0tMFiLV1xijn7fTtFfavYn0Aq4ag0bDJF6eSledlIiP0apIPRDNSG tGmPi6TBw7TPQ4Mr+tY/+qf0D7DJuhQPqh1aRSzPgbwlBp3yxjIGpHYwPVft4+eFg/ 4qyFcqD3Nzo+XccKhhcoarNI3zmKnDKsamMozh+3KdlSbSWBkGXIgDfgr79w6T0zx+ SJqSRTc4nojld9cw3r0Z6kD2O4NmeSjfAuVr+zZbPPT5Qb3ffMlSVQ+P48gUd28pg9 HsEWiHfUvu71g== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4WTymb6vTCz4x1V; Thu, 25 Jul 2024 14:37:51 +1000 (AEST) Date: Thu, 25 Jul 2024 14:37:43 +1000 From: David Gibson To: Stefano Brivio Subject: Re: [PATCH 10/11] tap: Discard guest data on length descriptor mismatch Message-ID: References: <20240724215021.3366863-1-sbrivio@redhat.com> <20240724215021.3366863-11-sbrivio@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qZiUnRAS83YxLj3j" Content-Disposition: inline In-Reply-To: <20240724215021.3366863-11-sbrivio@redhat.com> Message-ID-Hash: JXSS6FSHVAWZAPWS5R624OPUQICDJXXK X-Message-ID-Hash: JXSS6FSHVAWZAPWS5R624OPUQICDJXXK X-MailFrom: dgibson@gandalf.ozlabs.org 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: --qZiUnRAS83YxLj3j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. >=20 > 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. >=20 > While at it, change l2len in tap_handler_passt() to uint32_t, as the > length descriptor is logically unsigned and 32-bit wide. >=20 > Reported-by: Matej Hrica > Suggested-by: Matej Hrica > Signed-off-by: Stefano Brivio > --- > tap.c | 10 ++++++---- > 1 file changed, 6 insertions(+), 4 deletions(-) >=20 > diff --git a/tap.c b/tap.c > index 44bd444..62ba6a4 100644 > --- a/tap.c > +++ b/tap.c > @@ -1011,15 +1011,18 @@ redo: > } > =20 > while (n > (ssize_t)sizeof(uint32_t)) { > - ssize_t l2len =3D ntohl(*(uint32_t *)p); > + uint32_t l2len =3D ntohl(*(uint32_t *)p); > =20 > p +=3D sizeof(uint32_t); > n -=3D sizeof(uint32_t); > =20 > + 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. 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. 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. 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. 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. > /* 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 =3D recv(c->fd_tap, p + n, l2len - n, 0); > if ((n +=3D rem) !=3D 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(). > @@ -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); --=20 David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson --qZiUnRAS83YxLj3j Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmah1pcACgkQzQJF27ox 2GfYphAAmhtOXwXWrUNA2d/ElyHltIk1pdSTryH9x0IBNCYOd5wMLZXNGq/v466d QiWFRV4HE80GYDDH9EnieGfN+l/g1VJ+66jwxcLUTCYOZ8GsOEX3F/+5Bi9dGH87 e+biMHXOsNMq2urQQOzgEgZrLOGOGDBvgnG1rEvrwn8FO/phqsL8hzsmsfZt+kUO 8eK89HrhthPBUg6eDQTS7HDPqyswVzIPz01gwYsWA1OzaxyUqMc4ILGunMHAi8x3 knp2stOkJe1pjV5CBs3nRerf6BrmcWGXsPcd/42R9Rv0X8sIcj0otb81o1h6gRrl pKguetjWG+Aw9uom4BoCwKMiw4ciNJwr4AKDM55PidOADuzZDp8DpGdXdzVFjzEw y9WldUpaknx6JpsSSgLvnC+oXhd3VVJW/28rQqmo5wk+o3YaF9YusqfuhyeKQUAh EeQ+ehd8DTjRtJ5g3JywoJn8A+2vm/gd4LIEPIHAl/8JzluWLNpunE7jhXt3tD/L AG0Om8p5iamHO+EhhnuOxuR/Xdwec/uqRIcjQAD7T0HZjzLqMHISWIR6R+eIoCxs 7B3XO7lczmA+tAhGd6pL+UtBdOiau6aDM86kgySDLWPnxByNBHPZRQHCu+Be4sHm wib3a73a+6IJyAIYJiaUQcdEDVOHKcxSECuE+lRsGKg4vGA1L3s= =y9u3 -----END PGP SIGNATURE----- --qZiUnRAS83YxLj3j--