From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-119.freemail.mail.aliyun.com (out30-119.freemail.mail.aliyun.com [115.124.30.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E185D21CC51 for ; Mon, 11 May 2026 06:30:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.119 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778481010; cv=none; b=K7wVryufgkJXr4xzL0dcXn2Mu/cS7/GAcgBREqd5ilm5Cug2jldleKrvkRF3ZPOmN2CXACSxRE1vPahDv7X2K92jLZEcFs8aX07Y6e5pWFfl2Fm+wv3U49E1P/P9nuNhpGOhks1S4wxM1tuKlsWTemsDMoD/DmA2WM2FXZIyF3Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778481010; c=relaxed/simple; bh=RQfspkujNbsrNp4kmxdzXYeln0u5Scv8wzIgV9MFlUQ=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=OoCvKPv2EPx8ZvTbByugRuN2Pj4pNe65PQbDG46ZeuNpdDHQDDpM6+7ORPAVEByhaH0NKcjVd1XYN9lGmcwx433/13U/K4OQ9VAJ+nP+1I9xuZoUyOu5T0anBR2jDQJq97PKR7SIPslVzNMQ1cTNjpoWANAnMuwc/mHiFXzdfqA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=UTk87WjS; arc=none smtp.client-ip=115.124.30.119 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="UTk87WjS" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1778481006; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=NnP3IIBIJeiWGTdtsTfmcFDWpZNPBU+hGUJqL1qXHq4=; b=UTk87WjS42CL+/Muhr/wqWGWgMTQT/on9hULq1yctEtY+LGC8/bsLVmauflD5yJDPjnnSpUlXW9nA4TVVcfc+RAZIU+Hlk9WdqiM4UX/A9KJ0Zbz9DP027ioBricux7DztKnoJzgEOFKHAmY8vTJ4BrJ6JMOFvmnFjpnRvjnjxA= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R591e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033032089153;MF=joseph.qi@linux.alibaba.com;NM=1;PH=DS;RN=9;SR=0;TI=SMTPD_---0X2fE5H5_1778481005; Received: from 30.221.128.206(mailfrom:joseph.qi@linux.alibaba.com fp:SMTPD_---0X2fE5H5_1778481005 cluster:ay36) by smtp.aliyun-inc.com; Mon, 11 May 2026 14:30:05 +0800 Message-ID: <79f645c2-b97f-4c0f-8ba7-8e0ef541d455@linux.alibaba.com> Date: Mon, 11 May 2026 14:30:04 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/5] ocfs2: validate inline xattr header before checking outside values To: ZhengYuan Huang , akpm Cc: ocfs2-devel@lists.linux.dev, linux-kernel@vger.kernel.org, baijiaju1990@gmail.com, r33s3n6@gmail.com, zzzccc427@gmail.com, Mark Fasheh , Joel Becker References: <20260508085914.61647-1-gality369@gmail.com> <20260508085914.61647-3-gality369@gmail.com> From: Joseph Qi In-Reply-To: <20260508085914.61647-3-gality369@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 5/8/26 4:59 PM, ZhengYuan Huang wrote: > [BUG] > A corrupt inline xattr header can make > ocfs2_has_inline_xattr_value_outside() walk xh_count from an unchecked > header while refcount-tree teardown decides whether inline xattrs still > point outside the inode body. > > [CAUSE] > ocfs2_has_inline_xattr_value_outside() still computed the inline header > directly from di->i_xattr_inline_size and immediately iterated xh_count. > That is the same unchecked metadata boundary as the ibody lookup bug. > > [FIX] > Reuse the shared inline-header helper before iterating xh_count. Because > this helper returns a boolean-style answer to its caller, treat a corrupt > header conservatively as "has outside values" instead of walking it. > > Signed-off-by: ZhengYuan Huang Looks fine. Reviewed-by: Joseph Qi > --- > fs/ocfs2/xattr.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/fs/ocfs2/xattr.c b/fs/ocfs2/xattr.c > index 3a5a17cdcf7e..05f6f0a886cf 100644 > --- a/fs/ocfs2/xattr.c > +++ b/fs/ocfs2/xattr.c > @@ -989,11 +989,12 @@ int ocfs2_has_inline_xattr_value_outside(struct inode *inode, > struct ocfs2_dinode *di) > { > struct ocfs2_xattr_header *xh; > + int ret; > int i; > > - xh = (struct ocfs2_xattr_header *) > - ((void *)di + inode->i_sb->s_blocksize - > - le16_to_cpu(di->i_xattr_inline_size)); > + ret = ocfs2_xattr_ibody_lookup_header(inode, di, &xh); > + if (ret) > + return 1; > > for (i = 0; i < le16_to_cpu(xh->xh_count); i++) > if (!ocfs2_xattr_is_local(&xh->xh_entries[i]))