All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Long Li <leo.lilong@huawei.com>
Cc: cem@kernel.org, linux-xfs@vger.kernel.org, david@fromorbit.com,
	yi.zhang@huawei.com, houtao1@huawei.com, yangerkun@huawei.com,
	lonuxli.64@gmail.com
Subject: Re: [PATCH 2/3] xfs: fix ri_total validation in xlog_recover_attri_commit_pass2
Date: Mon, 16 Mar 2026 15:39:21 -0700	[thread overview]
Message-ID: <20260316223921.GD1770774@frogsfrogsfrogs> (raw)
In-Reply-To: <20260316012416.2413909-3-leo.lilong@huawei.com>

On Mon, Mar 16, 2026 at 09:24:15AM +0800, Long Li wrote:
> The ri_total checks for SET/REPLACE operations are hardcoded to 3,
> but xfs_attri_item_size() only emits a value iovec when value_len > 0,
> so ri_total is 2 when value_len == 0.

When can you have a set/replace operation with no value?  Is this the
weird case where you're trying to set an attr to zero-length buffer?

--D

> For PPTR_SET/PPTR_REMOVE/PPTR_REPLACE, value_len is validated by
> xfs_attri_validate() to be exactly sizeof(struct xfs_parent_rec) and
> is never zero, so their hardcoded checks remain correct.
> 
> Fix this by deriving the expected count dynamically as "2 + !!value_len"
> for SET/REPLACE operations.
> 
> Cc: <stable@vger.kernel.org> # v6.9
> Fixes: ad206ae50eca ("xfs: check opcode and iovec count match in xlog_recover_attri_commit_pass2")
> Signed-off-by: Long Li <leo.lilong@huawei.com>
> ---
>  fs/xfs/xfs_attr_item.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/xfs/xfs_attr_item.c b/fs/xfs/xfs_attr_item.c
> index 3d3ac8dad519..21da995ba4e7 100644
> --- a/fs/xfs/xfs_attr_item.c
> +++ b/fs/xfs/xfs_attr_item.c
> @@ -1049,7 +1049,7 @@ xlog_recover_attri_commit_pass2(
>  	case XFS_ATTRI_OP_FLAGS_SET:
>  	case XFS_ATTRI_OP_FLAGS_REPLACE:
>  		/* Log item, attr name, attr value */
> -		if (item->ri_total != 3) {
> +		if (item->ri_total != 2 + !!attri_formatp->alfi_value_len) {
>  			XFS_CORRUPTION_ERROR(__func__, XFS_ERRLEVEL_LOW, mp,
>  					     attri_formatp, len);
>  			return -EFSCORRUPTED;
> -- 
> 2.39.2
> 
> 

  reply	other threads:[~2026-03-16 22:39 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-16  1:24 [PATCH 0/3] xfs: fixes and clean up for attr item Long Li
2026-03-16  1:24 ` [PATCH 1/3] xfs: fix possible null pointer dereference in xfs_attri_recover_work Long Li
2026-03-16 22:33   ` Darrick J. Wong
2026-03-17  2:19     ` Long Li
2026-03-16  1:24 ` [PATCH 2/3] xfs: fix ri_total validation in xlog_recover_attri_commit_pass2 Long Li
2026-03-16 22:39   ` Darrick J. Wong [this message]
2026-03-17  2:14     ` Long Li
2026-03-16  1:24 ` [PATCH 3/3] xfs: simplify iovec " Long Li
2026-03-16 22:46   ` Darrick J. Wong
2026-03-17  2:33     ` Long Li

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=20260316223921.GD1770774@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=cem@kernel.org \
    --cc=david@fromorbit.com \
    --cc=houtao1@huawei.com \
    --cc=leo.lilong@huawei.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=lonuxli.64@gmail.com \
    --cc=yangerkun@huawei.com \
    --cc=yi.zhang@huawei.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.