[PATCH 12/13] ext4: send folios that cover a wraparound to the buffer_head path

[Baokun Li <libaokun@linux.alibaba.com>]

ext4_mpage_readpages() puts a whole folio into a bio with a single
crypt context, taken from the position of the folio, and blk-crypto
increments the data unit number for each data unit that follows in
the bio.

By contrast, fscrypt truncates the data unit numbers to 32 bits for
IV_INO_LBLK_32, the only supported IV generation method whose data
unit numbers wrap around within a file.

The blocks after a wraparound inside a folio are then en/decrypted
with IVs of 2^32 + i instead of i.  fscrypt_mergeable_bio() only runs
between folios, so nothing catches this.

This is reachable even without a block size larger than the page
size: when a filesystem is mounted without the encrypt feature,
ext4_set_max_mapping_order() does not cap its folio order, and
enabling the feature on the mounted filesystem does not change that.

The encrypted files of a policy that is set up afterwards then get
large folios, which can cover the data unit number wraparound of the
file.

Fix this by sending folios that cover a wraparound to the buffer_head
based path in ext4_mpage_readpages(), which creates one bio per block:
fscrypt_limit_io_blocks() tells whether the wraparound falls inside
the folio's blocks, and only the folio covering it takes the slower
path.

At most one folio per file is affected: the extra cost is a
buffer_head and a bio per block for that folio, and the block layer
merges those bios back together.

Fixes: 709f0f1f1bf5 ("ext4: add checks for large folio incompatibilities when BS > PS")
Cc: stable@vger.kernel.org # v6.19+
Signed-off-by: Baokun Li <libaokun@linux.alibaba.com>
---
 fs/ext4/readpage.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/fs/ext4/readpage.c b/fs/ext4/readpage.c
index c7b6cdb2e124..0c0dfaac6ded 100644
--- a/fs/ext4/readpage.c
+++ b/fs/ext4/readpage.c
@@ -264,6 +264,17 @@ static int ext4_mpage_readpages(struct inode *inode, struct fsverity_info *vi,
 			folio_set_mappedtodisk(folio);
 		}
 
+		/*
+		 * A bio's data unit numbers are derived from its first data
+		 * unit, so a folio that covers a data unit number wraparound
+		 * would be encrypted with the wrong IVs.  Only IV_INO_LBLK_32
+		 * can wrap; route such folios to the buffer_head based path,
+		 * which creates a bio per block.
+		 */
+		if (fscrypt_limit_io_blocks(inode, pos >> blkbits,
+					    first_hole) < first_hole)
+			goto confused;
+
 		/*
 		 * This folio will go to BIO.  Do we need to send this
 		 * BIO off first?
-- 
2.43.7