17 Jan, 2019

5 commits

  • commit 95cb67138746451cc84cf8e516e14989746e93b0 upstream.

    We already using mapping_set_error() in fs/ext4/page_io.c, so all we
    need to do is to use file_check_and_advance_wb_err() when handling
    fsync() requests in ext4_sync_file().

    Signed-off-by: Theodore Ts'o
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman

    Theodore Ts'o
     
  • commit ad211f3e94b314a910d4af03178a0b52a7d1ee0a upstream.

    In no-journal mode, we previously used __generic_file_fsync() in
    no-journal mode. This triggers a lockdep warning, and in addition,
    it's not safe to depend on the inode writeback mechanism in the case
    ext4. We can solve both problems by calling ext4_write_inode()
    directly.

    Signed-off-by: Theodore Ts'o
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman

    Theodore Ts'o
     
  • commit e86807862e6880809f191c4cea7f88a489f0ed34 upstream.

    The xfstests generic/475 test switches the underlying device with
    dm-error while running a stress test. This results in a large number
    of file system errors, and since we can't lock the buffer head when
    marking the superblock dirty in the ext4_grp_locked_error() case, it's
    possible the superblock to be !buffer_uptodate() without
    buffer_write_io_error() being true.

    We need to set buffer_uptodate() before we call mark_buffer_dirty() or
    this will trigger a WARN_ON. It's safe to do this since the
    superblock must have been properly read into memory or the mount would
    have been successful. So if buffer_uptodate() is not set, we can
    safely assume that this happened due to a failed attempt to write the
    superblock.

    Signed-off-by: Theodore Ts'o
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman

    Theodore Ts'o
     
  • commit 2b08b1f12cd664dc7d5c84ead9ff25ae97ad5491 upstream.

    The ext4_inline_data_fiemap() function calls fiemap_fill_next_extent()
    while still holding the xattr semaphore. This is not necessary and it
    triggers a circular lockdep warning. This is because
    fiemap_fill_next_extent() could trigger a page fault when it writes
    into page which triggers a page fault. If that page is mmaped from
    the inline file in question, this could very well result in a
    deadlock.

    This problem can be reproduced using generic/519 with a file system
    configuration which has the inline_data feature enabled.

    Signed-off-by: Theodore Ts'o
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman

    Theodore Ts'o
     
  • commit 812c0cab2c0dfad977605dbadf9148490ca5d93f upstream.

    There are enough credits reserved for most dioread_nolock writes;
    however, if the extent tree is sufficiently deep, and/or quota is
    enabled, the code was not allowing for all eventualities when
    reserving journal credits for the unwritten extent conversion.

    This problem can be seen using xfstests ext4/034:

    WARNING: CPU: 1 PID: 257 at fs/ext4/ext4_jbd2.c:271 __ext4_handle_dirty_metadata+0x10c/0x180
    Workqueue: ext4-rsv-conversion ext4_end_io_rsv_work
    RIP: 0010:__ext4_handle_dirty_metadata+0x10c/0x180
    ...
    EXT4-fs: ext4_free_blocks:4938: aborting transaction: error 28 in __ext4_handle_dirty_metadata
    EXT4: jbd2_journal_dirty_metadata failed: handle type 11 started at line 4921, credits 4/0, errcode -28
    EXT4-fs error (device dm-1) in ext4_free_blocks:4950: error 28

    Signed-off-by: Theodore Ts'o
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman

    Theodore Ts'o
     

10 Jan, 2019

7 commits

  • commit 18f2c4fcebf2582f96cbd5f2238f4f354a0e4847 upstream.

    If the file system has been shut down or is read-only, then
    ext4_write_inode() needs to bail out early.

    Also use jbd2_complete_transaction() instead of ext4_force_commit() so
    we only force a commit if it is needed.

    Signed-off-by: Theodore Ts'o
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman

    Theodore Ts'o
     
  • commit fde872682e175743e0c3ef939c89e3c6008a1529 upstream.

    Some time back, nfsd switched from calling vfs_fsync() to using a new
    commit_metadata() hook in export_operations(). If the file system did
    not provide a commit_metadata() hook, it fell back to using
    sync_inode_metadata(). Unfortunately doesn't work on all file
    systems. In particular, it doesn't work on ext4 due to how the inode
    gets journalled --- the VFS writeback code will not always call
    ext4_write_inode().

    So we need to provide our own ext4_nfs_commit_metdata() method which
    calls ext4_write_inode() directly.

    Google-Bug-Id: 121195940
    Signed-off-by: Theodore Ts'o
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman

    Theodore Ts'o
     
  • commit a805622a757b6d7f65def4141d29317d8e37b8a1 upstream.

    In ext4_expand_extra_isize_ea(), we calculate the total size of the
    xattr header, plus the xattr entries so we know how much of the
    beginning part of the xattrs to move when expanding the inode extra
    size. We need to include the terminating u32 at the end of the xattr
    entries, or else if there is uninitialized, non-zero bytes after the
    xattr entries and before the xattr values, the list of xattr entries
    won't be properly terminated.

    Reported-by: Steve Graham
    Signed-off-by: Theodore Ts'o
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman

    Theodore Ts'o
     
  • commit e647e29196b7f802f8242c39ecb7cc937f5ef217 upstream.

    Commit e2b911c53584 ("ext4: clean up feature test macros with
    predicate functions") broke the EXT4_IOC_GROUP_ADD ioctl. This was
    not noticed since only very old versions of resize2fs (before
    e2fsprogs 1.42) use this ioctl. However, using a new kernel with an
    enterprise Linux userspace will cause attempts to use online resize to
    fail with "No reserved GDT blocks".

    Fixes: e2b911c53584 ("ext4: clean up feature test macros with predicate...")
    Cc: stable@kernel.org # v4.4
    Signed-off-by: Theodore Ts'o
    Signed-off-by: ruippan (潘睿)
    Signed-off-by: Greg Kroah-Hartman

    ruippan (潘睿)
     
  • commit 132d00becb31e88469334e1e62751c81345280e0 upstream.

    In case of error, ext4_try_to_write_inline_data() should unlock
    and release the page it holds.

    Fixes: f19d5870cbf7 ("ext4: add normal write support for inline data")
    Cc: stable@kernel.org # 3.8
    Signed-off-by: Maurizio Lombardi
    Signed-off-by: Theodore Ts'o
    Signed-off-by: Greg Kroah-Hartman

    Maurizio Lombardi
     
  • commit 61157b24e60fb3cd1f85f2c76a7b1d628f970144 upstream.

    The function frees qf_inode via iput but then pass qf_inode to
    lockdep_set_quota_inode on the failure path. This may result in a
    use-after-free bug. The patch frees df_inode only when it is never used.

    Fixes: daf647d2dd5 ("ext4: add lockdep annotations for i_data_sem")
    Cc: stable@kernel.org # 4.6
    Reviewed-by: Jan Kara
    Signed-off-by: Pan Bian
    Signed-off-by: Theodore Ts'o
    Signed-off-by: Greg Kroah-Hartman

    Pan Bian
     
  • commit fb265c9cb49e2074ddcdd4de99728aefdd3b3592 upstream.

    Today, when sb_bread() returns NULL, this can either be because of an
    I/O error or because the system failed to allocate the buffer. Since
    it's an old interface, changing would require changing many call
    sites.

    So instead we create our own ext4_sb_bread(), which also allows us to
    set the REQ_META flag.

    Also fixed a problem in the xattr code where a NULL return in a
    function could also mean that the xattr was not found, which could
    lead to the wrong error getting returned to userspace.

    Fixes: ac27a0ec112a ("ext4: initial copy of files from ext3")
    Cc: stable@kernel.org # 2.6.19
    Signed-off-by: Theodore Ts'o
    Signed-off-by: Greg Kroah-Hartman

    Theodore Ts'o
     

21 Nov, 2018

17 commits


14 Nov, 2018

5 commits

  • commit 33458eaba4dfe778a426df6a19b7aad2ff9f7eec upstream.

    It's possible for ext4_show_quota_options() to try reading
    s_qf_names[i] while it is being modified by ext4_remount() --- most
    notably, in ext4_remount's error path when the original values of the
    quota file name gets restored.

    Reported-by: syzbot+a2872d6feea6918008a9@syzkaller.appspotmail.com
    Signed-off-by: Theodore Ts'o
    Cc: stable@kernel.org # 3.2+
    Signed-off-by: Greg Kroah-Hartman

    Theodore Ts'o
     
  • commit 182a79e0c17147d2c2d3990a9a7b6b58a1561c7a upstream.

    We return most failure of dquota_initialize() except
    inode evict, this could make a bit sense, for example
    we allow file removal even quota files are broken?

    But it dosen't make sense to allow setting project
    if quota files etc are broken.

    Signed-off-by: Wang Shilong
    Signed-off-by: Theodore Ts'o
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman

    Wang Shilong
     
  • commit dc7ac6c4cae3b58724c2f1e21a7c05ce19ecd5a8 upstream.

    Currently, project quota could be changed by fssetxattr
    ioctl, and existed permission check inode_owner_or_capable()
    is obviously not enough, just think that common users could
    change project id of file, that could make users to
    break project quota easily.

    This patch try to follow same regular of xfs project
    quota:

    "Project Quota ID state is only allowed to change from
    within the init namespace. Enforce that restriction only
    if we are trying to change the quota ID state.
    Everything else is allowed in user namespaces."

    Besides that, check and set project id'state should
    be an atomic operation, protect whole operation with
    inode lock, ext4_ioctl_setproject() is only used for
    ioctl EXT4_IOC_FSSETXATTR, we have held mnt_want_write_file()
    before ext4_ioctl_setflags(), and ext4_ioctl_setproject()
    is called after ext4_ioctl_setflags(), we could share
    codes, so remove it inside ext4_ioctl_setproject().

    Signed-off-by: Wang Shilong
    Signed-off-by: Theodore Ts'o
    Reviewed-by: Andreas Dilger
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman

    Wang Shilong
     
  • commit 625ef8a3acd111d5f496d190baf99d1a815bd03e upstream.

    Variable retries is not initialized in ext4_da_write_inline_data_begin()
    which can lead to nondeterministic number of retries in case we hit
    ENOSPC. Initialize retries to zero as we do everywhere else.

    Signed-off-by: Lukas Czerner
    Signed-off-by: Theodore Ts'o
    Fixes: bc0ca9df3b2a ("ext4: retry allocation when inline->extent conversion failed")
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman

    Lukas Czerner
     
  • [ Upstream commit f18b2b83a727a3db208308057d2c7945f368e625 ]

    If the starting block number of either the source or destination file
    exceeds the EOF, EXT4_IOC_MOVE_EXT should return EINVAL.

    Also fixed the helper function mext_check_coverage() so that if the
    logical block is beyond EOF, make it return immediately, instead of
    looping until the block number wraps all the away around. This takes
    long enough that if there are multiple threads trying to do pound on
    an the same inode doing non-sensical things, it can end up triggering
    the kernel's soft lockup detector.

    Reported-by: syzbot+c61979f6f2cba5cb3c06@syzkaller.appspotmail.com
    Signed-off-by: Theodore Ts'o
    Cc: stable@kernel.org
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Theodore Ts'o
     

29 Sep, 2018

6 commits

  • commit 338affb548c243d2af25b1ca628e67819350de6b upstream.

    When in effect, add "test_dummy_encryption" to _ext4_show_options() so
    that it is shown in /proc/mounts and other relevant procfs files.

    Signed-off-by: Eric Biggers
    Signed-off-by: Theodore Ts'o
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman

    Eric Biggers
     
  • commit fe18d649891d813964d3aaeebad873f281627fbc upstream.

    Marking mmp bh dirty before writing it will make writeback
    pick up mmp block later and submit a write, we don't want the
    duplicate write as kmmpd thread should have full control of
    reading and writing the mmp block.
    Another reason is we will also have random I/O error on
    the writeback request when blk integrity is enabled, because
    kmmpd could modify the content of the mmp block(e.g. setting
    new seq and time) while the mmp block is under I/O requested
    by writeback.

    Signed-off-by: Li Dongyang
    Signed-off-by: Theodore Ts'o
    Reviewed-by: Andreas Dilger
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman

    Li Dongyang
     
  • commit 5f8c10936fab2b69a487400f2872902e597dd320 upstream.

    An online resize of a file system with the bigalloc feature enabled
    and a 1k block size would be refused since ext4_resize_begin() did not
    understand s_first_data_block is 0 for all bigalloc file systems, even
    when the block size is 1k.

    Signed-off-by: Theodore Ts'o
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman

    Theodore Ts'o
     
  • commit f0a459dec5495a3580f8d784555e6f8f3bf7f263 upstream.

    Avoid growing the file system to an extent so that the last block
    group is too small to hold all of the metadata that must be stored in
    the block group.

    This problem can be triggered with the following reproducer:

    umount /mnt
    mke2fs -F -m0 -b 4096 -t ext4 -O resize_inode,^has_journal \
    -E resize=1073741824 /tmp/foo.img 128M
    mount /tmp/foo.img /mnt
    truncate --size 1708M /tmp/foo.img
    resize2fs /dev/loop0 295400
    umount /mnt
    e2fsck -fy /tmp/foo.img

    Reported-by: Torsten Hilbrich
    Signed-off-by: Theodore Ts'o
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman

    Theodore Ts'o
     
  • commit 4274f516d4bc50648a4d97e4f67ecbd7b65cde4a upstream.

    When mounting the superblock, ext4_fill_super() calculates the free
    blocks and free inodes and stores them in the superblock. It's not
    strictly necessary, since we don't use them any more, but it's nice to
    keep them roughly aligned to reality.

    Since it's not critical for file system correctness, the code doesn't
    call ext4_commit_super(). The problem is that it's in
    ext4_commit_super() that we recalculate the superblock checksum. So
    if we're not going to call ext4_commit_super(), we need to call
    ext4_superblock_csum_set() to make sure the superblock checksum is
    consistent.

    Most of the time, this doesn't matter, since we end up calling
    ext4_commit_super() very soon thereafter, and definitely by the time
    the file system is unmounted. However, it doesn't work in this
    sequence:

    mke2fs -Fq -t ext4 /dev/vdc 128M
    mount /dev/vdc /vdc
    cp xfstests/git-versions /vdc
    godown /vdc
    umount /vdc
    mount /dev/vdc
    tune2fs -l /dev/vdc

    With this commit, the "tune2fs -l" no longer fails.

    Reported-by: Chengguang Xu
    Signed-off-by: Theodore Ts'o
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman

    Theodore Ts'o
     
  • commit bcd8e91f98c156f4b1ebcfacae675f9cfd962441 upstream.

    A maliciously crafted file system can cause an overflow when the
    results of a 64-bit calculation is stored into a 32-bit length
    parameter.

    https://bugzilla.kernel.org/show_bug.cgi?id=200623

    Signed-off-by: Theodore Ts'o
    Reported-by: Wen Xu
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman

    Theodore Ts'o