[Qemu-commits] [qemu/qemu] dd28fb: 9pfs: add xattrwalk_fid field in V9fsXattr struct

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: dd28fbbc2edc0822965d402d927ce646326d6954
      
https://github.com/qemu/qemu/commit/dd28fbbc2edc0822965d402d927ce646326d6954
  Author: Li Qiang <address@hidden>
  Date:   2016-11-01 (Tue, 01 Nov 2016)

  Changed paths:
    M hw/9pfs/9p.c
    M hw/9pfs/9p.h

  Log Message:
  -----------
  9pfs: add xattrwalk_fid field in V9fsXattr struct

Currently, 9pfs sets the 'copied_len' field in V9fsXattr
to -1 to tag xattr walk fid. As the 'copied_len' is also
used to account for copied bytes, this may make confusion. This patch
add a bool 'xattrwalk_fid' to tag the xattr walk fid.

Suggested-by: Greg Kurz <address@hidden>
Signed-off-by: Li Qiang <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
Signed-off-by: Greg Kurz <address@hidden>


  Commit: 8495f9ad26d398f01e208a53f1a5152483a16084
      
https://github.com/qemu/qemu/commit/8495f9ad26d398f01e208a53f1a5152483a16084
  Author: Li Qiang <address@hidden>
  Date:   2016-11-01 (Tue, 01 Nov 2016)

  Changed paths:
    M hw/9pfs/9p.h

  Log Message:
  -----------
  9pfs: convert 'len/copied_len' field in V9fsXattr to the type of uint64_t

The 'len' in V9fsXattr comes from the 'size' argument in setxattr()
function in guest. The setxattr() function's declaration is this:

int setxattr(const char *path, const char *name,
       const void *value, size_t size, int flags);

and 'size' is treated as u64 in linux kernel client code:

int p9_client_xattrcreate(struct p9_fid *fid, const char *name,
                    u64 attr_size, int flags)

So the 'len' should have an type of 'uint64_t'.
The 'copied_len' in V9fsXattr is used to account for copied bytes, it
should also have an type of 'uint64_t'.

Suggested-by: Greg Kurz <address@hidden>
Signed-off-by: Li Qiang <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
Signed-off-by: Greg Kurz <address@hidden>


  Commit: 7e55d65c56a03dcd2c5d7c49d37c5a74b55d4bd6
      
https://github.com/qemu/qemu/commit/7e55d65c56a03dcd2c5d7c49d37c5a74b55d4bd6
  Author: Li Qiang <address@hidden>
  Date:   2016-11-01 (Tue, 01 Nov 2016)

  Changed paths:
    M hw/9pfs/9p.c

  Log Message:
  -----------
  9pfs: fix integer overflow issue in xattr read/write

The v9fs_xattr_read() and v9fs_xattr_write() are passed a guest
originated offset: they must ensure this offset does not go beyond
the size of the extended attribute that was set in v9fs_xattrcreate().
Unfortunately, the current code implement these checks with unsafe
calculations on 32 and 64 bit values, which may allow a malicious
guest to cause OOB access anyway.

Fix this by comparing the offset and the xattr size, which are
both uint64_t, before trying to compute the effective number of bytes
to read or write.

Suggested-by: Greg Kurz <address@hidden>
Signed-off-by: Li Qiang <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
Reviewed-By: Guido Günther <address@hidden>
Signed-off-by: Greg Kurz <address@hidden>


  Commit: 3b79ef2cf48805dc693a8b0c82e05e0abeaa64f8
      
https://github.com/qemu/qemu/commit/3b79ef2cf48805dc693a8b0c82e05e0abeaa64f8
  Author: Greg Kurz <address@hidden>
  Date:   2016-11-01 (Tue, 01 Nov 2016)

  Changed paths:
    M hw/9pfs/9p.c
    M hw/9pfs/trace-events

  Log Message:
  -----------
  9pfs: limit xattr size in xattrcreate

We shouldn't allow guests to create extended attribute with arbitrary sizes.
On linux hosts, the limit is XATTR_SIZE_MAX. Let's use it.

Signed-off-by: Greg Kurz <address@hidden>


  Commit: dd654e0365c7b70df01920f1fca88dd7089eeb5d
      
https://github.com/qemu/qemu/commit/dd654e0365c7b70df01920f1fca88dd7089eeb5d
  Author: Greg Kurz <address@hidden>
  Date:   2016-11-01 (Tue, 01 Nov 2016)

  Changed paths:
    M hw/9pfs/9p.c

  Log Message:
  -----------
  9pfs: xattrcreate requires non-opened fids

The xattrcreate operation only makes sense on a freshly cloned fid
actually, since any open state would be leaked because of the fid_type
change. This is indeed what the linux kernel client does:

        fid = clone_fid(fid);
        [...]
        retval = p9_client_xattrcreate(fid, name, value_len, flags);

This patch also reverts commit ff55e94d23ae since we are sure that a fid
with type P9_FID_NONE doesn't have a previously allocated xattr.

Signed-off-by: Greg Kurz <address@hidden>


  Commit: 49dd946bb5419681c8668b09a6d10f42bc707b78
      
https://github.com/qemu/qemu/commit/49dd946bb5419681c8668b09a6d10f42bc707b78
  Author: Greg Kurz <address@hidden>
  Date:   2016-11-01 (Tue, 01 Nov 2016)

  Changed paths:
    M hw/9pfs/9p.c

  Log Message:
  -----------
  9pfs: don't BUG_ON() if fid is already opened

A buggy or malicious guest could pass the id of an already opened fid and
cause QEMU to abort. Let's return EINVAL to the guest instead.

Signed-off-by: Greg Kurz <address@hidden>
Reviewed-by: Eric Blake <address@hidden>


  Commit: 79decce35b4d769fa878b048ab1a7b3e9045c9c6
      
https://github.com/qemu/qemu/commit/79decce35b4d769fa878b048ab1a7b3e9045c9c6
  Author: Greg Kurz <address@hidden>
  Date:   2016-11-01 (Tue, 01 Nov 2016)

  Changed paths:
    M hw/9pfs/9p.c

  Log Message:
  -----------
  9pfs: drop excessive error message from virtfs_reset()

The virtfs_reset() function is called either when the virtio-9p device
gets reset, or when the client starts a new 9P session. In both cases,
if it finds fids from a previous session, the following is printed in
the monitor:

9pfs:virtfs_reset: One or more uncluncked fids found during reset

For example, if a linux guest with a mounted 9P share is reset from the
monitor with system_reset, the message will be printed. This is excessive
since these fids are now clunked and the state is clean.

Signed-off-by: Greg Kurz <address@hidden>
Reviewed-by: Eric Blake <address@hidden>


  Commit: 39542105bbb19c690219d2f22844d8dfbd9bba05
      
https://github.com/qemu/qemu/commit/39542105bbb19c690219d2f22844d8dfbd9bba05
  Author: Peter Maydell <address@hidden>
  Date:   2016-11-01 (Tue, 01 Nov 2016)

  Changed paths:
    M hw/9pfs/9p.c
    M hw/9pfs/9p.h
    M hw/9pfs/trace-events

  Log Message:
  -----------
  Merge remote-tracking branch 'remotes/gkurz/tags/for-upstream' into staging

This pull request mostly contains some more fixes to prevent buggy guests from
breaking QEMU.

# gpg: Signature made Tue 01 Nov 2016 11:26:42 GMT
# gpg:                using DSA key 0x02FC3AEB0101DBC2
# gpg: Good signature from "Greg Kurz <address@hidden>"
# gpg:                 aka "Greg Kurz <address@hidden>"
# gpg:                 aka "Greg Kurz <address@hidden>"
# gpg:                 aka "Greg Kurz <address@hidden>"
# gpg:                 aka "Gregory Kurz (Groug) <address@hidden>"
# gpg:                 aka "Gregory Kurz (Cimai Technology) <address@hidden>"
# gpg:                 aka "Gregory Kurz (Meiosys Technology) <address@hidden>"
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg:          There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 2BD4 3B44 535E C0A7 9894  DBA2 02FC 3AEB 0101 DBC2

* remotes/gkurz/tags/for-upstream:
  9pfs: drop excessive error message from virtfs_reset()
  9pfs: don't BUG_ON() if fid is already opened
  9pfs: xattrcreate requires non-opened fids
  9pfs: limit xattr size in xattrcreate
  9pfs: fix integer overflow issue in xattr read/write
  9pfs: convert 'len/copied_len' field in V9fsXattr to the type of uint64_t
  9pfs: add xattrwalk_fid field in V9fsXattr struct

Signed-off-by: Peter Maydell <address@hidden>


Compare: https://github.com/qemu/qemu/compare/38ab359644e7...39542105bbb1