[PATCH 3/4] ext4: don't put a DUN wraparound in the middle of a read bio

[Baokun Li]

Under IV_INO_LBLK_32, a file's DUNs wrap at 2^32, and the policy
is only allowed when the block size equals the page size.

ext4_mpage_readpages() adds a whole folio to one bio, but checks
only the DUN of the first block. blk-crypto assumes the DUNs
in a bio are contiguous and never wraps them, so blocks past
the wraparound are read with the wrong DUNs.

Writeback and direct I/O get this right, but with large folios
a single folio can still span the wraparound.

Fix this by routing such a folio through the buffer_head path,
which submits one bio per block and so gives each block its own DUN.

fscrypt_limit_io_blocks() tells whether the wraparound falls after
the first block; a wraparound at the first block itself is already
caught by fscrypt_mergeable_bio().

A file's DUNs wrap at most once, so at most one folio per file takes
the slower path, and the per-block bios can be merged again by the
block layer.

Signed-off-by: Baokun Li <libaokun@xxxxxxxxxxxxxxxxx>
---
 fs/ext4/readpage.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/fs/ext4/readpage.c b/fs/ext4/readpage.c
index c7b6cdb2e124..43af6d9d6ddb 100644
--- a/fs/ext4/readpage.c
+++ b/fs/ext4/readpage.c
@@ -264,6 +264,16 @@ static int ext4_mpage_readpages(struct inode *inode, struct fsverity_info *vi,
 			folio_set_mappedtodisk(folio);
 		}
 
+		/*
+		 * blk-crypto assumes a bio's DUNs are contiguous, but under
+		 * IV_INO_LBLK_32 alone they wrap at 2^32.  A folio spanning
+		 * the wrap would be decrypted with wrong IVs, so it goes to
+		 * the buffer_head-based path, one bio per block.
+		 */
+		if (first_hole >
+		    fscrypt_limit_io_blocks(inode, pos >> blkbits, first_hole))
+			goto confused;
+
 		/*
 		 * This folio will go to BIO.  Do we need to send this
 		 * BIO off first?
-- 
2.43.7