Re: [PATCH 03/13] blk-crypto: reject fallback data unit sizes it can't handle

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

On 2026/10/16 02:45, Eric Biggers wrote:
> On Mon, Oct 12, 2026 at 01:09:48AM +0800, Baokun Li wrote:
>> Such keys exist on filesystems whose
>> block size is larger than the page size, because fscrypt uses the block
>> size as its data unit size by default.
>>
>> Fix this by advertising only the data unit sizes that the fallback
>> really supports, and by rejecting keys that the fallback can't handle in
>> blk_crypto_fallback_start_using_key(), so that the failure happens when
>> the key is set up instead of during I/O, and before any data is written.
>>
>> Fixes: 488f6682c832 ("block: blk-crypto-fallback for Inline Encryption")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Baokun Li <libaokun@linux.alibaba.com>
> Several patches in this series are marked as fixes, but they seem to
> only be needed for encryption with data_unit_size > PAGE_SIZE which is a
> new feature in this series.  I don't think these should be marked as
> fixes, as they will cause unnecessary backports, CVEs, etc.

In this patch set, the five patches carrying the “Fixes” tag are
1, 2, 3, 8, and 12.

Patches 1, 2, and 12 were included because my commit 709f0f1f1bf5
(“ext4: add checks for large folio incompatibilities when BS > PS”)
did not account for the fact that encryption can be enabled at mount
time, making these issues accessible. Sorry about that.

Patch 3 was added because the blk-crypto-fallback implementation did not
limit the supported data unit size, setting it directly to 0xFFFFFFFF.
This could cause silent data corruption, so I added an upper limit in
the patch set and applied the “Fixes” tag. However, since this issue was
unreachable prior to my patch mentioned above, I'm fine with removing
the “Fixes” tag 

Patch 8 can also be triggered when the sector size is 512 but the
filesystem block size is 4k, so a `Fixes` tag was added to it as well.

If you think any of these are unnecessary, I can remove them in the next
iteration.


Cheers,
Baokun