From: Joel Becker <jlbec@evilplan.org>
To: Michael Bommarito <michael.bommarito@gmail.com>
Cc: Joseph Qi <joseph.qi@linux.alibaba.com>,
Mark Fasheh <mark@fasheh.com>,
ZhengYuan Huang <gality369@gmail.com>,
ocfs2-devel@lists.linux.dev, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/3] ocfs2: harden inode validators against forged metadata
Date: Mon, 1 Jun 2026 10:39:09 -0700 [thread overview]
Message-ID: <ah3DvUPLC9AG2q6N@google.com> (raw)
In-Reply-To: <20260517111015.3187935-1-michael.bommarito@gmail.com>
On Sun, May 17, 2026 at 07:10:11AM -0400, Michael Bommarito wrote:
> This series adds three structural checks to
> ocfs2_validate_inode_block() that catch attacker-controlled bytes
> in a freshly read dinode before ocfs2_populate_inode() copies them
> verbatim into the in-core inode. All three checks fire on the
>
> ...
>
> Threat model
> ============
>
> The validator is the chokepoint that protects
> ocfs2_populate_inode() from a malformed dinode whether the
> malformation got there via:
>
> (1) An attacker-supplied disk image mounted by a privileged
> user. The mount path runs every dinode through this
> validator before any unprivileged user opens a file on
> the volume. This is the same threat model the existing
> inline-data, refcount, and chain-list checks in this
> function were written for.
>
> (2) A compromised cluster peer with raw write access to the
> shared block device. OCFS2 is a clustered filesystem;
> the on-disk blocks behind bh->b_data live on shared
> storage that other cluster nodes can write. The local
> node's cache-eviction re-read runs the newly fetched
> block through this validator before ocfs2_populate_inode()
> runs again. Oracle's BlockErrorDetection design document
> scopes the existing CRC32 + Hamming integrity primitive
> explicitly as defense against memory and wire corruption,
> not as authentication of peer writes; the field-level
> validators are therefore the kernel-side defense
> whichever path produced the forged block.
Thank you for the excellent description of the threat model, and for
devising the comprehensive model in the first place. It really helps
consider these patches in the right context.
Can you make sure this info carries on to later versions of this patch
series, so it isn't lost?
Thanks,
Joel
--
"Every day I get up and look through the Forbes list of the richest
people in America. If I'm not there, I go to work."
- Robert Orben
http://www.jlbec.org/
jlbec@evilplan.org
prev parent reply other threads:[~2026-06-01 17:39 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-17 11:10 [PATCH 0/3] ocfs2: harden inode validators against forged metadata Michael Bommarito
2026-05-17 11:10 ` [PATCH 1/3] ocfs2: reject dinodes with non-canonical i_mode type or stray bits Michael Bommarito
2026-05-18 1:36 ` Joseph Qi
2026-05-17 11:10 ` [PATCH 2/3] ocfs2: reject dinodes whose i_rdev disagrees with the file type Michael Bommarito
2026-05-18 1:37 ` Joseph Qi
2026-05-17 11:10 ` [PATCH 3/3] ocfs2: reject regular files with non-zero i_size and zero i_clusters Michael Bommarito
2026-05-18 1:38 ` Joseph Qi
2026-05-18 21:40 ` [PATCH 0/3] ocfs2: harden inode validators against forged metadata Andrew Morton
2026-05-19 0:57 ` Michael Bommarito
2026-06-01 17:39 ` Joel Becker [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=ah3DvUPLC9AG2q6N@google.com \
--to=jlbec@evilplan.org \
--cc=gality369@gmail.com \
--cc=joseph.qi@linux.alibaba.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark@fasheh.com \
--cc=michael.bommarito@gmail.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