linux-stable.git/fs/ext4/super.c, branch linux-4.1.y

ext4: don't allow r/w mounts if metadata blocks overlap the superblock

2018-05-23T01:36:34+00:00

[ Upstream commit 18db4b4e6fc31eda838dd1c1296d67dbcb3dc957 ]

If some metadata block, such as an allocation bitmap, overlaps the
superblock, it's very likely that if the file system is mounted
read/write, the results will not be pretty.  So disallow r/w mounts
for file systems corrupted in this particular way.

Signed-off-by: Theodore Ts'o 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

ext4 crypto: don't regenerate the per-inode encryption key unnecessarily

2018-03-04T15:28:35+00:00

[ Relevant upstream commit: 1b53cf9815bb4744958d41f3795d5d5a1d365e2d ]

This fixes the same problem as upstream commit 1b53cf9815bb: "fscrypt:
remove broken support for detecting keyring key revocation".
Specifically, key revocations racing with readpage operations will
cause the kernel to crash and burn with a BUG_ON or a NULL pointer
dereference in a block I/O callback stemming from an ext4_readpage()
operation.

This fix is needed to fix prevent xfstests test runs from crashing
while running the generic/421 test.

The root cause is different in the 4.1 kernel, however, since the
4.1's encryption handling is so _primitive_ compared to later kernels.
The code isn't actually explicitly checking for revoked keys.
Instead, the code is neededly regenerating the per-file encryption key
on every mmap() or open() or directory operation (in the case of a
directory inode).  Yelch!

If the file is already opened and actively being read, and while an
open() is racing with the read operations, after the user's master key
has been revoked, there will be the same net effect as the problem
fixed by upstream commit 1b53cf9815bb --- the per-file key will be
marked as invalid and this will cause a BUG_ON.

The AOSP 3.18 and 4.4 android-common kernels have a much more modern
version of ext4 encryption have been backported, which incldes a
backport of upstream commit 1b53cf9815bb.  This is a (at least)
dozen-plus commits, and isn't really suitable for the Upstream LTS
kernel.  So instead, this is the simplest bug which fixes the same
high-level issue as the upstream commit, without dragging in all of
the other non-bug-fix improvements to ext4 encryption found in newer
kernels.

Signed-off-by: Theodore Ts'o 
Signed-off-by: Eric Biggers 
Signed-off-by: Sasha Levin

ext4: save error to disk in __ext4_grp_locked_error()

2018-03-04T15:28:23+00:00

[ Upstream commit 06f29cc81f0350261f59643a505010531130eea0 ]

In the function __ext4_grp_locked_error(), __save_error_info()
is called to save error info in super block block, but does not sync
that information to disk to info the subsequence fsck after reboot.

This patch writes the error information to disk.  After this patch,
I think there is no obvious EXT4 error handle branches which leads to
"Remounting filesystem read-only" will leave the disk partition miss
the subsequence fsck.

Signed-off-by: Zhouyi Zhou 
Signed-off-by: Theodore Ts'o 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

ext4: preserve the needs_recovery flag when the journal is aborted

2018-01-17T17:25:20+00:00

[ Upstream commit 97abd7d4b5d9c48ec15c425485f054e1c15e591b ]

If the journal is aborted, the needs_recovery feature flag should not
be removed.  Otherwise, it's the journal might not get replayed and
this could lead to more data getting lost.

Signed-off-by: Theodore Ts'o 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

ext4: do not use stripe_width if it is not set

2017-12-07T02:19:55+00:00

[ Upstream commit 5469d7c3087ecaf760f54b447f11af6061b7c897 ]

Avoid using stripe_width for sbi->s_stripe value if it is not actually
set. It prevents using the stride for sbi->s_stripe.

Signed-off-by: Jan Kara 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Sasha Levin

ext4: fix incorrect quotaoff if the quota feature is enabled

2017-10-04T01:36:51+00:00

[ Upstream commit b0a5a9589decd07db755d6a8d9c0910d96ff7992 ]

Current ext4 quota should always "usage enabled" if the
quota feautre is enabled. But in ext4_orphan_cleanup(), it
turn quotas off directly (used for the older journaled
quota), so we cannot turn it on again via "quotaon" unless
umount and remount ext4.

Simple reproduce:

  mkfs.ext4 -O project,quota /dev/vdb1
  mount -o prjquota /dev/vdb1 /mnt
  chattr -p 123 /mnt
  chattr +P /mnt
  touch /mnt/aa /mnt/bb
  exec 100<>/mnt/aa
  rm -f /mnt/aa
  sync
  echo c > /proc/sysrq-trigger

  #reboot and mount
  mount -o prjquota /dev/vdb1 /mnt
  #query status
  quotaon -Ppv /dev/vdb1
  #output
  quotaon: Cannot find mountpoint for device /dev/vdb1
  quotaon: No correct mountpoint specified.

This patch add check for journaled quotas to avoid incorrect
quotaoff when ext4 has quota feautre.

Signed-off-by: zhangyi (F) 
Signed-off-by: Theodore Ts'o 
Reviewed-by: Jan Kara 
Cc: stable@vger.kernel.org # 3.18
Signed-off-by: Sasha Levin

ext4: add sanity checking to count_overhead()

2017-01-13T01:56:54+00:00

[ Upstream commit c48ae41bafe31e9a66d8be2ced4e42a6b57fa814 ]

The commit "ext4: sanity check the block and cluster size at mount
time" should prevent any problems, but in case the superblock is
modified while the file system is mounted, add an extra safety check
to make sure we won't overrun the allocated buffer.

Signed-off-by: Theodore Ts'o 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

ext4: use more strict checks for inodes_per_block on mount

2017-01-13T01:56:53+00:00

[ Upstream commit cd6bb35bf7f6d7d922509bf50265383a0ceabe96 ]

Centralize the checks for inodes_per_block and be more strict to make
sure the inodes_per_block_group can't end up being zero.

Signed-off-by: Theodore Ts'o 
Reviewed-by: Andreas Dilger 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

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

2017-01-13T01:56:53+00:00

[ Upstream commit 9e47a4c9fc58032ee135bf76516809c7624b1551 ]

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 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

xattr: Option to disable meta-data block cache

2016-12-23T13:56:34+00:00

mbcache provides absolutely no value for Lustre xattrs (because
they are unique and cannot be shared between files) and as we can
see it has a noticable overhead in some cases. In the past there
was a CONFIG_MBCACHE option that would allow it to be disabled,
but this was removed in newer kernels, so we will need to patch
ldiskfs to fix this.

References: 
References: 
References: CVE-2015-8952

On 13.12.2016 at 15:58 Ben Hutchings wrote:
> I decided not to apply this as it's a userland ABI extension that we
> would then need to carry indefinitely.

Signed-off-by: Philipp Hahn 
Signed-off-by: Sasha Levin