public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: lei lu <llfamsec@gmail.com>
Cc: djwong@kernel.org, linux-xfs@vger.kernel.org, chandan.babu@oracle.com
Subject: Re: [PATCH] xfs: don't walk off the end of a directory data block
Date: Mon, 3 Jun 2024 15:58:18 +1000	[thread overview]
Message-ID: <Zl1bequjV5u9QjXD@dread.disaster.area> (raw)
In-Reply-To: <CAEBF3_ayLsCJVPdZQCb=gHtiFCNG9C3xcGv4_cnUpmS8TQRdYw@mail.gmail.com>

On Thu, May 30, 2024 at 11:10:57AM +0800, lei lu wrote:
> Thanks for your time.
> 
> I just add check for the fixed members because I see after the patch
> code there is some checks for dup and dep. "offset +
> be16_to_cpu(dup->length) > end" for dup and "offset +
> xfs_dir2_data_entsize(mp, dep->namelen) > end" for dep.
> “xfs_dir2_data_entsize(mp, dep->namelen)” ensures the alignment of the
> dep.

Sure, but go back and read what I said.

Detect the actual object corruption, not the downstream symptom.

IOWs, the verifier should be detecting the exact corruption you
induced.

Catching all the object corruptions prevents a buffer overrun.
We abort processing before we move beyond the end of the buffer.

IOWs, we need to:

1. verify dup->length is a multiple of XFS_DIR2_DATA_ALIGN; and
2. verify that if the last object in the buffer is less than
   xfs_dir2_data_entsize(mp, 1) bytes in size it must be a dup
   entry of exactly XFS_DIR2_DATA_ALIGN bytes in length.

If either of these checks fail, then the block is corrupt.
#1 will catch your induced corruption and fail immediately.
#2 will catch the runt entry in the structure without derefencing
past the end of the structure.

Can you now see how properly validating that the objects within the
structure will prevent buffer overruns from occurring without
needing generic buffer overrun checks?

-Dave.
-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2024-06-03  5:58 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-29 22:57 [PATCH] xfs: don't walk off the end of a directory data block lei lu
2024-05-30  2:38 ` Dave Chinner
2024-05-30  3:10   ` lei lu
2024-06-03  5:58     ` Dave Chinner [this message]
2024-06-03  7:08       ` lei lu
  -- strict thread matches above, loose matches on Subject: below --
2024-09-24 22:29 [PATCH] xfs: add bounds checking to xlog_recover_process_data Kuntal Nayak
2024-09-24 22:29 ` [PATCH] xfs: don't walk off the end of a directory data block Kuntal Nayak

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=Zl1bequjV5u9QjXD@dread.disaster.area \
    --to=david@fromorbit.com \
    --cc=chandan.babu@oracle.com \
    --cc=djwong@kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=llfamsec@gmail.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