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 0A5F15A004F for ; Fri, 28 Jun 2024 09:19:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202312; t=1719559186; bh=rvSh/9esUFvVkAm3j4pCgtsfQzq2B9sOgad5b1bpuGc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=J2MLIvkUqHB/wKQIC2czRL6JSahyfuWv9XlVweND3pRgmu8+UbVDlGtTw4BVao5eN ZU8EPuqpON5AsVSN/2rblHPnbZQN6P4lgubz+L6HknBocgUTWbUpIg/4Z0rczc0QSs 0tYKGnu8vB3YaeUnf/8fxZza30IKhywezWyrr1W4tO0JPCbs+mtIxYHq1iZjJ0RiES q70aNtqrrKhSR4x0LP0mA5NgZk2R72CJnh+DkbqwTMGZkpS6RBK3GaCnJJaFR+KTEH 4yPgg+zBy3OH9S5oost409wgvrQJwamGlOZDTB5OYuj7+Vdew4JLIMENuPIOz4sQEK YGpaKwjcy/XfA== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4W9Rdt49zFz4wcr; Fri, 28 Jun 2024 17:19:46 +1000 (AEST) Date: Fri, 28 Jun 2024 17:19:37 +1000 From: David Gibson To: Stefano Brivio Subject: Re: [PATCH 4/4] tap: Drop frames from guest whose length is more than remaining buffer Message-ID: References: <20240626234536.3306466-1-sbrivio@redhat.com> <20240626234536.3306466-5-sbrivio@redhat.com> <20240627102057.2f452002@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xqWS7NjZn+uB78uV" Content-Disposition: inline In-Reply-To: <20240627102057.2f452002@elisabeth> Message-ID-Hash: CJY57QXUX5FSY75QMUC7HKRWLELTZSE6 X-Message-ID-Hash: CJY57QXUX5FSY75QMUC7HKRWLELTZSE6 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, Matej Hrica 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: --xqWS7NjZn+uB78uV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 27, 2024 at 10:21:04AM +0200, Stefano Brivio wrote: > On Thu, 27 Jun 2024 11:30:02 +1000 > David Gibson wrote: >=20 > > On Thu, Jun 27, 2024 at 01:45:36AM +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 skip the > > > offending frame, as we had a few cases where QEMU would get the > > > length descriptor wrong, in the past. > > >=20 > > > Reported-by: Matej Hrica > > > Suggested-by: Matej Hrica > > > Signed-off-by: Stefano Brivio > > > --- > > > tap.c | 3 +++ > > > 1 file changed, 3 insertions(+) > > >=20 > > > diff --git a/tap.c b/tap.c > > > index 7f8c26d..bb993e0 100644 > > > --- a/tap.c > > > +++ b/tap.c > > > @@ -1026,6 +1026,9 @@ redo: =20 > >=20 > > So.. I just realised there's a different pre-existing problem here, > > above what's quoted in the patch we have: > >=20 > > ssize_t l2len =3D ntohl(*(uint32_t *)p); > >=20 > > On a platform where ssize_t is only 32-bits we could get a negative > > value here, which would be very bad. >=20 > We can't, because the length is anyway limited to the maximum IPv4 path > MTU in any hypervisor we might be talking to. Only if we trust the hypervisor. And that the user didn't misconfigure us to point the socket at something that's not actually a hypervisor. And that it's not some future version of the hypervisor configured to use a different framing format. And that our code is robust enough to never get out of sync on the stream. I really think it's better to read this into a u32, and range sanity check it before we do anything else. > > So l2len should be a uint32_t, not ssize_t. >=20 > True, I can also change that while at it. >=20 > > We do then need to make sure that the comparison between > > l2len and n is unsigned - it's safe to cast n to size_t there, because > > we've verified it's positive as the loop condition. > > > > Or... maybe it's simpler. The frame length is encoded as 32-bits, but > > we can't meaningfully have frames above 64k (maybe 64k+ETH_HLEN). So > > possibly we should just reset the tap connection if we see such a > > frame (most likely it means we've somehow gotten out of sync, anyway). >=20 > I'd rather "fix" type and comparison, for the sake of whatever static > checkers might eventually come up with. >=20 > > > p +=3D sizeof(uint32_t); > > > n -=3D sizeof(uint32_t); =20 > >=20 > >=20 > > > + if (l2len > (ssize_t)TAP_BUF_BYTES - n) =20 > >=20 > > I hate to discard valid frames from the guest. >=20 > That won't happen because of how TAP_BUF_FILL and TAP_BUF_BYTES are > defined. If this condition is true, the length descriptor actually > mismatched. If you have a better proposal, let me know. Hmm.. I'll have a look. > > > + goto next; =20 > >=20 > > ..and this is not safe. This skips (l2len > n) check, which means > > that the n -=3D l2len at next could now have a signed overflow, which is > > UB. >=20 > It's safe because of the change from 3/4, which will just return on > overflow. In any case, yes, I can add a return directly, it's not very > productive to speculate what kind of issues a hypervisor might have, > let's just avoid crashing in case. >=20 > > > + > > > /* At most one packet might not fit in a single read, and this > > > * needs to be blocking. > > > */ =20 > >=20 >=20 --=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 --xqWS7NjZn+uB78uV Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmZ+ZAgACgkQzQJF27ox 2GcllA/+I7O2/uy5lIuyYAMtbk4X0s8uTn+g8YzAFAUhZmMDHbOmGcgje7M+Lr8S yxubRflflBBFAtCE3N+wnopbUuYmnjbEuIySDnbMxwkkjy6vDuK3GDxs0DuIK4fX Ji5Wgw8ojDEYJPR8nnyaszK7AlzpkPJuvlub7kBsqAeQMfuhK9jQeLvu1/LJFH8I //JtkXyKeKIrGPuQVQLK5yXfx1Z1wbYanz87VIfG062oUNNB6bxDLHQjUyXYO89M EMQwY33uk8Mt3uhFLZ0SHm4hS4z1Ekd/WXmxjDuHnB5j8WL6RU+kZxRjczvwqqbh E65tbaAZPFKmwrwwd6XJN4/91r0twrMZs2hMwDeUNI34uFhmiMFwK76ziIpeeBG3 Ueevpl4S9dkSrMuuxFofrZtAwTZX8CmSqNoDIhasOQeFfp7FUn+45kj+U8C3t5qu 4RZYuu8BwDBUU72HcbojyzbKRPvNRfLl6DvBDrDn/BI8CSx8X6Aw9f392bcl/UOT wRiVomI9BFamJlVXx1vDdashihk19wRu8SkGx6XOepcY2wNISXxadO/jzuxoNJAP 628iBkFU326EYilg4ee/TpRJXgTgEh+Ve9jNwmI/jWnETrxbIIC2kzPXdbN8LVDO fqraLEFNotxjnwZvjzEveU1/fc6Nv0pjwmNdgVo/qWfylh1CkaM= =/LWW -----END PGP SIGNATURE----- --xqWS7NjZn+uB78uV--