From: Raphael Pinsonneault-Thibeault <rpthibeault@gmail.com>
To: cem@kernel.org
Cc: chandanbabu@kernel.org, djwong@kernel.org, bfoster@redhat.com,
david@fromorbit.com, linux-xfs@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-kernel-mentees@lists.linux.dev,
syzbot+9f6d080dece587cfdd4c@syzkaller.appspotmail.com,
Raphael Pinsonneault-Thibeault <rpthibeault@gmail.com>
Subject: [PATCH v4] xfs: validate log record version against superblock log version
Date: Wed, 19 Nov 2025 10:37:22 -0500 [thread overview]
Message-ID: <20251119153721.2765700-2-rpthibeault@gmail.com> (raw)
In-Reply-To: <aRzU0yjBfQ3CjWpp@dread.disaster.area>
Syzbot creates a fuzzed record where xfs_has_logv2() but the
xlog_rec_header h_version != XLOG_VERSION_2. This causes a
KASAN: slab-out-of-bounds read in xlog_do_recovery_pass() ->
xlog_recover_process() -> xlog_cksum().
Fix by adding a check to xlog_valid_rec_header() to abort journal
recovery if the xlog_rec_header h_version does not match the super
block log version.
A file system with a version 2 log will only ever set
XLOG_VERSION_2 in its headers (and v1 will only ever set V_1), so if
there is any mismatch, either the journal or the superblock has been
corrupted and therefore we abort processing with a -EFSCORRUPTED error
immediately.
Also, refactor the structure of the validity checks for better
readability. At the default error level (LOW), XFS_IS_CORRUPT() emits
the condition that failed, the file and line number it is
located at, then dumps the stack. This gives us everything we need
to know about the failure if we do a single validity check per
XFS_IS_CORRUPT().
Reported-by: syzbot+9f6d080dece587cfdd4c@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=9f6d080dece587cfdd4c
Tested-by: syzbot+9f6d080dece587cfdd4c@syzkaller.appspotmail.com
Fixes: 45cf976008dd ("xfs: fix log recovery buffer allocation for the legacy h_size fixup")
Signed-off-by: Raphael Pinsonneault-Thibeault <rpthibeault@gmail.com>
---
changelog
v1 -> v2:
- reject the mount for h_size > XLOG_HEADER_CYCLE_SIZE && !XLOG_VERSION_2
v2 -> v3:
- abort journal recovery if the xlog_rec_header h_version does not
match the super block log version
v3 -> v4:
- refactor for readability
fs/xfs/xfs_log_recover.c | 31 ++++++++++++++++++++-----------
1 file changed, 20 insertions(+), 11 deletions(-)
diff --git a/fs/xfs/xfs_log_recover.c b/fs/xfs/xfs_log_recover.c
index e6ed9e09c027..f5f28755b2ff 100644
--- a/fs/xfs/xfs_log_recover.c
+++ b/fs/xfs/xfs_log_recover.c
@@ -2950,31 +2950,40 @@ xlog_valid_rec_header(
xfs_daddr_t blkno,
int bufsize)
{
+ struct xfs_mount *mp = log->l_mp;
+ u32 h_version = be32_to_cpu(rhead->h_version);
int hlen;
- if (XFS_IS_CORRUPT(log->l_mp,
+ if (XFS_IS_CORRUPT(mp,
rhead->h_magicno != cpu_to_be32(XLOG_HEADER_MAGIC_NUM)))
return -EFSCORRUPTED;
- if (XFS_IS_CORRUPT(log->l_mp,
- (!rhead->h_version ||
- (be32_to_cpu(rhead->h_version) &
- (~XLOG_VERSION_OKBITS))))) {
- xfs_warn(log->l_mp, "%s: unrecognised log version (%d).",
- __func__, be32_to_cpu(rhead->h_version));
+
+ if (XFS_IS_CORRUPT(mp, !h_version))
return -EFSCORRUPTED;
- }
+ if (XFS_IS_CORRUPT(mp, (h_version & ~XLOG_VERSION_OKBITS)))
+ return -EFSCORRUPTED;
+
+ /*
+ * the log version is known, but must match the superblock log
+ * version feature bits for the header to be considered valid
+ */
+ if (xfs_has_logv2(mp)) {
+ if (XFS_IS_CORRUPT(mp, !(h_version & XLOG_VERSION_2)))
+ return -EFSCORRUPTED;
+ } else if (XFS_IS_CORRUPT(mp, !(h_version & XLOG_VERSION_1)))
+ return -EFSCORRUPTED;
/*
* LR body must have data (or it wouldn't have been written)
* and h_len must not be greater than LR buffer size.
*/
hlen = be32_to_cpu(rhead->h_len);
- if (XFS_IS_CORRUPT(log->l_mp, hlen <= 0 || hlen > bufsize))
+ if (XFS_IS_CORRUPT(mp, hlen <= 0 || hlen > bufsize))
return -EFSCORRUPTED;
- if (XFS_IS_CORRUPT(log->l_mp,
- blkno > log->l_logBBsize || blkno > INT_MAX))
+ if (XFS_IS_CORRUPT(mp, blkno > log->l_logBBsize || blkno > INT_MAX))
return -EFSCORRUPTED;
+
return 0;
}
--
2.43.0
next prev parent reply other threads:[~2025-11-19 15:40 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-12 14:10 [PATCH] xfs: ensure log recovery buffer is resized to avoid OOB Raphael Pinsonneault-Thibeault
2025-11-12 15:28 ` Christoph Hellwig
2025-11-12 18:18 ` [PATCH] xfs: reject log records with v2 size but v1 header version " Raphael Pinsonneault-Thibeault
2025-11-12 18:45 ` Darrick J. Wong
2025-11-13 6:55 ` Christoph Hellwig
2025-11-12 22:19 ` [PATCH] xfs: ensure log recovery buffer is resized " Dave Chinner
2025-11-13 19:01 ` [PATCH v3] xfs: validate log record version against superblock log version Raphael Pinsonneault-Thibeault
2025-11-18 20:19 ` Dave Chinner
2025-11-19 15:37 ` Raphael Pinsonneault-Thibeault [this message]
2025-11-19 20:16 ` [PATCH v4] " Dave Chinner
2025-11-20 6:57 ` Christoph Hellwig
2025-11-24 17:47 ` [PATCH v5] " Raphael Pinsonneault-Thibeault
2025-11-24 18:52 ` Darrick J. Wong
2025-11-25 6:31 ` Christoph Hellwig
2025-11-25 17:06 ` Darrick J. Wong
2025-11-25 6:31 ` Christoph Hellwig
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=20251119153721.2765700-2-rpthibeault@gmail.com \
--to=rpthibeault@gmail.com \
--cc=bfoster@redhat.com \
--cc=cem@kernel.org \
--cc=chandanbabu@kernel.org \
--cc=david@fromorbit.com \
--cc=djwong@kernel.org \
--cc=linux-kernel-mentees@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=syzbot+9f6d080dece587cfdd4c@syzkaller.appspotmail.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