mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Joseph Qi <joseph.qi@linux.alibaba.com>
To: Andrew Morton <akpm@linux-foundation.org>,
	Heming Zhao <heming.zhao@suse.com>
Cc: Mark Fasheh <mark@fasheh.com>, Joel Becker <jlbec@evilplan.org>,
	ocfs2-devel@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: [PATCH 0/4] ocfs2: validate suballoc slot and bit of metadata blocks
Date: Mon, 31 Aug 2026 14:28:44 +0800	[thread overview]
Message-ID: <20260831062848.2743436-1-joseph.qi@linux.alibaba.com> (raw)

ocfs2 metadata validators trust the on-disk suballoc slot (and the
dinode suballoc bit) without checking them against the mounted
filesystem's slot range.  A corrupted image can carry
OCFS2_INVALID_SLOT or another out-of-range value; when the
corresponding inode, extent block, xattr block, or dir index root is
later freed, the unvalidated slot/bit is passed to
ocfs2_get_system_file_inode() or _ocfs2_free_suballoc_bits() and hits
BUG_ON() or indexes local_system_inodes[] out of bounds.

Mounting ocfs2 requires privilege (ocfs2 cannot be mounted from a
user namespace), so this needs a privileged mount of a crafted or
corrupted image -- e.g. an administrator mounting untrusted media or a
disk image supplied to a virtual machine.  Once such an image is
mounted, an unprivileged user who can delete the corrupted object
triggers the crash.

This series rejects such values at read time, in the existing
validators, so corrupted objects fail with -EROFS (and a read-only
remount) instead of crashing:

  patch 1 restricts OCFS2_INVALID_SLOT dinodes to system inodes,
        completing fe7a283b3916 ("ocfs2: add suballoc slot check in
        ocfs2_validate_inode_block()");
  patch 2 rejects oversized dinode suballoc bits;
  patch 3 validates the suballoc slot of xattr and dir index blocks;
  patch 4 validates the suballoc slot of extent blocks.

All checks match what the kernel itself writes (always a valid slot
from meta_ac->ac_alloc_slot) and what mkfs.ocfs2/libocfs2 write
(system inodes carry OCFS2_INVALID_SLOT with OCFS2_SYSTEM_FL, extent
blocks carry slot 0), so legitimate filesystems are unaffected.

Tested with negative corruption testing under QEMU: for each new
check a test image was generated with the field overwritten by an
out-of-range value; with the series applied the access fails cleanly
with -EROFS and the filesystem remounts read-only instead of hitting
BUG_ON().

Joseph Qi (4):
  ocfs2: restrict OCFS2_INVALID_SLOT suballoc slot to system inodes
  ocfs2: validate suballoc bit during inode read
  ocfs2: validate suballoc slot of xattr and dir index blocks
  ocfs2: validate suballoc slot of extent blocks

 fs/ocfs2/alloc.c | 14 ++++++++++++++
 fs/ocfs2/dir.c   | 14 ++++++++++++++
 fs/ocfs2/inode.c | 33 +++++++++++++++++++++++++++++++--
 fs/ocfs2/xattr.c | 13 +++++++++++++
 4 files changed, 72 insertions(+), 2 deletions(-)

-- 
2.39.3


             reply	other threads:[~2026-08-31  6:28 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-31  6:28 Joseph Qi [this message]
2026-08-31  6:28 ` [PATCH 1/4] ocfs2: restrict OCFS2_INVALID_SLOT suballoc slot to system inodes Joseph Qi
2026-08-31 14:02   ` Heming Zhao
2026-09-01  1:08     ` Joseph Qi
2026-09-01  1:16       ` Heming Zhao
2026-09-01  2:08         ` Joseph Qi
2026-08-31  6:28 ` [PATCH 2/4] ocfs2: validate suballoc bit during inode read Joseph Qi
2026-08-31 14:03   ` Heming Zhao
2026-08-31  6:28 ` [PATCH 3/4] ocfs2: validate suballoc slot of xattr and dir index blocks Joseph Qi
2026-08-31 14:04   ` Heming Zhao
2026-08-31  6:28 ` [PATCH 4/4] ocfs2: validate suballoc slot of extent blocks Joseph Qi
2026-08-31 14:04   ` Heming Zhao

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=20260831062848.2743436-1-joseph.qi@linux.alibaba.com \
    --to=joseph.qi@linux.alibaba.com \
    --cc=akpm@linux-foundation.org \
    --cc=heming.zhao@suse.com \
    --cc=jlbec@evilplan.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark@fasheh.com \
    --cc=ocfs2-devel@lists.linux.dev \
    /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®