1. 17 2月, 2011 6 次提交
  2. 15 2月, 2011 6 次提交
    • T
      Btrfs: check return value of alloc_extent_map() · c26a9203
      Tsutomu Itoh 提交于
      I add the check on the return value of alloc_extent_map() to several places.
      In addition, alloc_extent_map() returns only the address or NULL.
      Therefore, check by IS_ERR() is unnecessary. So, I remove IS_ERR() checking.
      Signed-off-by: NTsutomu Itoh <t-itoh@jp.fujitsu.com>
      Signed-off-by: NChris Mason <chris.mason@oracle.com>
      c26a9203
    • I
      Btrfs - Fix memory leak in btrfs_init_new_device() · 67100f25
      Ilya Dryomov 提交于
      Memory allocated by calling kstrdup() should be freed.
      Signed-off-by: NIlya Dryomov <idryomov@gmail.com>
      Signed-off-by: NChris Mason <chris.mason@oracle.com>
      67100f25
    • D
      btrfs: prevent heap corruption in btrfs_ioctl_space_info() · 51788b1b
      Dan Rosenberg 提交于
      Commit bf5fc093 refactored
      btrfs_ioctl_space_info() and introduced several security issues.
      
      space_args.space_slots is an unsigned 64-bit type controlled by a
      possibly unprivileged caller.  The comparison as a signed int type
      allows providing values that are treated as negative and cause the
      subsequent allocation size calculation to wrap, or be truncated to 0.
      By providing a size that's truncated to 0, kmalloc() will return
      ZERO_SIZE_PTR.  It's also possible to provide a value smaller than the
      slot count.  The subsequent loop ignores the allocation size when
      copying data in, resulting in a heap overflow or write to ZERO_SIZE_PTR.
      
      The fix changes the slot count type and comparison typecast to u64,
      which prevents truncation or signedness errors, and also ensures that we
      don't copy more data than we've allocated in the subsequent loop.  Note
      that zero-size allocations are no longer possible since there is already
      an explicit check for space_args.space_slots being 0 and truncation of
      this value is no longer an issue.
      Signed-off-by: NDan Rosenberg <drosenberg@vsecurity.com>
      Signed-off-by: NJosef Bacik <josef@redhat.com>
      Reviewed-by: NJosef Bacik <josef@redhat.com>
      Signed-off-by: NChris Mason <chris.mason@oracle.com>
      51788b1b
    • Y
      Btrfs: Fix balance panic · 6848ad64
      Yan, Zheng 提交于
      Mark the cloned backref_node as checked in clone_backref_node()
      Signed-off-by: NYan, Zheng <zheng.z.yan@intel.com>
      Signed-off-by: NChris Mason <chris.mason@oracle.com>
      6848ad64
    • C
      Btrfs: don't release pages when we can't clear the uptodate bits · e3f24cc5
      Chris Mason 提交于
      Btrfs tracks uptodate state in an rbtree as well as in the
      page bits.  This is supposed to enable us to use block sizes other than
      the page size, but there are a few parts still missing before that
      completely works.
      
      But, our readpage routine trusts this additional range based tracking
      of uptodateness, much in the same way the buffer head up to date bits
      are trusted for the other filesystems.
      
      The problem is that sometimes we need to allocate memory in order to
      split records in the rbtree, even when we are just clearing bits.  This
      can be difficult when our clearing function is called GFP_ATOMIC, which
      can happen in the releasepage path.
      
      So, what happens today looks like this:
      
      releasepage called with GFP_ATOMIC
      btrfs_releasepage calls clear_extent_bit
      clear_extent_bit fails to allocate ram, leaving the up to date bit set
      btrfs_releasepage returns success
      
      The end result is the page being gone, but btrfs thinking the range is
      up to date.   Later on if someone tries to read that same page, the
      btrfs readpage code will return immediately thinking the page is already
      up to date.
      
      This commit fixes things to fail the releasepage when we can't clear the
      extent state bits.  It covers both data pages and metadata tree blocks.
      Signed-off-by: NChris Mason <chris.mason@oracle.com>
      e3f24cc5
    • C
      Btrfs: fix page->private races · eb14ab8e
      Chris Mason 提交于
      There is a race where btrfs_releasepage can drop the
      page->private contents just as alloc_extent_buffer is setting
      up pages for metadata.  Because of how the Btrfs page flags work,
      this results in us skipping the crc on the page during IO.
      
      This patch sovles the race by waiting until after the extent buffer
      is inserted into the radix tree before it sets page private.
      Signed-off-by: NChris Mason <chris.mason@oracle.com>
      eb14ab8e
  3. 08 2月, 2011 1 次提交
  4. 06 2月, 2011 4 次提交
  5. 01 2月, 2011 5 次提交
  6. 29 1月, 2011 12 次提交
  7. 27 1月, 2011 6 次提交