[PATCH 0/2] quota: fix oops when loading corrupted quota file

[PATCH 0/2] quota: fix oops when loading corrupted quota file

[Zhang Yi]

We hit an oops issue on our Syzkaller machine, it test on an corrupted
ext4 filesystem image with quota feature.

 BUG: unable to handle page fault for address: ffffffffd9c01f8d
 PGD 732e0f067 P4D 732e0f067 PUD 732e11067 PMD 0 
 Oops: 0000 [#1] SMP PTI
 CPU: 5 PID: 1282 Comm: chown Not tainted 5.15.0-rc4-00019-g5af4055fa813 #572
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
 ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31
 04/01/2014
 RIP: 0010:do_raw_spin_lock+0x6/0x190
 Code: e8 00 44 8b 4d 08 48 85 db 0f 84 c5 b9 e8 00 e9 fd b9 e8 00 48 83
 05 d0 ec cc 02 01 31 db eb b0 0f 1f 40 00 0f 1f 44 00 00 53 <8b> 47 04
 48 89 fb 48 83 05 0c ee cc 02 01 48 83 05 e4 ec cc 02 01
 RSP: 0018:ffffac4140be7b78 EFLAGS: 00010202
 RAX: 0000000000000000 RBX: ffffffffd9c01f11 RCX: 0000000000000000
 RDX: ffffac4140be7c00 RSI: 0000000000000001 RDI: ffffffffd9c01f89
 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000002
 R10: 0000000000000001 R11: 0000000000000005 R12: ffffac4140be7c00
 R13: ffffffffd9c01f89 R14: ffffac4140be7d20 R15: 0000000000000000
 FS:  00007efd702dc580(0000) GS:ffff889ca5740000(0000)
 knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: ffffffffd9c01f8d CR3: 000000015dae8000 CR4: 00000000000006e0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
 Call Trace:
  _raw_spin_lock+0x1a/0x30
  dquot_add_inodes+0x28/0x2a0
  __dquot_transfer+0x3af/0x8e0
  ? jbd2_journal_stop+0x213/0x510
  ? __ext4_journal_stop+0x43/0x110
  ? ext4_acquire_dquot+0xb2/0x120
  ? dqget+0x317/0x710
  dquot_transfer+0xaa/0x1f0
  ext4_setattr+0x1b1/0xf20
  ? path_lookupat.isra.0+0xca/0x200
  notify_change+0x484/0x790
  ? chown_common+0x16e/0x2f0
  chown_common+0x16e/0x2f0
  do_fchownat+0x107/0x180
  __x64_sys_fchownat+0x29/0x40
  do_syscall_64+0x3b/0x90

We could 100% reproduce it through the following simple test case. The
first patche add some block validity check and the second patch fix an
incorrect return value.


 TEST_DEV=/dev/pmem0
 
 useradd fsgqa
 useradd 123456-fsgqa
 
 mkfs.ext4 -F -O quota -b 1024 $TEST_DEV
 debugfs -w -R "zap_block -o 0 -l 1 -p 6 -f <3> 1" $TEST_DEV
 mount $TEST_DEV /mnt
 chown fsgqa:fsgqa /mnt
 touch /mnt/foo
 rm -f /mnt/foo
 chown 123456-fsgqa:123456-fsgqa /mnt


Thanks,
Yi.

Zhang Yi (2):
  quota: check block number when reading the block in quota file
  qupta: correct error number in free_dqentry()

 fs/quota/quota_tree.c | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

-- 
2.31.1

[PATCH 1/2] quota: check block number when reading the block in quota file

[Zhang Yi]

The block number in the quota tree on disk should smaller than the
v2_disk_dqinfo.dqi_blocks. If the quota file was corrupted, we may
allocating an 'allocated' block and lead to the tree infinite loop,
which may probably trigger oops later. This patch add a check for
getting block number in the quota tree to prevent such potential issue.

Signed-off-by: Zhang Yi <yi.zhang@huawei.com>
Cc: stable@kernel.org
---
 fs/quota/quota_tree.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/fs/quota/quota_tree.c b/fs/quota/quota_tree.c
index d3e995e1046f..583b7f7715f9 100644
--- a/fs/quota/quota_tree.c
+++ b/fs/quota/quota_tree.c
@@ -479,6 +479,13 @@ static int remove_tree(struct qtree_mem_dqinfo *info, struct dquot *dquot,
 		goto out_buf;
 	}
 	newblk = le32_to_cpu(ref[get_index(info, dquot->dq_id, depth)]);
+	if (newblk < QT_TREEOFF || newblk >= info->dqi_blocks) {
+		quota_error(dquot->dq_sb, "Getting block too big (%u >= %u)",
+			    newblk, info->dqi_blocks);
+		ret = -EUCLEAN;
+		goto out_buf;
+	}
+
 	if (depth == info->dqi_qtree_depth - 1) {
 		ret = free_dqentry(info, dquot, newblk);
 		newblk = 0;
@@ -578,6 +585,13 @@ static loff_t find_tree_dqentry(struct qtree_mem_dqinfo *info,
 	blk = le32_to_cpu(ref[get_index(info, dquot->dq_id, depth)]);
 	if (!blk)	/* No reference? */
 		goto out_buf;
+	if (blk < QT_TREEOFF || blk >= info->dqi_blocks) {
+		quota_error(dquot->dq_sb, "Getting block too big (%u >= %u)",
+			    blk, info->dqi_blocks);
+		ret = -EUCLEAN;
+		goto out_buf;
+	}
+
 	if (depth < info->dqi_qtree_depth - 1)
 		ret = find_tree_dqentry(info, dquot, blk, depth+1);
 	else
-- 
2.31.1

[PATCH 2/2] qupta: correct error number in free_dqentry()

[Zhang Yi]

Fix the error path in free_dqentry(), pass out the error number if the
freeing block is not correct.

Fixes: 1ccd14b9c271c ("quota: Split off quota tree handling into a separate file")
Signed-off-by: Zhang Yi <yi.zhang@huawei.com>
Cc: stable@kernel.org
---
 fs/quota/quota_tree.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/quota/quota_tree.c b/fs/quota/quota_tree.c
index 583b7f7715f9..5f2405994280 100644
--- a/fs/quota/quota_tree.c
+++ b/fs/quota/quota_tree.c
@@ -414,6 +414,7 @@ static int free_dqentry(struct qtree_mem_dqinfo *info, struct dquot *dquot,
 		quota_error(dquot->dq_sb, "Quota structure has offset to "
 			"other block (%u) than it should (%u)", blk,
 			(uint)(dquot->dq_off >> info->dqi_blocksize_bits));
+		ret = -EIO;
 		goto out_buf;
 	}
 	ret = read_blk(info, blk, buf);
-- 
2.31.1

Re: [PATCH 0/2] quota: fix oops when loading corrupted quota file

[Jan Kara]

On Fri 08-10-21 17:38:19, Zhang Yi wrote:
> We hit an oops issue on our Syzkaller machine, it test on an corrupted
> ext4 filesystem image with quota feature.
> 
>  BUG: unable to handle page fault for address: ffffffffd9c01f8d
>  PGD 732e0f067 P4D 732e0f067 PUD 732e11067 PMD 0 
>  Oops: 0000 [#1] SMP PTI
>  CPU: 5 PID: 1282 Comm: chown Not tainted 5.15.0-rc4-00019-g5af4055fa813 #572
>  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
>  ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31
>  04/01/2014
>  RIP: 0010:do_raw_spin_lock+0x6/0x190
>  Code: e8 00 44 8b 4d 08 48 85 db 0f 84 c5 b9 e8 00 e9 fd b9 e8 00 48 83
>  05 d0 ec cc 02 01 31 db eb b0 0f 1f 40 00 0f 1f 44 00 00 53 <8b> 47 04
>  48 89 fb 48 83 05 0c ee cc 02 01 48 83 05 e4 ec cc 02 01
>  RSP: 0018:ffffac4140be7b78 EFLAGS: 00010202
>  RAX: 0000000000000000 RBX: ffffffffd9c01f11 RCX: 0000000000000000
>  RDX: ffffac4140be7c00 RSI: 0000000000000001 RDI: ffffffffd9c01f89
>  RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000002
>  R10: 0000000000000001 R11: 0000000000000005 R12: ffffac4140be7c00
>  R13: ffffffffd9c01f89 R14: ffffac4140be7d20 R15: 0000000000000000
>  FS:  00007efd702dc580(0000) GS:ffff889ca5740000(0000)
>  knlGS:0000000000000000
>  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>  CR2: ffffffffd9c01f8d CR3: 000000015dae8000 CR4: 00000000000006e0
>  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
>  Call Trace:
>   _raw_spin_lock+0x1a/0x30
>   dquot_add_inodes+0x28/0x2a0
>   __dquot_transfer+0x3af/0x8e0
>   ? jbd2_journal_stop+0x213/0x510
>   ? __ext4_journal_stop+0x43/0x110
>   ? ext4_acquire_dquot+0xb2/0x120
>   ? dqget+0x317/0x710
>   dquot_transfer+0xaa/0x1f0
>   ext4_setattr+0x1b1/0xf20
>   ? path_lookupat.isra.0+0xca/0x200
>   notify_change+0x484/0x790
>   ? chown_common+0x16e/0x2f0
>   chown_common+0x16e/0x2f0
>   do_fchownat+0x107/0x180
>   __x64_sys_fchownat+0x29/0x40
>   do_syscall_64+0x3b/0x90
> 
> We could 100% reproduce it through the following simple test case. The
> first patche add some block validity check and the second patch fix an
> incorrect return value.
> 
> 
>  TEST_DEV=/dev/pmem0
>  
>  useradd fsgqa
>  useradd 123456-fsgqa
>  
>  mkfs.ext4 -F -O quota -b 1024 $TEST_DEV
>  debugfs -w -R "zap_block -o 0 -l 1 -p 6 -f <3> 1" $TEST_DEV
>  mount $TEST_DEV /mnt
>  chown fsgqa:fsgqa /mnt
>  touch /mnt/foo
>  rm -f /mnt/foo
>  chown 123456-fsgqa:123456-fsgqa /mnt
> 
> 
> Thanks,
> Yi.
> 
> Zhang Yi (2):
>   quota: check block number when reading the block in quota file
>   qupta: correct error number in free_dqentry()

Thanks, I've merged both patches into my tree with some minor spelling
fixes.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR