From: Alberto Garcia <berto@igalia.com>
To: Theodore Ts'o <tytso@mit.edu>
Cc: Alberto Garcia <berto@igalia.com>,
Andreas Dilger <adilger.kernel@dilger.ca>,
Baokun Li <libaokun@linux.alibaba.com>, Jan Kara <jack@suse.cz>,
Ojaswin Mujoo <ojaswin@linux.ibm.com>,
Ritesh Harjani <ritesh.list@gmail.com>,
Zhang Yi <yi.zhang@huawei.com>,
Eric Biggers <ebiggers@kernel.org>,
linux-fscrypt@vger.kernel.org, linux-ext4@vger.kernel.org
Subject: [PATCH 0/2] ext4: refuse encryption when block size > page size
Date: Fri, 25 Sep 2026 16:19:17 +0200 [thread overview]
Message-ID: <cover.1790343958.git.berto@igalia.com> (raw)
Hi,
encryption is not supported when a filesystem's block size is larger
than the page size. Although the kernel refuses to mount such a
filesystem if the "encrypt" feature is already set, it is possible to
enable it on a mounted filesystem with e.g. tune2fs.
# mkfs.ext4 -b 16384 /dev/vdb
# mount /dev/vdb /mnt/
# tune2fs -O encrypt /dev/vdb
# mkdir /mnt/foo
# fscrypt setup /mnt
# fscrypt encrypt /mnt/foo/
# head -c 20M /dev/urandom > /mnt/foo/data
# sync
[ 116.014221] EXT4-fs warning (device vdb): ext4_end_bio:360: I/O error 19 writing to inode 19 starting block 130040)
[ 116.014235] EXT4-fs (vdb): failed to convert unwritten extents to written extents -- potential data loss! (inode 19, error -5)
[ 116.014241] Buffer I/O error on device vdb, logical block 130040
[...]
[ 116.014264] Buffer I/O error on device vdb, logical block 130049
[ 116.015505] EXT4-fs warning (device vdb): ext4_end_bio:360: I/O error 19 writing to inode 19 starting block 66552)
[ 116.015520] EXT4-fs (vdb): failed to convert unwritten extents to written extents -- potential data loss! (inode 19, error -5)
[ 116.016451] EXT4-fs warning (device vdb): ext4_end_bio:360: I/O error 19 writing to inode 19 starting block 65784)
[ 116.016459] EXT4-fs (vdb): failed to convert unwritten extents to written extents -- potential data loss! (inode 19, error -5)
This affects all kernels starting from v6.19 up to v7.3-rc4.
Note that this still allows encrypted inodes even when the 'encrypt'
feature is missing as long as block size <= page size. With v1
encryption policies they can be used normally.
There's an additional bug that only affects kernels between v6.19 and
v7.2 (but not v7.3), which will be dealt with separately.
Regards,
Berto
Alberto Garcia (2):
ext4: refuse encryption when block size > page size
ext4: reject encrypted inodes when block size > page size
fs/ext4/crypto.c | 9 +++++++++
fs/ext4/inode.c | 6 ++++++
2 files changed, 15 insertions(+)
--
2.47.3
next reply other threads:[~2026-09-25 14:20 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-25 14:19 Alberto Garcia [this message]
2026-09-25 14:19 ` [PATCH 1/2] ext4: refuse encryption when block size > page size Alberto Garcia
2026-09-25 14:27 ` sashiko-bot
2026-10-03 15:17 ` Baokun Li
2026-09-25 14:19 ` [PATCH 2/2] ext4: reject encrypted inodes " Alberto Garcia
2026-09-25 14:26 ` sashiko-bot
2026-10-03 15:28 ` Baokun Li
2026-09-25 19:59 ` [PATCH 0/2] ext4: refuse encryption " Eric Biggers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cover.1790343958.git.berto@igalia.com \
--to=berto@igalia.com \
--cc=adilger.kernel@dilger.ca \
--cc=ebiggers@kernel.org \
--cc=jack@suse.cz \
--cc=libaokun@linux.alibaba.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fscrypt@vger.kernel.org \
--cc=ojaswin@linux.ibm.com \
--cc=ritesh.list@gmail.com \
--cc=tytso@mit.edu \
--cc=yi.zhang@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox