From: Ali Ahmet Memis <ali@iusegentoo.com>
To: Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>
Cc: Jan Kara <jack@suse.cz>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH 10/10] ufs: refuse read-write mount of check-hashed filesystems
Date: Sat, 1 Aug 2026 22:55:30 +0000 [thread overview]
Message-ID: <20260801225530.148386-11-ali@iusegentoo.com> (raw)
In-Reply-To: <20260801225530.148386-1-ali@iusegentoo.com>
Modern UFS2 protects metadata with check hashes. fs_metackhash says
which kinds are in use, CK_SUPERBLOCK, CK_CYLGRP, CK_INODE, CK_INDIR and
CK_DIR, and the hashes themselves live in fs_ckhash, cg_ckhash and
di_ckhash. FreeBSD recomputes them on every metadata write, for inodes
in ffs_update() right before the inode goes to disk, and treats a
mismatch as an integrity failure.
Linux knows about none of these fields. It happily allocates blocks,
changes inodes and rewrites cylinder groups without touching a single
hash, so an ordinary
touch /mnt/x
chmod 600 /mnt/x
leaves the filesystem valid by its own rules but failing every check
hash it advertises. Back on FreeBSD that surfaces as inode, cylinder
group and superblock check-hash failures on a filesystem that was never
damaged in any other way.
Implementing the hashes is a lot more work than this series is doing, so
stay read-only instead. Both the flag and a non-zero fs_metackhash are
required, so a filesystem that advertises the feature without actually
maintaining any hash is still writable.
This does change what userspace can do with an existing image: modern
FreeBSD enables check hashes by default, so filesystems that mount
read-write today will start coming up read-only. That is the point, but
it is a policy call rather than a plain bug fix, and it is the one patch
here that could be dropped without affecting the rest.
Signed-off-by: Ali Ahmet Memis <ali@iusegentoo.com>
---
fs/ufs/super.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/fs/ufs/super.c b/fs/ufs/super.c
index 6132c28c4308..52de393aebe2 100644
--- a/fs/ufs/super.c
+++ b/fs/ufs/super.c
@@ -799,6 +799,11 @@ static bool ufs_features_allow_write(struct super_block *sb)
return false;
}
}
+ if ((fsflags & UFS_FS_METACKHASH) &&
+ fs32_to_cpu(sb, usb3->fs_un2.fs_44.fs_metackhash)) {
+ pr_err("%s(): fs uses metadata check hashes\n", __func__);
+ return false;
+ }
return true;
}
--
2.55.0
prev parent reply other threads:[~2026-08-01 22:56 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-01 22:55 [PATCH 00/10] ufs: correctness fixes for valid on-disk filesystems Ali Ahmet Memis
2026-08-01 22:55 ` [PATCH 01/10] ufs: name the modern UFS2 superblock fields Ali Ahmet Memis
2026-08-01 22:55 ` [PATCH 02/10] ufs: use i_size to detect fast symlinks Ali Ahmet Memis
2026-08-01 22:55 ` [PATCH 03/10] ufs: free UFS2 external attribute blocks on inode deletion Ali Ahmet Memis
2026-08-01 22:55 ` [PATCH 04/10] ufs: do not inherit file flags from the parent directory Ali Ahmet Memis
2026-08-01 22:55 ` [PATCH 05/10] ufs: honour on-disk immutable and append-only flags Ali Ahmet Memis
2026-08-01 22:55 ` [PATCH 06/10] ufs: fix fragment relocation offsets within a folio Ali Ahmet Memis
2026-08-01 22:55 ` [PATCH 07/10] ufs: revalidate filesystem state before remounting read-write Ali Ahmet Memis
2026-08-01 22:55 ` [PATCH 08/10] ufs: refuse read-write mount when fsck or journal replay is needed Ali Ahmet Memis
2026-08-01 22:55 ` [PATCH 09/10] ufs: refuse read-write mount of filesystems with active snapshots Ali Ahmet Memis
2026-08-01 22:55 ` Ali Ahmet Memis [this message]
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=20260801225530.148386-11-ali@iusegentoo.com \
--to=ali@iusegentoo.com \
--cc=brauner@kernel.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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
all inboxes | Powered by JetHome®