From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36398) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1be0Ds-0002Or-GA for qemu-devel@nongnu.org; Sun, 28 Aug 2016 09:34:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1be0Dn-0005T2-Fr for qemu-devel@nongnu.org; Sun, 28 Aug 2016 09:34:04 -0400 Received: from 9.mo6.mail-out.ovh.net ([87.98.171.146]:52740) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1be0Dn-0005Sx-6S for qemu-devel@nongnu.org; Sun, 28 Aug 2016 09:33:59 -0400 Received: from player786.ha.ovh.net (b7.ovh.net [213.186.33.57]) by mo6.mail-out.ovh.net (Postfix) with ESMTP id 05D39FF9803 for ; Sun, 28 Aug 2016 15:33:57 +0200 (CEST) Date: Sun, 28 Aug 2016 15:33:49 +0200 From: Greg Kurz Message-ID: <20160828153349.2c071fcf@bahia.lan> In-Reply-To: <57C08D53.1040604@redhat.com> References: <147222401281.18925.1894824578752486297.stgit@bahia.lan> <147222402890.18925.12890875990211775724.stgit@bahia.lan> <57C08D53.1040604@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/d+vpwv_48i_lRbyac._yDwk"; protocol="application/pgp-signature" Subject: Re: [Qemu-devel] [PATCH v2 2/5] 9p: disallow the NUL character in all strings List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: qemu-devel@nongnu.org, Peter Maydell , Felix Wilhelm , "Michael S. Tsirkin" , P J P , "Aneesh Kumar K.V" --Sig_/d+vpwv_48i_lRbyac._yDwk Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 26 Aug 2016 13:41:23 -0500 Eric Blake wrote: > On 08/26/2016 10:07 AM, Greg Kurz wrote: > > According to the 9P spec at http://man.cat-v.org/plan_9/5/intro : > >=20 > > Data items of larger or variable lengths are represented by a > > two-byte field specifying a count, n, followed by n bytes of > > data. Text strings are represented this way, with the text > > itself stored as a UTF-8 encoded sequence of Unicode charac- > > ters (see utf(6)). Text strings in 9P messages are not NUL- > > terminated: n counts the bytes of UTF-8 data, which include > > no final zero byte. The NUL character is illegal in all > > text strings in 9P, and is therefore excluded from file > > names, user names, and so on. > >=20 > > With this patch, if a 9P client sends a text string containing a NUL > > character, the request will fail and the client is returned EINVAL. > >=20 > > The checking is done in v9fs_iov_vunmarshal() because it is a convenient > > place to check all client originated strings. > >=20 > > Suggested-by: Peter Maydell > > Signed-off-by: Greg Kurz > > --- > > fsdev/9p-iov-marshal.c | 7 ++++++- > > 1 file changed, 6 insertions(+), 1 deletion(-) > >=20 > > diff --git a/fsdev/9p-iov-marshal.c b/fsdev/9p-iov-marshal.c > > index 663cad542900..9bcdc370231d 100644 > > --- a/fsdev/9p-iov-marshal.c > > +++ b/fsdev/9p-iov-marshal.c > > @@ -127,7 +127,12 @@ ssize_t v9fs_iov_vunmarshal(struct iovec *out_sg, = int out_num, size_t offset, > > str->size); > > if (copied > 0) { > > str->data[str->size] =3D 0; > > - } else { > > + /* 9P forbids NUL characters in all text strings */ > > + if (strlen(str->data) !=3D str->size) { =20 >=20 > If this were glibc, we could micro-optimize and do: >=20 > if (rawmemchr(str->data, 0) !=3D str->data + str->size) >=20 > so that strlen() doesn't have to visit the tail end of the string if a > NUL is present early. But your code is just fine as-is, and doesn't Hmmm... if a NUL is present early, why would strlen() visit the tail end of the string ? Looking at the glibc sources (string/strlen.c and string/rawmemchr.c), both= calls share the same implementation: handle initial characters 1 by 1 and then te= st a longword at a time... and FWIW, strlen() knows at compile time it looks for= 0=20 instead of a runtime character for rawmemchr(). I have the feeling that str= len() is the more optimized actually. > have to worry about rawmemchr() being present. >=20 > Reviewed-by: Eric Blake >=20 --Sig_/d+vpwv_48i_lRbyac._yDwk Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlfC6D0ACgkQAvw66wEB28IrAwCfah8005Z09OzxoqCBXdOMlan2 DDMAn3dXn22MhIhyQ1xoLjAy5ab3rMDb =PRAW -----END PGP SIGNATURE----- --Sig_/d+vpwv_48i_lRbyac._yDwk--