1. 16 Dec, 2019 2 commits
  2. 15 Dec, 2019 1 commit
  3. 14 Dec, 2019 5 commits
    • yangerkun's avatar
      ext4: reserve revoke credits in __ext4_new_inode · a70fd5ac
      yangerkun authored
      It's possible that __ext4_new_inode will release the xattr block, so
      it will trigger a warning since there is revoke credits will be 0 if
      the handle == NULL. The below scripts can reproduce it easily.
      
      ------------[ cut here ]------------
      WARNING: CPU: 0 PID: 3861 at fs/jbd2/revoke.c:374 jbd2_journal_revoke+0x30e/0x540 fs/jbd2/revoke.c:374
      ...
      __ext4_forget+0x1d7/0x800 fs/ext4/ext4_jbd2.c:248
      ext4_free_blocks+0x213/0x1d60 fs/ext4/mballoc.c:4743
      ext4_xattr_release_block+0x55b/0x780 fs/ext4/xattr.c:1254
      ext4_xattr_block_set+0x1c2c/0x2c40 fs/ext4/xattr.c:2112
      ext4_xattr_set_handle+0xa7e/0x1090 fs/ext4/xattr.c:2384
      __ext4_set_acl+0x54d/0x6c0 fs/ext4/acl.c:214
      ext4_init_acl+0x218/0x2e0 fs/ext4/acl.c:293
      __ext4_new_inode+0x352a/0x42b0 fs/ext4/ialloc.c:1151
      ext4_mkdir+0x2e9/0xbd0 fs/ext4/namei.c:2774
      vfs_mkdir+0x386/0x5f0 fs/namei.c:3811
      do_mkdirat+0x11c/0x210 fs/namei.c:3834
      do_syscall_64+0xa1/0x530 arch/x86/entry/common.c:294
      ...
      -------------------------------------
      
      scripts:
      mkfs.ext4 /dev/vdb
      mount /dev/vdb /mnt
      cd /mnt && mkdir dir && for i in {1..8}; do setfacl -dm "u:user_"$i":rx" dir; done
      mkdir dir/dir1 && mv dir/dir1 ./
      sh repro.sh && add some user
      
      [root@localhost ~]# cat repro.sh
      while [ 1 -eq 1 ]; do
          rm -rf dir
          rm -rf dir1/dir1
          mkdir dir
          for i in {1..8}; do  setfacl -dm "u:test"$i":rx" dir; done
          setfacl -m "u:user_9:rx" dir &
          mkdir dir1/dir1 &
      done
      
      Before exec repro.sh, dir1 has inherit the default acl from dir, and
      xattr block of dir1 dir is not the same, so the h_refcount of these
      two dir's xattr block will be 1. Then repro.sh can trigger the warning
      with the situation show as below. The last h_refcount can be clear
      with mkdir, and __ext4_new_inode has not reserved revoke credits, so
      the warning will happened, fix it by reserve revoke credits in
      __ext4_new_inode.
      
      Thread 1                        Thread 2
      mkdir dir
      set default acl(will create
      a xattr block blk1 and the
      refcount of ext4_xattr_header
      will be 1)
      				...
                                      mkdir dir1/dir1
      				->....->ext4_init_acl
      				->__ext4_set_acl(set default acl,
      			          will reuse blk1, and h_refcount
      				  will be 2)
      
      setfacl->ext4_set_acl->...
      ->ext4_xattr_block_set(will create
      new block blk2 to store xattr)
      
      				->__ext4_set_acl(set access acl, since
      				  h_refcount of blk1 is 2, will create
      				  blk3 to store xattr)
      
        ->ext4_xattr_release_block(dec
        h_refcount of blk1 to 1)
      				  ->ext4_xattr_release_block(dec
      				    h_refcount and since it is 0,
      				    will release the block and trigger
      				    the warning)
      
      Link: https://lore.kernel.org/r/20191213014900.47228-1-yangerkun@huawei.comReported-by: default avatarHulk Robot <hulkci@huawei.com>
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avataryangerkun <yangerkun@huawei.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      a70fd5ac
    • Dan Carpenter's avatar
      ext4: unlock on error in ext4_expand_extra_isize() · 7f420d64
      Dan Carpenter authored
      We need to unlock the xattr before returning on this error path.
      
      Cc: stable@kernel.org # 4.13
      Fixes: c03b45b8 ("ext4, project: expand inode extra size if possible")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Link: https://lore.kernel.org/r/20191213185010.6k7yl2tck3wlsdkt@kili.mountainSigned-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      7f420d64
    • Theodore Ts'o's avatar
      ext4: optimize __ext4_check_dir_entry() · 707d1a2f
      Theodore Ts'o authored
      Make __ext4_check_dir_entry() a bit easier to understand, and reduce
      the object size of the function by over 11%.
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Link: https://lore.kernel.org/r/20191209004346.38526-1-tytso@mit.eduSigned-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      707d1a2f
    • Jan Kara's avatar
      ext4: check for directory entries too close to block end · 109ba779
      Jan Kara authored
      ext4_check_dir_entry() currently does not catch a case when a directory
      entry ends so close to the block end that the header of the next
      directory entry would not fit in the remaining space. This can lead to
      directory iteration code trying to access address beyond end of current
      buffer head leading to oops.
      
      CC: stable@vger.kernel.org
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Link: https://lore.kernel.org/r/20191202170213.4761-3-jack@suse.czSigned-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      109ba779
    • Jan Kara's avatar
      ext4: fix ext4_empty_dir() for directories with holes · 64d4ce89
      Jan Kara authored
      Function ext4_empty_dir() doesn't correctly handle directories with
      holes and crashes on bh->b_data dereference when bh is NULL. Reorganize
      the loop to use 'offset' variable all the times instead of comparing
      pointers to current direntry with bh->b_data pointer. Also add more
      strict checking of '.' and '..' directory entries to avoid entering loop
      in possibly invalid state on corrupted filesystems.
      
      References: CVE-2019-19037
      CC: stable@vger.kernel.org
      Fixes: 4e19d6b6 ("ext4: allow directory holes")
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Link: https://lore.kernel.org/r/20191202170213.4761-2-jack@suse.czSigned-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      64d4ce89
  4. 19 Nov, 2019 3 commits
  5. 15 Nov, 2019 5 commits
  6. 14 Nov, 2019 3 commits
  7. 11 Nov, 2019 1 commit
  8. 05 Nov, 2019 20 commits