kernel.git/fs/ext4/ext4.h, branch linux-3.16.y

ext4: Make checks for metadata_csum feature safer

2020-06-11T18:05:53Z

This is just a small part of commit dec214d00e0d7 "ext4: xattr inode deduplication" that makes checks for metadata_csum feature safer and is actually needed by following fixes. Signed-off-by: Tahsin Erdogan Acked-by: Jan Kara [bwh: Ported to 3.16: Use EXT4_HAS_RO_COMPAT_FEATURE()] Signed-off-by: Ben Hutchings

ext4: fix races of writeback with punch hole and zero range

2020-04-28T18:02:21Z

commit 011278485ecc3cd2a3954b5d4c73101d919bf1fa upstream. When doing delayed allocation, update of on-disk inode size is postponed until IO submission time. However hole punch or zero range fallocate calls can end up discarding the tail page cache page and thus on-disk inode size would never be properly updated. Make sure the on-disk inode size is updated before truncating page cache. Signed-off-by: Jan Kara Signed-off-by: Theodore Ts'o Signed-off-by: Ben Hutchings

ext4: fix races between page faults and hole punching

2020-04-28T18:02:19Z

commit ea3d7209ca01da209cda6f0dea8be9cc4b7a933b upstream. Currently, page faults and hole punching are completely unsynchronized. This can result in page fault faulting in a page into a range that we are punching after truncate_pagecache_range() has been called and thus we can end up with a page mapped to disk blocks that will be shortly freed. Filesystem corruption will shortly follow. Note that the same race is avoided for truncate by checking page fault offset against i_size but there isn't similar mechanism available for punching holes. Fix the problem by creating new rw semaphore i_mmap_sem in inode and grab it for writing over truncate, hole punching, and other functions removing blocks from extent tree and for read over page faults. We cannot easily use i_data_sem for this since that ranks below transaction start and we need something ranking above it so that it can be held over the whole truncate / hole punching operation. Also remove various workarounds we had in the code to reduce race window when page fault could have created pages with stale mapping information. Signed-off-by: Jan Kara Signed-off-by: Theodore Ts'o [bwh: Backported to 3.16: - Drop changes in ext4_insert_range(), ext4_dax_* - Adjust context] Signed-off-by: Ben Hutchings

ext4: add mask of ext4 flags to swap

2019-07-09T21:03:58Z

commit abdc644e8cbac2e9b19763680e5a7cf9bab2bee7 upstream. The reason is that while swapping two inode, we swap the flags too. Some flags such as EXT4_JOURNAL_DATA_FL can really confuse the things since we're not resetting the address operations structure. The simplest way to keep things sane is to restrict the flags that can be swapped. Signed-off-by: yangerkun Signed-off-by: Theodore Ts'o [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings

ext4: ext4_inline_data_fiemap should respect callers argument

2019-04-04T15:14:06Z

commit d952d69e268f833c85c0bafee9f67f9dba85044b upstream. Currently ext4_inline_data_fiemap ignores requested arguments (start and len) which may lead endless loop if start != 0. Also fix incorrect extent length determination. Signed-off-by: Dmitry Monakhov Signed-off-by: Theodore Ts'o [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings

ext4: avoid declaring fs inconsistent due to invalid file handles

2019-04-04T15:13:59Z

commit 8a363970d1dc38c4ec4ad575c862f776f468d057 upstream. If we receive a file handle, either from NFS or open_by_handle_at(2), and it points at an inode which has not been initialized, and the file system has metadata checksums enabled, we shouldn't try to get the inode, discover the checksum is invalid, and then declare the file system as being inconsistent. This can be reproduced by creating a test file system via "mke2fs -t ext4 -O metadata_csum /tmp/foo.img 8M", mounting it, cd'ing into that directory, and then running the following program. #define _GNU_SOURCE #include struct handle { struct file_handle fh; unsigned char fid[MAX_HANDLE_SZ]; }; int main(int argc, char **argv) { struct handle h = {{8, 1 }, { 12, }}; open_by_handle_at(AT_FDCWD, &h.fh, O_RDONLY); return 0; } Google-Bug-Id: 120690101 Signed-off-by: Theodore Ts'o [bwh: Backported to 3.16: - Keep using EIO instead of EFSCORRUPTED and EFSBADCRC - Drop inapplicable changes - Adjust context] Signed-off-by: Ben Hutchings

ext4: fix use-after-free race in ext4_remount()'s error path

2019-02-11T17:53:31Z

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 [bwh: Backported to 3.16: - s/EXT4_MAXQUOTAS/MAXQUOTAS/ - Adjust context] Signed-off-by: Ben Hutchings

ext4: avoid running out of journal credits when appending to an inline file

2018-09-25T22:47:29Z

commit 8bc1379b82b8e809eef77a9fedbb75c6c297be19 upstream. Use a separate journal transaction if it turns out that we need to convert an inline file to use an data block. Otherwise we could end up failing due to not having journal credits. This addresses CVE-2018-10883. https://bugzilla.kernel.org/show_bug.cgi?id=200071 Signed-off-by: Theodore Ts'o [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings

ext4: add more inode number paranoia checks

2018-09-25T22:47:29Z

commit c37e9e013469521d9adb932d17a1795c139b36db upstream. If there is a directory entry pointing to a system inode (such as a journal inode), complain and declare the file system to be corrupted. Also, if the superblock's first inode number field is too small, refuse to mount the file system. This addresses CVE-2018-10882. https://bugzilla.kernel.org/show_bug.cgi?id=200069 Signed-off-by: Theodore Ts'o [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings

ext4: sanity check the block and cluster size at mount time

2017-02-23T03:54:38Z

commit 8cdf3372fe8368f56315e66bea9f35053c418093 upstream. If the block size or cluster size is insane, reject the mount. This is important for security reasons (although we shouldn't be just depending on this check). Ref: http://www.securityfocus.com/archive/1/539661 Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1332506 Reported-by: Borislav Petkov Reported-by: Nikolay Borisov Signed-off-by: Theodore Ts'o Signed-off-by: Ben Hutchings