Linux XFS filesystem development
 help / color / mirror / Atom feed
From: Dave Chinner <dgc@kernel.org>
To: David Lee <david.lee@trailofbits.com>
Cc: cem@kernel.org, Kyle Zeng <kylebot@openai.com>,
	Dominik 'Disconnect3d' Czarnota
	<dominik.czarnota@trailofbits.com>,
	linux-xfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] xfs: validate btree block level on read
Date: Sat, 1 Aug 2026 09:28:32 +1000	[thread overview]
Message-ID: <am0voArOlA31WBC3@dread> (raw)
In-Reply-To: <20260731120344.558808-1-david.lee@trailofbits.com>

On Fri, Jul 31, 2026 at 12:03:42PM +0000, David Lee wrote:
> Btree buffer verifiers validate record counts against the level stored in
> the block itself.  Callers of xfs_btree_read_buf_block(), however, use
> the returned block according to the level they are traversing.  A
> corrupted sibling pointer can therefore return a verifier-valid block
> from another level and cause out-of-bounds accesses when layout-specific
> entries are moved.
> 
> Pass the expected level into xfs_btree_read_buf_block() and reject
> blocks whose on-disk level differs before returning them.  This
> centralizes the check for traversal and sibling reads.

We already have a centralised function that does all this level
check (and more): xfs_btree_lookup_get_block(). It is already passed
the expected level, and it also checks various other per-usage
header information like owner, level specific numrecs bounds, etc.

If we have to verify per-block context state, then nothing should be
calling xfs_btree_read_buf_block() directly except
xfs_btree_lookup_get_block(), and all the read context checks should
be performed in xfs_btree_lookup_get_block() (as they already are).

> Fixes: 3d3e6f64e22c ("xfs: verify btree blocks as they are read from disk")
> Bug found and triaged by OpenAI Security Research and 
> validated by Trail of Bits.

Great. How did you reproduce the issue and test the fix is correct?
Did you submit an fstests that reproduces the issue and verifies the
fix works?

> Assisted-by: Codex:gpt-5.6-sol gpt-5.5-cyber
> Signed-off-by: Kyle Zeng <kylebot@openai.com>

Yeah, nah. Patches have to be submitted by a real person, not a bot
account, and SOB should reflect that.

-Dave.
-- 
Dave Chinner
dgc@kernel.org

      reply	other threads:[~2026-07-31 23:28 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-31 12:03 [PATCH] xfs: validate btree block level on read David Lee
2026-07-31 23:28 ` Dave Chinner [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=am0voArOlA31WBC3@dread \
    --to=dgc@kernel.org \
    --cc=cem@kernel.org \
    --cc=david.lee@trailofbits.com \
    --cc=dominik.czarnota@trailofbits.com \
    --cc=kylebot@openai.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    /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