From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:32946) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bdzsB-0003pt-GR for qemu-devel@nongnu.org; Sun, 28 Aug 2016 09:11:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bdzs7-0001bl-7X for qemu-devel@nongnu.org; Sun, 28 Aug 2016 09:11:38 -0400 Received: from mo6.mail-out.ovh.net ([178.32.228.6]:56813) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bdzs6-0001bg-UU for qemu-devel@nongnu.org; Sun, 28 Aug 2016 09:11:35 -0400 Received: from player786.ha.ovh.net (b7.ovh.net [213.186.33.57]) by mo6.mail-out.ovh.net (Postfix) with ESMTP id 86734FF9804 for ; Sun, 28 Aug 2016 15:11:33 +0200 (CEST) Date: Sun, 28 Aug 2016 15:11:20 +0200 From: Greg Kurz Message-ID: <20160828151120.6acf8ea6@bahia.lan> In-Reply-To: <57C08B78.1040409@redhat.com> References: <147222401281.18925.1894824578752486297.stgit@bahia.lan> <147222402095.18925.396915168302239352.stgit@bahia.lan> <57C08B78.1040409@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/frgp6q6oGljSvjFTwbnCc/x"; protocol="application/pgp-signature" Subject: Re: [Qemu-devel] [PATCH v2 1/5] 9p: forbid illegal path names 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_/frgp6q6oGljSvjFTwbnCc/x Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 26 Aug 2016 13:33:28 -0500 Eric Blake wrote: > On 08/26/2016 10:07 AM, Greg Kurz wrote: > > Empty path components don't make sense and may cause undefined behavior, > > depending on the backend. > >=20 > > Also, the walk request described in the 9P spec [1] clearly shows that > > the client is supposed to send individual path components: the official > > linux client never sends portions of path containing the / character for > > example. > >=20 > > Moreover, the 9P spec [2] also states that a system can decide to restr= ict > > the set of supported characters used in path components, with an explic= it > > mention "to remove slashes from name components". > >=20 > > This patch introduces a new name_is_illegal() helper that checks the > > names sent by the client are not empty and don't contain unwanted chars. > > Since 9pfs is only supported on linux hosts, only the / character is > > checked at the moment. When support for other hosts (AKA. win32) is add= ed, > > other chars may need to be blacklisted as well. > >=20 > > If a client sends an illegal path component, the request will fail and > > EINVAL is returned to the client. > >=20 > > [1] http://man.cat-v.org/plan_9/5/walk > > [2] http://man.cat-v.org/plan_9/5/intro > >=20 > > Suggested-by: Peter Maydell > > Signed-off-by: Greg Kurz > > --- > > hw/9pfs/9p.c | 56 ++++++++++++++++++++++++++++++++++++++++++++++++++= ++++++ > > 1 file changed, 56 insertions(+) > >=20 > > diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c > > index b6b02b46a9da..dba11773699b 100644 > > --- a/hw/9pfs/9p.c > > +++ b/hw/9pfs/9p.c > > @@ -1256,6 +1256,11 @@ static int v9fs_walk_marshal(V9fsPDU *pdu, uint1= 6_t nwnames, V9fsQID *qids) > > return offset; > > } > > =20 > > +static bool name_is_illegal(const char *name) > > +{ > > + return name =3D=3D NULL || strchr(name, '/') !=3D NULL; =20 >=20 > Is anyone actually passing NULL? And the commit message says you are > blacklisting the empty string "", but that is not what you did here. > Depending on whether callers can even pass NULL, you may be able to just > s/name =3D=3D NULL/!*name/ >=20 Oops you're right, v9fs_iov_vunmarshal() always allocates and sets str->dat= a, even for empty strings... so I guess this cannot be call with NULL and your sugg= estion is the way to go. --Sig_/frgp6q6oGljSvjFTwbnCc/x Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlfC4vkACgkQAvw66wEB28Iv2gCeNdqac/FHR2erkh/cQTWbz+kE FI0An2h7ylziQT5cR0doe8bEGrqm1B3n =tyWr -----END PGP SIGNATURE----- --Sig_/frgp6q6oGljSvjFTwbnCc/x--