From: Joseph Qi <joseph.qi@linux.alibaba.com>
To: ZhengYuan Huang <gality369@gmail.com>
Cc: mark@fasheh.com, jlbec@evilplan.org, ocfs2-devel@lists.linux.dev,
linux-kernel@vger.kernel.org, baijiaju1990@gmail.com,
r33s3n6@gmail.com, zzzccc427@gmail.com
Subject: Re: [PATCH] ocfs2: reject inconsistent local xattr entries
Date: Wed, 5 Aug 2026 19:57:13 +0800 [thread overview]
Message-ID: <f23fdf09-6e6a-4291-a47d-fb86705fd206@linux.alibaba.com> (raw)
In-Reply-To: <20260804112806.1219362-1-gality369@gmail.com>
This conflicts with the following commit in linux-next:
ocfs2: fix circular locking dependency in ocfs2_init_acl()
Thanks,
Joseph
On 8/4/26 7:28 PM, ZhengYuan Huang wrote:
> [BUG]
> A corrupt OCFS2 xattr entry can set OCFS2_XATTR_ENTRY_LOCAL while
> keeping xe_value_size larger than OCFS2_XATTR_INLINE_SIZE.Once
> that entry reaches namevalue_size_xe(), the filesystem trips over:
>
> kernel BUG at fs/ocfs2/xattr.c:231!
> Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI
> RIP: 0010:namevalue_size_xe fs/ocfs2/xattr.c:231 [inline]
> RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2e4/0x330 fs/ocfs2/xattr.c:1638
> Call Trace:
> ocfs2_xa_wipe_namevalue fs/ocfs2/xattr.c:1470 [inline]
> ocfs2_xa_remove_entry+0xae/0x1d0 fs/ocfs2/xattr.c:1941
> ocfs2_xa_remove fs/ocfs2/xattr.c:2043 [inline]
> ocfs2_xa_set+0x11a8/0x30a0 fs/ocfs2/xattr.c:2247
> ocfs2_xattr_ibody_set+0x302/0xc50 fs/ocfs2/xattr.c:2795
> __ocfs2_xattr_set_handle+0x7e6/0xdb0 fs/ocfs2/xattr.c:3416
> ocfs2_xattr_set+0x1447/0x2610 fs/ocfs2/xattr.c:3650
> ocfs2_xattr_security_set+0x37/0x50 fs/ocfs2/xattr.c:7241
> __vfs_removexattr+0x14d/0x1d0 fs/xattr.c:518
> cap_inode_killpriv+0x29/0x50 security/commoncap.c:355
> security_inode_killpriv+0x105/0x220 security/security.c:2724
> setattr_prepare+0x147/0x8a0 fs/attr.c:219
> ocfs2_setattr+0x504/0x1fd0 fs/ocfs2/file.c:1148
> notify_change+0x4b5/0x1030 fs/attr.c:546
> do_truncate+0x1d2/0x230 fs/open.c:68
> handle_truncate fs/namei.c:3596 [inline]
> do_open fs/namei.c:3979 [inline]
> path_openat+0x260f/0x2ce0 fs/namei.c:4134
> do_filp_open+0x1f6/0x430 fs/namei.c:4161
> do_sys_openat2+0x117/0x1c0 fs/open.c:1437
> ...
>
> [CAUSE]
> namevalue_size_xe() assumes on-disk xattr entries keep the local flag
> and value size consistent, but OCFS2 does not reject an entry that
> claims local storage for a value larger than the inline limit before
> handing that entry to namevalue_size_xe().
>
> The exact-match lookup path can return such an entry through xs->here,
> and bucket defragmentation and splitting can also walk the corrupt entry
> directly while reorganizing metadata.
>
> [FIX]
> Add a small validator for the local/value_size invariant and call it in
> the paths that feed disk entries to namevalue_size_xe(): exact-match
> lookup, bucket lookup results, bucket defragmentation, and bucket
> splitting.
>
> Corrupt metadata is now reported with ocfs2_error() and -EFSCORRUPTED
> instead of crashing the kernel with BUG_ON().
>
> Signed-off-by: ZhengYuan Huang <gality369@gmail.com>
> ---
> No Fixes tag was added because this is more like a defensive check
> that is long overdue, not a regression that can be clearly attributed
> to a specific introduction commit.
> ---
> diff --git a/fs/ocfs2/xattr.c b/fs/ocfs2/xattr.c
> index 86cfd4c2adf9..63b1e55b242f 100644
> --- a/fs/ocfs2/xattr.c
> +++ b/fs/ocfs2/xattr.c
> @@ -237,6 +237,23 @@ static int namevalue_size_xe(struct ocfs2_xattr_entry *xe)
> return namevalue_size(xe->xe_name_len, value_len);
> }
>
> +static int ocfs2_validate_xattr_entry(struct inode *inode,
> + struct ocfs2_xattr_entry *xe)
> +{
> + u64 value_len = le64_to_cpu(xe->xe_value_size);
> +
> + if (value_len > OCFS2_XATTR_INLINE_SIZE &&
> + ocfs2_xattr_is_local(xe)) {
> + ocfs2_error(inode->i_sb,
> + "Inode %llu has corrupt xattr entry: local value_size %llu\n",
> + (unsigned long long)OCFS2_I(inode)->ip_blkno,
> + value_len);
> + return -EFSCORRUPTED;
> + }
> +
> + return 0;
> +}
> +
>
> static int ocfs2_xattr_bucket_get_name_value(struct super_block *sb,
> struct ocfs2_xattr_header *xh,
> @@ -1099,6 +1116,7 @@ static int ocfs2_xattr_find_entry(struct inode *inode, int name_index,
> struct ocfs2_xattr_entry *entry;
> size_t name_len;
> int i, name_offset, cmp = 1;
> + int ret;
>
> if (name == NULL)
> return -EINVAL;
> @@ -1121,6 +1139,11 @@ static int ocfs2_xattr_find_entry(struct inode *inode, int name_index,
> return -EFSCORRUPTED;
> }
> cmp = memcmp(name, (xs->base + name_offset), name_len);
> + if (!cmp) {
> + ret = ocfs2_validate_xattr_entry(inode, entry);
> + if (ret)
> + return ret;
> + }
> }
> if (cmp == 0)
> break;
> @@ -3823,6 +3846,9 @@ static int ocfs2_find_xe_in_bucket(struct inode *inode,
>
> xe_name = bucket_block(bucket, block_off) + new_offset;
> if (!memcmp(name, xe_name, name_len)) {
> + ret = ocfs2_validate_xattr_entry(inode, xe);
> + if (ret)
> + break;
> *xe_index = i;
> *found = 1;
> ret = 0;
> @@ -4463,6 +4489,10 @@ static int ocfs2_defrag_xattr_bucket(struct inode *inode,
> xe = xh->xh_entries;
> end = OCFS2_XATTR_BUCKET_SIZE;
> for (i = 0; i < le16_to_cpu(xh->xh_count); i++, xe++) {
> + ret = ocfs2_validate_xattr_entry(inode, xe);
> + if (ret)
> + goto out;
> +
> offset = le16_to_cpu(xe->xe_name_offset);
> len = namevalue_size_xe(xe);
>
> @@ -4745,6 +4775,10 @@ static int ocfs2_divide_xattr_bucket(struct inode *inode,
> name_value_len = 0;
> for (i = 0; i < start; i++) {
> xe = &xh->xh_entries[i];
> + ret = ocfs2_validate_xattr_entry(inode, xe);
> + if (ret)
> + goto out;
> +
> name_value_len += namevalue_size_xe(xe);
> if (le16_to_cpu(xe->xe_name_offset) < name_offset)
> name_offset = le16_to_cpu(xe->xe_name_offset);
next prev parent reply other threads:[~2026-08-05 11:57 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-04 11:28 [PATCH] ocfs2: reject inconsistent local xattr entries ZhengYuan Huang
2026-08-05 11:57 ` Joseph Qi [this message]
-- strict thread matches above, loose matches on Subject: below --
2026-04-16 4:48 gality369
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=f23fdf09-6e6a-4291-a47d-fb86705fd206@linux.alibaba.com \
--to=joseph.qi@linux.alibaba.com \
--cc=baijiaju1990@gmail.com \
--cc=gality369@gmail.com \
--cc=jlbec@evilplan.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark@fasheh.com \
--cc=ocfs2-devel@lists.linux.dev \
--cc=r33s3n6@gmail.com \
--cc=zzzccc427@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 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.