An error occurred fetching the project authors.
  1. 23 Apr, 2024 6 commits
  2. 15 Apr, 2024 2 commits
  3. 22 Feb, 2024 6 commits
  4. 10 Aug, 2023 1 commit
  5. 17 Jul, 2023 1 commit
    • Darrick J. Wong's avatar
      xfs: convert flex-array declarations in struct xfs_attrlist* · 371baf5c
      Darrick J. Wong authored
      As of 6.5-rc1, UBSAN trips over the attrlist ioctl definitions using an
      array length of 1 to pretend to be a flex array.  Kernel compilers have
      to support unbounded array declarations, so let's correct this.  This
      may cause friction with userspace header declarations, but suck is life.
      
      ================================================================================
      UBSAN: array-index-out-of-bounds in fs/xfs/xfs_ioctl.c:345:18
      index 1 is out of range for type '__s32 [1]'
      Call Trace:
       <TASK>
       dump_stack_lvl+0x33/0x50
       __ubsan_handle_out_of_bounds+0x9c/0xd0
       xfs_ioc_attr_put_listent+0x413/0x420 [xfs 4a986a89a77bb77402ab8a87a37da369ef6a3f09]
       xfs_attr_list_ilocked+0x170/0x850 [xfs 4a986a89a77bb77402ab8a87a37da369ef6a3f09]
       xfs_attr_list+0xb7/0x120 [xfs 4a986a89a77bb77402ab8a87a37da369ef6a3f09]
       xfs_ioc_attr_list+0x13b/0x2e0 [xfs 4a986a89a77bb77402ab8a87a37da369ef6a3f09]
       xfs_attrlist_by_handle+0xab/0x120 [xfs 4a986a89a77bb77402ab8a87a37da369ef6a3f09]
       xfs_file_ioctl+0x1ff/0x15e0 [xfs 4a986a89a77bb77402ab8a87a37da369ef6a3f09]
       vfs_ioctl+0x1f/0x60
      
      The kernel and xfsprogs code that uses these structures will not have
      problems, but the long tail of external user programs might.
      Signed-off-by: default avatarDarrick J. Wong <djwong@kernel.org>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      371baf5c
  6. 13 Jun, 2023 1 commit
    • Long Li's avatar
      xfs: fix ag count overflow during growfs · c3b880ac
      Long Li authored
      I found a corruption during growfs:
      
       XFS (loop0): Internal error agbno >= mp->m_sb.sb_agblocks at line 3661 of
         file fs/xfs/libxfs/xfs_alloc.c.  Caller __xfs_free_extent+0x28e/0x3c0
       CPU: 0 PID: 573 Comm: xfs_growfs Not tainted 6.3.0-rc7-next-20230420-00001-gda8c95746257
       Call Trace:
        <TASK>
        dump_stack_lvl+0x50/0x70
        xfs_corruption_error+0x134/0x150
        __xfs_free_extent+0x2c1/0x3c0
        xfs_ag_extend_space+0x291/0x3e0
        xfs_growfs_data+0xd72/0xe90
        xfs_file_ioctl+0x5f9/0x14a0
        __x64_sys_ioctl+0x13e/0x1c0
        do_syscall_64+0x39/0x80
        entry_SYSCALL_64_after_hwframe+0x63/0xcd
       XFS (loop0): Corruption detected. Unmount and run xfs_repair
       XFS (loop0): Internal error xfs_trans_cancel at line 1097 of file
         fs/xfs/xfs_trans.c.  Caller xfs_growfs_data+0x691/0xe90
       CPU: 0 PID: 573 Comm: xfs_growfs Not tainted 6.3.0-rc7-next-20230420-00001-gda8c95746257
       Call Trace:
        <TASK>
        dump_stack_lvl+0x50/0x70
        xfs_error_report+0x93/0xc0
        xfs_trans_cancel+0x2c0/0x350
        xfs_growfs_data+0x691/0xe90
        xfs_file_ioctl+0x5f9/0x14a0
        __x64_sys_ioctl+0x13e/0x1c0
        do_syscall_64+0x39/0x80
        entry_SYSCALL_64_after_hwframe+0x63/0xcd
       RIP: 0033:0x7f2d86706577
      
      The bug can be reproduced with the following sequence:
      
       # truncate -s  1073741824 xfs_test.img
       # mkfs.xfs -f -b size=1024 -d agcount=4 xfs_test.img
       # truncate -s 2305843009213693952  xfs_test.img
       # mount -o loop xfs_test.img /mnt/test
       # xfs_growfs -D  1125899907891200  /mnt/test
      
      The root cause is that during growfs, user space passed in a large value
      of newblcoks to xfs_growfs_data_private(), due to current sb_agblocks is
      too small, new AG count will exceed UINT_MAX. Because of AG number type
      is unsigned int and it would overflow, that caused nagcount much smaller
      than the actual value. During AG extent space, delta blocks in
      xfs_resizefs_init_new_ags() will much larger than the actual value due to
      incorrect nagcount, even exceed UINT_MAX. This will cause corruption and
      be detected in __xfs_free_extent. Fix it by growing the filesystem to up
      to the maximally allowed AGs and not return EINVAL when new AG count
      overflow.
      Signed-off-by: default avatarLong Li <leo.lilong@huawei.com>
      Reviewed-by: default avatarDarrick J. Wong <djwong@kernel.org>
      Signed-off-by: default avatarDarrick J. Wong <djwong@kernel.org>
      c3b880ac
  7. 21 Apr, 2022 1 commit
  8. 13 Apr, 2022 1 commit
  9. 11 Apr, 2022 1 commit
  10. 17 Jan, 2022 2 commits
  11. 19 Oct, 2021 1 commit
  12. 20 May, 2021 1 commit
  13. 12 Apr, 2021 1 commit
  14. 07 Apr, 2021 1 commit
  15. 03 Feb, 2021 1 commit
  16. 16 Sep, 2020 1 commit
  17. 13 May, 2020 1 commit
  18. 03 Mar, 2020 2 commits
  19. 13 Nov, 2019 1 commit
    • Arnd Bergmann's avatar
      xfs: avoid time_t in user api · e8777b27
      Arnd Bergmann authored
      The ioctl definitions for XFS_IOC_SWAPEXT, XFS_IOC_FSBULKSTAT and
      XFS_IOC_FSBULKSTAT_SINGLE are part of libxfs and based on time_t.
      
      The definition for time_t differs between current kernels and coming
      32-bit libc variants that define it as 64-bit. For most ioctls, that
      means the kernel has to be able to handle two different command codes
      based on the different structure sizes.
      
      The same solution could be applied for XFS_IOC_SWAPEXT, but it would
      not work for XFS_IOC_FSBULKSTAT and XFS_IOC_FSBULKSTAT_SINGLE because
      the structure with the time_t is passed through an indirect pointer,
      and the command number itself is based on struct xfs_fsop_bulkreq,
      which does not differ based on time_t.
      
      This means any solution that can be applied requires a change of the
      ABI definition in the xfs_fs.h header file, as well as doing the same
      change in any user application that contains a copy of this header.
      
      The usual solution would be to define a replacement structure and
      use conditional compilation for the ioctl command codes to use
      one or the other, such as
      
       #define XFS_IOC_FSBULKSTAT_OLD _IOWR('X', 101, struct xfs_fsop_bulkreq)
       #define XFS_IOC_FSBULKSTAT_NEW _IOWR('X', 129, struct xfs_fsop_bulkreq)
       #define XFS_IOC_FSBULKSTAT ((sizeof(time_t) == sizeof(__kernel_long_t)) ? \
      			     XFS_IOC_FSBULKSTAT_OLD : XFS_IOC_FSBULKSTAT_NEW)
      
      After this, the kernel would be able to implement both
      XFS_IOC_FSBULKSTAT_OLD and XFS_IOC_FSBULKSTAT_NEW handlers on
      32-bit architectures with the correct ABI for either definition
      of time_t.
      
      However, as long as two observations are true, a much simpler solution
      can be used:
      
      1. xfsprogs is the only user space project that has a copy of this header
      2. xfsprogs already has a replacement for all three affected ioctl commands,
         based on the xfs_bulkstat structure to pass 64-bit timestamps
         regardless of the architecture
      
      Based on those assumptions, changing xfs_bstime to use __kernel_long_t
      instead of time_t in both the kernel and in xfsprogs preserves the current
      ABI for any libc definition of time_t and solves the problem of passing
      64-bit timestamps to 32-bit user space.
      
      If either of the two assumptions is invalid, more discussion is needed
      for coming up with a way to fix as much of the affected user space
      code as possible.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      e8777b27
  20. 10 Nov, 2019 1 commit
  21. 15 Oct, 2019 1 commit
  22. 04 Sep, 2019 1 commit
  23. 04 Jul, 2019 5 commits