This patch series enables a future version of tune2fs to be able to modify certain parts of the ext4 superblock without to write to the block device.
The first patch fixes a potential buffer overrun caused by a maliciously moified superblock. The second patch adds support for 32-bit uid and gid's which can have access to the reserved blocks pool. The last patch adds the ioctl's which will be used by tune2fs.
Signed-off-by: Theodore Ts'o tytso@mit.edu --- Theodore Ts'o (3): ext4: avoid potential buffer over-read in parse_apply_sb_mount_options() ext4: add support for 32-bit default reserved uid and gid values ext4: implemet new ioctls to set and get superblock parameters
fs/ext4/ext4.h | 16 ++++- fs/ext4/ioctl.c | 256 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--- fs/ext4/super.c | 25 +++----- include/uapi/linux/ext4.h | 75 ++++++++++++++++++++++ 4 files changed, 348 insertions(+), 24 deletions(-) --- base-commit: b320789d6883cc00ac78ce83bccbfe7ed58afcf0 change-id: 20250830-tune2fs-3376beb72403
Best regards,
From: Theodore Ts'o tytso@mit.edu
Unlike other strings in the ext4 superblock, we rely on tune2fs to make sure s_mount_opts is NUL terminated. Harden parse_apply_sb_mount_options() by treating s_mount_opts as a potential __nonstring.
Cc: stable@vger.kernel.org Fixes: 8b67f04ab9de ("ext4: Add mount options in superblock") Signed-off-by: Theodore Ts'o tytso@mit.edu --- fs/ext4/super.c | 17 +++++------------ 1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/fs/ext4/super.c b/fs/ext4/super.c index 699c15db28a82f26809bf68533454a242596f0fd..94c98446c84f9a4614971d246ca7f001de610a8a 100644 --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -2460,7 +2460,7 @@ static int parse_apply_sb_mount_options(struct super_block *sb, struct ext4_fs_context *m_ctx) { struct ext4_sb_info *sbi = EXT4_SB(sb); - char *s_mount_opts = NULL; + char s_mount_opts[65]; struct ext4_fs_context *s_ctx = NULL; struct fs_context *fc = NULL; int ret = -ENOMEM; @@ -2468,15 +2468,11 @@ static int parse_apply_sb_mount_options(struct super_block *sb, if (!sbi->s_es->s_mount_opts[0]) return 0;
- s_mount_opts = kstrndup(sbi->s_es->s_mount_opts, - sizeof(sbi->s_es->s_mount_opts), - GFP_KERNEL); - if (!s_mount_opts) - return ret; + strscpy_pad(s_mount_opts, sbi->s_es->s_mount_opts);
fc = kzalloc(sizeof(struct fs_context), GFP_KERNEL); if (!fc) - goto out_free; + return -ENOMEM;
s_ctx = kzalloc(sizeof(struct ext4_fs_context), GFP_KERNEL); if (!s_ctx) @@ -2508,11 +2504,8 @@ static int parse_apply_sb_mount_options(struct super_block *sb, ret = 0;
out_free: - if (fc) { - ext4_fc_free(fc); - kfree(fc); - } - kfree(s_mount_opts); + ext4_fc_free(fc); + kfree(fc); return ret; }
On Mon, Sep 08, 2025 at 11:15:48PM -0400, Theodore Ts'o via B4 Relay wrote:
From: Theodore Ts'o tytso@mit.edu
Unlike other strings in the ext4 superblock, we rely on tune2fs to make sure s_mount_opts is NUL terminated. Harden parse_apply_sb_mount_options() by treating s_mount_opts as a potential __nonstring.
Uh.... does that mean that a filesystem with exactly 64 bytes worth of mount option string (and no trailing null) could do something malicious?
My guess is that s_usr_quota_inum mostly saves us, but a nastycrafted filesystem with more than 2^24 inodes could cause an out of bounds memory access? But that most likely will just fail the mount option parser anyway?
--D
Cc: stable@vger.kernel.org Fixes: 8b67f04ab9de ("ext4: Add mount options in superblock") Signed-off-by: Theodore Ts'o tytso@mit.edu
fs/ext4/super.c | 17 +++++------------ 1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/fs/ext4/super.c b/fs/ext4/super.c index 699c15db28a82f26809bf68533454a242596f0fd..94c98446c84f9a4614971d246ca7f001de610a8a 100644 --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -2460,7 +2460,7 @@ static int parse_apply_sb_mount_options(struct super_block *sb, struct ext4_fs_context *m_ctx) { struct ext4_sb_info *sbi = EXT4_SB(sb);
- char *s_mount_opts = NULL;
- char s_mount_opts[65]; struct ext4_fs_context *s_ctx = NULL; struct fs_context *fc = NULL; int ret = -ENOMEM;
@@ -2468,15 +2468,11 @@ static int parse_apply_sb_mount_options(struct super_block *sb, if (!sbi->s_es->s_mount_opts[0]) return 0;
- s_mount_opts = kstrndup(sbi->s_es->s_mount_opts,
sizeof(sbi->s_es->s_mount_opts),GFP_KERNEL);- if (!s_mount_opts)
return ret;
- strscpy_pad(s_mount_opts, sbi->s_es->s_mount_opts);
fc = kzalloc(sizeof(struct fs_context), GFP_KERNEL); if (!fc)
goto out_free;
return -ENOMEM;s_ctx = kzalloc(sizeof(struct ext4_fs_context), GFP_KERNEL); if (!s_ctx) @@ -2508,11 +2504,8 @@ static int parse_apply_sb_mount_options(struct super_block *sb, ret = 0; out_free:
- if (fc) {
ext4_fc_free(fc);kfree(fc);- }
- kfree(s_mount_opts);
- ext4_fc_free(fc);
- kfree(fc); return ret;
}
-- 2.51.0
On Thu, Sep 11, 2025 at 03:27:00PM -0700, Darrick J. Wong wrote:
On Mon, Sep 08, 2025 at 11:15:48PM -0400, Theodore Ts'o via B4 Relay wrote:
From: Theodore Ts'o tytso@mit.edu
Unlike other strings in the ext4 superblock, we rely on tune2fs to make sure s_mount_opts is NUL terminated. Harden parse_apply_sb_mount_options() by treating s_mount_opts as a potential __nonstring.
Uh.... does that mean that a filesystem with exactly 64 bytes worth of mount option string (and no trailing null) could do something malicious?
Maybe.... I'm surprised syzkaller hasn't managed to create a maliciously fuzzed file system along these lines.
This was one of the things that I found while I was poking about in code that I hadn't examined in years. And I guess the kernel hardening folks have been looking for strndup() as a deprecated interface, but apparently they haven't targetted kstrndup() yet.
My guess is that s_usr_quota_inum mostly saves us, but a nastycrafted filesystem with more than 2^24 inodes could cause an out of bounds memory access? But that most likely will just fail the mount option parser anyway?
Actually, s_usr_quota_inum won't help, because s_mount_opts is copied into allocated memory using kstrndup(). So the buffer overrun is going to be in the allocated memory buffer, and since parse_options() uses strsep() it could potentially modify an adajacent string/buffer by replacing ',' and '=' bytes with NUL characters. I'll leave to security engineers to see if they can turn it into a usuable exploit, although I've always said that mounting untrusted file systems isn't a wise thing for a paranoid system administrator to do/allow, which is why I'm a big fan of your fuse2fs work. :-)
- Ted
linux-stable-mirror@lists.linaro.org
-
Darrick J. Wong -
Theodore Ts'o -
Theodore Ts'o via B4 Relay