1. 11 Dec, 2018 1 commit
  2. 10 Dec, 2018 1 commit
    • Takeshi Misawa's avatar
      fuse: Fix memory leak in fuse_dev_free() · d72f70da
      Takeshi Misawa authored
      
      
      When ntfs is unmounted, the following leak is
      reported by kmemleak.
      
      kmemleak report:
      
      unreferenced object 0xffff880052bf4400 (size 4096):
        comm "mount.ntfs", pid 16530, jiffies 4294861127 (age 3215.836s)
        hex dump (first 32 bytes):
          00 44 bf 52 00 88 ff ff 00 44 bf 52 00 88 ff ff  .D.R.....D.R....
          10 44 bf 52 00 88 ff ff 10 44 bf 52 00 88 ff ff  .D.R.....D.R....
        backtrace:
          [<00000000bf4a2f8d>] fuse_fill_super+0xb22/0x1da0 [fuse]
          [<000000004dde0f0c>] mount_bdev+0x263/0x320
          [<0000000025aebc66>] mount_fs+0x82/0x2bf
          [<0000000042c5a6be>] vfs_kern_mount.part.33+0xbf/0x480
          [<00000000ed10cd5b>] do_mount+0x3de/0x2ad0
          [<00000000d59ff068>] ksys_mount+0xba/0xd0
          [<000000001bda1bcc>] __x64_sys_mount+0xba/0x150
          [<00000000ebe26304>] do_syscall_64+0x151/0x490
          [<00000000d25f2b42>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
          [<000000002e0abd2c>] 0xffffffffffffffff
      
      fuse_dev_alloc() allocate fud->pq.processing.
      But this hash table is not freed.
      
      Fix this by freeing fud->pq.processing.
      Signed-off-by: default avatarTakeshi Misawa <jeliantsurux@gmail.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      Fixes: be2ff42c ("fuse: Use hash table to link processing request")
      d72f70da
  3. 03 Dec, 2018 2 commits
  4. 22 Nov, 2018 1 commit
    • Myungho Jung's avatar
      fuse: Add bad inode check in fuse_destroy_inode() · 4fc4bb79
      Myungho Jung authored
      make_bad_inode() sets inode->i_mode to S_IFREG if I/O error is detected
      in fuse_do_getattr()/fuse_do_setattr(). If the inode is not a regular
      file, write_files and queued_writes in fuse_inode are not initialized
      and have NULL or invalid pointers written by other members in a union.
      So, list_empty() returns false in fuse_destroy_inode(). Add
      is_bad_inode() to check if make_bad_inode() was called.
      
      Reported-by: syzbot+b9c89b84423073226299@syzkaller.appspotmail.com
      Fixes: ab2257e9
      
       ("fuse: reduce size of struct fuse_inode")
      Signed-off-by: default avatarMyungho Jung <mhjungk@gmail.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      4fc4bb79
  5. 18 Nov, 2018 2 commits
  6. 16 Nov, 2018 1 commit
  7. 13 Nov, 2018 1 commit
  8. 12 Nov, 2018 3 commits
  9. 09 Nov, 2018 6 commits
    • Vasily Averin's avatar
      ext4: missing !bh check in ext4_xattr_inode_write() · eb6984fa
      Vasily Averin authored
      According to Ted Ts'o ext4_getblk() called in ext4_xattr_inode_write()
      should not return bh = NULL
      
      The only time that bh could be NULL, then, would be in the case of
      something really going wrong; a programming error elsewhere (perhaps a
      wild pointer dereference) or I/O error causing on-disk file system
      corruption (although that would be highly unlikely given that we had
      *just* allocated the blocks and so the metadata blocks in question
      probably would still be in the cache).
      
      Fixes: e50e5129
      
       ("ext4: xattr-in-inode support")
      Signed-off-by: default avatarVasily Averin <vvs@virtuozzo.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Cc: stable@kernel.org # 4.13
      eb6984fa
    • Lukas Czerner's avatar
      fuse: fix use-after-free in fuse_direct_IO() · ebacb812
      Lukas Czerner authored
      
      
      In async IO blocking case the additional reference to the io is taken for
      it to survive fuse_aio_complete(). In non blocking case this additional
      reference is not needed, however we still reference io to figure out
      whether to wait for completion or not. This is wrong and will lead to
      use-after-free. Fix it by storing blocking information in separate
      variable.
      
      This was spotted by KASAN when running generic/208 fstest.
      Signed-off-by: default avatarLukas Czerner <lczerner@redhat.com>
      Reported-by: default avatarZorro Lang <zlang@redhat.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      Fixes: 744742d6 ("fuse: Add reference counting for fuse_io_priv")
      Cc: <stable@vger.kernel.org> # v4.6
      ebacb812
    • Miklos Szeredi's avatar
      fuse: fix possibly missed wake-up after abort · 2d84a2d1
      Miklos Szeredi authored
      
      
      In current fuse_drop_waiting() implementation it's possible that
      fuse_wait_aborted() will not be woken up in the unlikely case that
      fuse_abort_conn() + fuse_wait_aborted() runs in between checking
      fc->connected and calling atomic_dec(&fc->num_waiting).
      
      Do the atomic_dec_and_test() unconditionally, which also provides the
      necessary barrier against reordering with the fc->connected check.
      
      The explicit smp_mb() in fuse_wait_aborted() is not actually needed, since
      the spin_unlock() in fuse_abort_conn() provides the necessary RELEASE
      barrier after resetting fc->connected.  However, this is not a performance
      sensitive path, and adding the explicit barrier makes it easier to
      document.
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      Fixes: b8f95e5d ("fuse: umount should wait for all requests")
      Cc: <stable@vger.kernel.org> #v4.19
      2d84a2d1
    • Miklos Szeredi's avatar
      fuse: fix leaked notify reply · 7fabaf30
      Miklos Szeredi authored
      fuse_request_send_notify_reply() may fail if the connection was reset for
      some reason (e.g. fs was unmounted).  Don't leak request reference in this
      case.  Besides leaking memory, this resulted in fc->num_waiting not being
      decremented and hence fuse_wait_aborted() left in a hanging and unkillable
      state.
      
      Fixes: 2d45ba38 ("fuse: add retrieve request")
      Fixes: b8f95e5d
      
       ("fuse: umount should wait for all requests")
      Reported-and-tested-by: syzbot+6339eda9cb4ebbc4c37b@syzkaller.appspotmail.com
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      Cc: <stable@vger.kernel.org> #v2.6.36
      7fabaf30
    • Andreas Gruenbacher's avatar
      gfs2: Fix metadata read-ahead during truncate (2) · e7445ced
      Andreas Gruenbacher authored
      The previous attempt to fix for metadata read-ahead during truncate was
      incorrect: for files with a height > 2 (1006989312 bytes with a block
      size of 4096 bytes), read-ahead requests were not being issued for some
      of the indirect blocks discovered while walking the metadata tree,
      leading to significant slow-downs when deleting large files.  Fix that.
      
      In addition, only issue read-ahead requests in the first pass through
      the meta-data tree, while deallocating data blocks.
      
      Fixes: c3ce5aa9
      
       ("gfs2: Fix metadata read-ahead during truncate")
      Cc: stable@vger.kernel.org # v4.16+
      Signed-off-by: default avatarAndreas Gruenbacher <agruenba@redhat.com>
      e7445ced
    • Andreas Gruenbacher's avatar
      gfs2: Put bitmap buffers in put_super · 10283ea5
      Andreas Gruenbacher authored
      gfs2_put_super calls gfs2_clear_rgrpd to destroy the gfs2_rgrpd objects
      attached to the resource group glocks.  That function should release the
      buffers attached to the gfs2_bitmap objects (bi_bh), but the call to
      gfs2_rgrp_brelse for doing that is missing.
      
      When gfs2_releasepage later runs across these buffers which are still
      referenced, it refuses to free them.  This causes the pages the buffers
      are attached to to remain referenced as well.  With enough mount/unmount
      cycles, the system will eventually run out of memory.
      
      Fix this by adding the missing call to gfs2_rgrp_brelse in
      gfs2_clear_rgrpd.
      
      (Also fix a gfs2_rgrp_relse -> gfs2_rgrp_brelse typo in a comment.)
      
      Fixes: 39b0f1e9
      
       ("GFS2: Don't brelse rgrp buffer_heads every allocation")
      Cc: stable@vger.kernel.org # v4.2+
      Signed-off-by: default avatarAndreas Gruenbacher <agruenba@redhat.com>
      10283ea5
  10. 08 Nov, 2018 9 commits
    • Scott Mayhew's avatar
      nfsd: COPY and CLONE operations require the saved filehandle to be set · 01310bb7
      Scott Mayhew authored
      
      
      Make sure we have a saved filehandle, otherwise we'll oops with a null
      pointer dereference in nfs4_preprocess_stateid_op().
      Signed-off-by: default avatarScott Mayhew <smayhew@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      01310bb7
    • Ilya Dryomov's avatar
      libceph: assume argonaut on the server side · 23c625ce
      Ilya Dryomov authored
      
      
      No one is running pre-argonaut.  In addition one of the argonaut
      features (NOSRCADDR) has been required since day one (and a half,
      2.6.34 vs 2.6.35) of the kernel client.
      
      Allow for the possibility of reusing these feature bits later.
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Reviewed-by: default avatarSage Weil <sage@redhat.com>
      23c625ce
    • Luis Henriques's avatar
      ceph: quota: fix null pointer dereference in quota check · 71f2cc64
      Luis Henriques authored
      This patch fixes a possible null pointer dereference in
      check_quota_exceeded, detected by the static checker smatch, with the
      following warning:
      
         fs/ceph/quota.c:240 check_quota_exceeded()
          error: we previously assumed 'realm' could be null (see line 188)
      
      Fixes: b7a29217
      
       ("ceph: quota: support for ceph.quota.max_files")
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarLuis Henriques <lhenriques@suse.com>
      Reviewed-by: default avatar"Yan, Zheng" <zyan@redhat.com>
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      71f2cc64
    • Luis Henriques's avatar
      ceph: add destination file data sync before doing any remote copy · c2c6d3ce
      Luis Henriques authored
      If we try to copy into a file that was just written, any data that is
      remote copied will be overwritten by our buffered writes once they are
      flushed.  When this happens, the call to invalidate_inode_pages2_range
      will also return a -EBUSY error.
      
      This patch fixes this by also sync'ing the destination file before
      starting any copy.
      
      Fixes: 503f82a9
      
       ("ceph: support copy_file_range file operation")
      Signed-off-by: default avatarLuis Henriques <lhenriques@suse.com>
      Reviewed-by: default avatar"Yan, Zheng" <zyan@redhat.com>
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      c2c6d3ce
    • Amir Goldstein's avatar
      fanotify: fix handling of events on child sub-directory · b469e7e4
      Amir Goldstein authored
      
      
      When an event is reported on a sub-directory and the parent inode has
      a mark mask with FS_EVENT_ON_CHILD|FS_ISDIR, the event will be sent to
      fsnotify() even if the event type is not in the parent mark mask
      (e.g. FS_OPEN).
      
      Further more, if that event happened on a mount or a filesystem with
      a mount/sb mark that does have that event type in their mask, the "on
      child" event will be reported on the mount/sb mark.  That is not
      desired, because user will get a duplicate event for the same action.
      
      Note that the event reported on the victim inode is never merged with
      the event reported on the parent inode, because of the check in
      should_merge(): old_fsn->inode == new_fsn->inode.
      
      Fix this by looking for a match of an actual event type (i.e. not just
      FS_ISDIR) in parent's inode mark mask and by not reporting an "on child"
      event to group if event type is only found on mount/sb marks.
      
      [backport hint: The bug seems to have always been in fanotify, but this
                      patch will only apply cleanly to v4.19.y]
      
      Cc: <stable@vger.kernel.org> # v4.19
      Signed-off-by: default avatarAmir Goldstein <amir73il@gmail.com>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      b469e7e4
    • Eric W. Biederman's avatar
      mount: Prevent MNT_DETACH from disconnecting locked mounts · 9c8e0a1b
      Eric W. Biederman authored
      Timothy Baldwin <timbaldwin@fastmail.co.uk> wrote:
      > As per mount_namespaces(7) unprivileged users should not be able to look under mount points:
      >
      >   Mounts that come as a single unit from more privileged mount are locked
      >   together and may not be separated in a less privileged mount namespace.
      >
      > However they can:
      >
      > 1. Create a mount namespace.
      > 2. In the mount namespace open a file descriptor to the parent of a mount point.
      > 3. Destroy the mount namespace.
      > 4. Use the file descriptor to look under the mount point.
      >
      > I have reproduced this with Linux 4.16.18 and Linux 4.18-rc8.
      >
      > The setup:
      >
      > $ sudo sysctl kernel.unprivileged_userns_clone=1
      > kernel.unprivileged_userns_clone = 1
      > $ mkdir -p A/B/Secret
      > $ sudo mount -t tmpfs hide A/B
      >
      >
      > "Secret" is indeed hidden as expected:
      >
      > $ ls -lR A
      > A:
      > total 0
      > drwxrwxrwt 2 root root 40 Feb 12 21:08 B
      >
      > A/B:
      > total 0
      >
      >
      > The attack revealing "Secret":
      >
      > $ unshare -Umr sh -c "exec unshare -m ls -lR /proc/self/fd/4/ 4<A"
      > /proc/self/fd/4/:
      > total 0
      > drwxr-xr-x 3 root root 60 Feb 12 21:08 B
      >
      > /proc/self/fd/4/B:
      > total 0
      > drwxr-xr-x 2 root root 40 Feb 12 21:08 Secret
      >
      > /proc/self/fd/4/B/Secret:
      > total 0
      
      I tracked this down to put_mnt_ns running passing UMOUNT_SYNC and
      disconnecting all of the mounts in a mount namespace.  Fix this by
      factoring drop_mounts out of drop_collected_mounts and passing
      0 instead of UMOUNT_SYNC.
      
      There are two possible behavior differences that result from this.
      - No longer setting UMOUNT_SYNC will no longer set MNT_SYNC_UMOUNT on
        the vfsmounts being unmounted.  This effects the lazy rcu walk by
        kicking the walk out of rcu mode and forcing it to be a non-lazy
        walk.
      - No longer disconnecting locked mounts will keep some mounts around
        longer as they stay because the are locked to other mounts.
      
      There are only two users of drop_collected mounts: audit_tree.c and
      put_mnt_ns.
      
      In audit_tree.c the mounts are private and there are no rcu lazy walks
      only calls to iterate_mounts. So the changes should have no effect
      except for a small timing effect as the connected mounts are disconnected.
      
      In put_mnt_ns there may be references from process outside the mount
      namespace to the mounts.  So the mounts remaining connected will
      be the bug fix that is needed.  That rcu walks are allowed to continue
      appears not to be a problem especially as the rcu walk change was about
      an implementation detail not about semantics.
      
      Cc: stable@vger.kernel.org
      Fixes: 5ff9d8a6
      
       ("vfs: Lock in place mounts from more privileged users")
      Reported-by: default avatarTimothy Baldwin <timbaldwin@fastmail.co.uk>
      Tested-by: default avatarTimothy Baldwin <timbaldwin@fastmail.co.uk>
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      9c8e0a1b
    • Eric W. Biederman's avatar
      mount: Don't allow copying MNT_UNBINDABLE|MNT_LOCKED mounts · df7342b2
      Eric W. Biederman authored
      Jonathan Calmels from NVIDIA reported that he's able to bypass the
      mount visibility security check in place in the Linux kernel by using
      a combination of the unbindable property along with the private mount
      propagation option to allow a unprivileged user to see a path which
      was purposefully hidden by the root user.
      
      Reproducer:
        # Hide a path to all users using a tmpfs
        root@castiana:~# mount -t tmpfs tmpfs /sys/devices/
        root@castiana:~#
      
        # As an unprivileged user, unshare user namespace and mount namespace
        stgraber@castiana:~$ unshare -U -m -r
      
        # Confirm the path is still not accessible
        root@castiana:~# ls /sys/devices/
      
        # Make /sys recursively unbindable and private
        root@castiana:~# mount --make-runbindable /sys
        root@castiana:~# mount --make-private /sys
      
        # Recursively bind-mount the rest of /sys over to /mnnt
        root@castiana:~# mount --rbind /sys/ /mnt
      
        # Access our hidden /sys/device as an unprivileged user
        root@castiana:~# ls /mnt/devices/
        breakpoint cpu cstate_core cstate_pkg i915 intel_pt isa kprobe
        LNXSYSTM:00 msr pci0000:00 platform pnp0 power software system
        tracepoint uncore_arb uncore_cbox_0 uncore_cbox_1 uprobe virtual
      
      Solve this by teaching copy_tree to fail if a mount turns out to be
      both unbindable and locked.
      
      Cc: stable@vger.kernel.org
      Fixes: 5ff9d8a6
      
       ("vfs: Lock in place mounts from more privileged users")
      Reported-by: default avatarJonathan Calmels <jcalmels@nvidia.com>
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      df7342b2
    • Eric W. Biederman's avatar
      mount: Retest MNT_LOCKED in do_umount · 25d202ed
      Eric W. Biederman authored
      
      
      It was recently pointed out that the one instance of testing MNT_LOCKED
      outside of the namespace_sem is in ksys_umount.
      
      Fix that by adding a test inside of do_umount with namespace_sem and
      the mount_lock held.  As it helps to fail fails the existing test is
      maintained with an additional comment pointing out that it may be racy
      because the locks are not held.
      
      Cc: stable@vger.kernel.org
      Reported-by: default avatarAl Viro <viro@ZenIV.linux.org.uk>
      Fixes: 5ff9d8a6
      
       ("vfs: Lock in place mounts from more privileged users")
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      25d202ed
    • Vasily Averin's avatar
      ext4: fix buffer leak in __ext4_read_dirblock() on error path · de59fae0
      Vasily Averin authored
      Fixes: dc6982ff
      
       ("ext4: refactor code to read directory blocks ...")
      Signed-off-by: default avatarVasily Averin <vvs@virtuozzo.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Cc: stable@kernel.org # 3.9
      de59fae0
  11. 07 Nov, 2018 7 commits
  12. 06 Nov, 2018 6 commits