qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Greg Kurz <groug@kaod.org>
To: qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Stefan Hajnoczi <stefanha@redhat.com>, Greg Kurz <groug@kaod.org>
Subject: [Qemu-devel] [PULL 04/11] 9pfs: local: fix unlink of alien files in mapped-file mode
Date: Mon, 29 May 2017 11:05:33 +0200	[thread overview]
Message-ID: <1496048740-26578-5-git-send-email-groug@kaod.org> (raw)
In-Reply-To: <1496048740-26578-1-git-send-email-groug@kaod.org>

When trying to remove a file from a directory, both created in non-mapped
mode, the file remains and EBADF is returned to the guest.

This is a regression introduced by commit "df4938a6651b 9pfs: local:
unlinkat: don't follow symlinks" when fixing CVE-2016-9602. It changed the
way we unlink the metadata file from

    ret = remove("$dir/.virtfs_metadata/$name");
    if (ret < 0 && errno != ENOENT) {
         /* Error out */
    }
    /* Ignore absence of metadata */

to

    fd = openat("$dir/.virtfs_metadata")
    unlinkat(fd, "$name")
    if (ret < 0 && errno != ENOENT) {
         /* Error out */
    }
    /* Ignore absence of metadata */

If $dir was created in non-mapped mode, openat() fails with ENOENT and
we pass -1 to unlinkat(), which fails in turn with EBADF.

We just need to check the return of openat() and ignore ENOENT, in order
to restore the behaviour we had with remove().

Signed-off-by: Greg Kurz <groug@kaod.org>
Reviewed-by: Eric Blake <eblake@redhat.com>
[groug: rewrote the comments as suggested by Eric]
---
 hw/9pfs/9p-local.c | 34 +++++++++++++++-------------------
 1 file changed, 15 insertions(+), 19 deletions(-)

diff --git a/hw/9pfs/9p-local.c b/hw/9pfs/9p-local.c
index a2486566afb7..226234d38642 100644
--- a/hw/9pfs/9p-local.c
+++ b/hw/9pfs/9p-local.c
@@ -992,6 +992,14 @@ static int local_unlinkat_common(FsContext *ctx, int dirfd, const char *name,
     if (ctx->export_flags & V9FS_SM_MAPPED_FILE) {
         int map_dirfd;
 
+        /* We need to remove the metadata as well:
+         * - the metadata directory if we're removing a directory
+         * - the metadata file in the parent's metadata directory
+         *
+         * If any of these are missing (ie, ENOENT) then we're probably
+         * trying to remove something that wasn't created in mapped-file
+         * mode. We just ignore the error.
+         */
         if (flags == AT_REMOVEDIR) {
             int fd;
 
@@ -999,32 +1007,20 @@ static int local_unlinkat_common(FsContext *ctx, int dirfd, const char *name,
             if (fd == -1) {
                 goto err_out;
             }
-            /*
-             * If directory remove .virtfs_metadata contained in the
-             * directory
-             */
             ret = unlinkat(fd, VIRTFS_META_DIR, AT_REMOVEDIR);
             close_preserve_errno(fd);
             if (ret < 0 && errno != ENOENT) {
-                /*
-                 * We didn't had the .virtfs_metadata file. May be file created
-                 * in non-mapped mode ?. Ignore ENOENT.
-                 */
                 goto err_out;
             }
         }
-        /*
-         * Now remove the name from parent directory
-         * .virtfs_metadata directory.
-         */
         map_dirfd = openat_dir(dirfd, VIRTFS_META_DIR);
-        ret = unlinkat(map_dirfd, name, 0);
-        close_preserve_errno(map_dirfd);
-        if (ret < 0 && errno != ENOENT) {
-            /*
-             * We didn't had the .virtfs_metadata file. May be file created
-             * in non-mapped mode ?. Ignore ENOENT.
-             */
+        if (map_dirfd != -1) {
+            ret = unlinkat(map_dirfd, name, 0);
+            close_preserve_errno(map_dirfd);
+            if (ret < 0 && errno != ENOENT) {
+                goto err_out;
+            }
+        } else if (errno != ENOENT) {
             goto err_out;
         }
     }
-- 
2.7.4

  parent reply	other threads:[~2017-05-29  9:06 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-29  9:05 [Qemu-devel] [PULL 00/11] 9pfs patches for 2.10 20170525 Greg Kurz
2017-05-29  9:05 ` [Qemu-devel] [PULL 01/11] virtio-9p/xen-9p: move 9p specific bits to core 9p code Greg Kurz
2017-05-29  9:05 ` [Qemu-devel] [PULL 02/11] fsdev: don't allow unknown format in marshal/unmarshal Greg Kurz
2017-05-29  9:05 ` [Qemu-devel] [PULL 03/11] 9pfs: drop pdu_push_and_notify() Greg Kurz
2017-05-29  9:05 ` Greg Kurz [this message]
2017-05-29  9:05 ` [Qemu-devel] [PULL 05/11] fsdev: fix virtfs-proxy-helper cwd Greg Kurz
2017-05-29  9:05 ` [Qemu-devel] [PULL 06/11] 9pfs: assume utimensat() and futimens() are present Greg Kurz
2017-05-29  9:05 ` [Qemu-devel] [PULL 07/11] util: drop old utimensat() compat code Greg Kurz
2017-05-29  9:05 ` [Qemu-devel] [PULL 08/11] 9pfs: check return value of v9fs_co_name_to_path() Greg Kurz
2017-05-29  9:05 ` [Qemu-devel] [PULL 09/11] 9pfs: local: resolve special directories in paths Greg Kurz
2017-05-29  9:05 ` [Qemu-devel] [PULL 10/11] 9pfs: local: simplify file opening Greg Kurz
2017-05-29  9:05 ` [Qemu-devel] [PULL 11/11] 9pfs: local: metadata file for the VirtFS root Greg Kurz
2017-05-29  9:19 ` [Qemu-devel] [PULL 00/11] 9pfs patches for 2.10 20170525 no-reply
2017-05-30  9:42 ` Stefan Hajnoczi
2017-05-30 10:21   ` Greg Kurz
2017-05-30 10:26     ` Daniel P. Berrange
2017-05-30 10:33       ` Greg Kurz
2017-05-30 10:50         ` Fam Zheng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1496048740-26578-5-git-send-email-groug@kaod.org \
    --to=groug@kaod.org \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).