From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=115.124.30.100 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1792854629; b=MHMGo99XexkrHOd7CGbsNUkDCxEStIRWNsilENgEVk/RTczUwAcExiF0SmvWNSEjQJ4c /VuAEXkg4QPbXRL5NAiBjRkVk7Ln4qR1/j4ewNNCrAscJsJIaUrlt8UZ/ojSSwwECiFAC zuesrBCUSTyqC/DmeuzxerTqgVcnK5K2OGCQ/GHjcRDiROuK1ybCaCXpPcN8YZLc1TEpc wFKyHceu+sThWjOqnt4WSK5YCp1U9zpp9gSCt9fXqFJHd9WD9blT2OrelBpmGuy0jj6qQ IxBmKkNI+nW8b+3w3OGm2+lzUaP88XRxOXOpdIraxX4uXXeW99f9nDyafuXGNFlB5xQ== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1792854629; h=DMARC-Filter:DKIM-Signature:X-Alimail-AntiSpam:Received:From:To:Cc: Subject:Date:Message-Id:X-Mailer:In-Reply-To:References:MIME-Version: Content-Transfer-Encoding; bh=ryanL2dbdeecwzZPf9Ejq3ZeRrQmdc2FE6i0mK67jZY=; b=OU5KWU1jWGZghACg8lojorKn8363A5yegwSGrAW4iJCzsuDkm9UUWntt1ioRW5haPsSj 7L/IgITfyOuFgzapNlk1GBiwlvWpN6uHpKzqwtDH4SjypzlX2yw94fH9CNPotwtRif2Nf 6lAuW8YXci9WvZO8FogOwgogK1Y0+IUv5VXFqTOK2mqb6Z59MIANPYlqRY1kuF+xaO/Ug 1gRDEJTeiZbj2vvP/SpXXozYcBj3oTsNoeQjIeK+PyyfzNeY8h7HFPXeMqd727nTihIyi aaq5WYbrGjIwUbN/tw40mTf7p4JTXLN2AeHDDNERO8E98ShmLcH2MxR3P5lh9nlFEWA== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass header.d=linux.alibaba.com header.i=@linux.alibaba.com header.a=rsa-sha256 header.s=default header.b=Yrxp06rU; arc=none smtp.remote-ip=115.124.30.100 Received: from out30-100.freemail.mail.aliyun.com (out30-100.freemail.mail.aliyun.com [115.124.30.100]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2528560A2606 for ; Sat, 24 Oct 2026 15:10:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 2528560A2606 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, unprotected) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.a=rsa-sha256 header.s=default header.b=Yrxp06rU DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1792854618; h=From:To:Subject:Date:Message-Id:MIME-Version; bh=ryanL2dbdeecwzZPf9Ejq3ZeRrQmdc2FE6i0mK67jZY=; b=Yrxp06rUQCF5eDYlHBMqDjaApdE1SHXmK4/KZOtTMZJJuQoiv4eWQgC/P1vRhPoJvbqrqAP16DNeZR8nOik4tc7NVJXlO+Yn6VxjzufaexWzk74MWTJqRhIs+Py3/8Ax9d1hPoSfheqBozWkgy6J/U13QpF20RgMFi3DU2aWZtA= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R691e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033045133197;MF=joseph.qi@linux.alibaba.com;NM=1;PH=DS;RN=6;SR=0;TI=SMTPD_---0XDORGhn_1792854617; Received: from localhost(mailfrom:joseph.qi@linux.alibaba.com fp:SMTPD_---0XDORGhn_1792854617 cluster:ay36) by smtp.aliyun-inc.com; Sat, 24 Oct 2026 23:10:18 +0800 From: Joseph Qi To: Andrew Morton , Heming Zhao Cc: Mark Fasheh , Joel Becker , ocfs2-devel@lists.linux.dev, linux-kernel@vger.kernel.org Subject: [PATCH 6/6] ocfs2: do not read the entry array of an empty xattr block Date: Sat, 24 Oct 2026 23:10:12 +0800 Message-Id: <20261024151012.1059683-7-joseph.qi@linux.alibaba.com> X-Mailer: git-send-email 2.39.3 In-Reply-To: <20261024151012.1059683-1-joseph.qi@linux.alibaba.com> References: <20261024151012.1059683-1-joseph.qi@linux.alibaba.com> X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: 8bit ocfs2_cp_xattr_block_to_bucket() sizes the name and value area it has to carry over from the block's last entry, so an empty block makes it read xh_entries[-1]. That lands on the header, where xe_name_offset overlaps xh_name_value_len, and block storage never maintains that field, so it reads as 0 and the copy runs from the header to the end of the block. The bucket that comes out has xh_count 0 but a name_value_len of blocksize less the header, and a matching xh_free_start that claims those bytes are in use -- nearly the whole bucket with the common 4K block size -- while the last block of the bucket holds a copy of the old block's bytes. Nothing but a trace event reads xh_name_value_len, the copied bytes came from the same inode and were wiped before the entry was removed, and ocfs2_defrag_xattr_bucket() recomputes xh_free_start, so this corrupts the header rather than leaking anything. Leave the bucket empty instead, carrying over the hash the block was keyed by, since ocfs2_add_new_xattr_bucket() and ocfs2_xattr_bucket_find() both read xh_entries[0] of an empty bucket. That read is the exception ocfs2_xa_remove_entry() documents rather than a new out of bounds access. A block reaches the conversion empty when truncating an external value back fails partway through: the "reusing" and "overwriting" callers of ocfs2_xa_cleanup_value_truncate() remove the entry without setting ctxt->set_abort, so ocfs2_xattr_block_set() sees a plain -ENOSPC and converts. The "growing" caller does set it, and the block form makes a single attempt with no defragment and retry in between, so that is the only route here. Fixes: 012255961c9e ("ocfs2: Enable xattr set in index btree") Cc: Signed-off-by: Joseph Qi --- fs/ocfs2/xattr.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/fs/ocfs2/xattr.c b/fs/ocfs2/xattr.c index 822b1e9c3ba2..ac41653e59f5 100644 --- a/fs/ocfs2/xattr.c +++ b/fs/ocfs2/xattr.c @@ -4704,6 +4704,21 @@ static void ocfs2_cp_xattr_block_to_bucket(struct inode *inode, for (i = 0; i < blks; i++) memset(bucket_block(bucket, i), 0, blocksize); + /* + * An empty block has no names or values to carry over, and the + * xh_entries[count - 1] below would be xh_entries[-1]. Leave the + * bucket empty, but carry over the hash ocfs2_xa_remove_entry() left + * in the block's xh_entries[0] so that the bucket still holds the key + * it is looked up by. + */ + if (!count) { + xh->xh_num_buckets = cpu_to_le16(1); + xh->xh_free_start = cpu_to_le16(OCFS2_XATTR_BUCKET_SIZE); + xh->xh_entries[0].xe_name_hash = + xb_xh->xh_entries[0].xe_name_hash; + return; + } + /* * Since the xe_name_offset is based on ocfs2_xattr_header, * there is a offset change corresponding to the change of -- 2.39.3