From nobody Mon Feb 9 19:47:54 2026 Received: from szxga06-in.huawei.com (szxga06-in.huawei.com [45.249.212.32]) (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 AEB1A13D2AA for ; Wed, 10 Apr 2024 07:46:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.32 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712735189; cv=none; b=LXtDdko8sBmwR7K7Zqq+Vp5P/0I7fY5fRI+rqjlq+qpgjE84Ilz5iCu0F7h9nlXxEhjCkQYoYwTYIPZ2/uGYWz5mLZGbM9k9i+qqhmls0lMuSu7+JHXUopsO4/7R1qs/+GdvgofpjUUbYHKpGtaetmufZE80jaZoeJD33Ez6/a4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712735189; c=relaxed/simple; bh=G4+x/gzMfAHDc0HnV9EsKR+APIrtrrMs/uq4LgHmv8M=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=RxwpWo6LYktVAqhBRM2yN0/yYQYVe8N7efonh11p9vM8o3lUYSNiKlNWd4ukR2qvcgWKC+2VuV3qMKLqSH1UYnhPLTnWgbDuYteEYfUZw7gOq1XMovltxL4EbnpArzt/shMTXGnlrwLr8uBzVNMSetxwn158BfXgkJOGa0vy9lo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; arc=none smtp.client-ip=45.249.212.32 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Received: from mail.maildlp.com (unknown [172.19.88.163]) by szxga06-in.huawei.com (SkyGuard) with ESMTP id 4VDvy13XFZz21kfS; Wed, 10 Apr 2024 15:45:29 +0800 (CST) Received: from kwepemm600013.china.huawei.com (unknown [7.193.23.68]) by mail.maildlp.com (Postfix) with ESMTPS id D729F180063; Wed, 10 Apr 2024 15:46:24 +0800 (CST) Received: from huawei.com (10.175.104.67) by kwepemm600013.china.huawei.com (7.193.23.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Wed, 10 Apr 2024 15:46:22 +0800 From: Zhihao Cheng To: CC: , , Subject: [PATCH 9/9] ubifs: dbg_orphan_check: Fix missed key type checking Date: Wed, 10 Apr 2024 15:37:51 +0800 Message-ID: <20240410073751.2522830-10-chengzhihao1@huawei.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20240410073751.2522830-1-chengzhihao1@huawei.com> References: <20240410073751.2522830-1-chengzhihao1@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To kwepemm600013.china.huawei.com (7.193.23.68) Content-Type: text/plain; charset="utf-8" When selinux/encryption is enabled, xattr entry node is added into TNC before host inode when creating new file. So it is possible to find xattr entry without host inode from TNC. Orphan debug checking is called by ubifs_orphan_end_commit(), at that time, the commit semaphore is already unlock, so the new creation won't be blocked. Fixes: d7f0b70d30ff ("UBIFS: Add security.* XATTR support for the UBIFS") Fixes: d475a507457b ("ubifs: Add skeleton for fscrypto") Signed-off-by: Zhihao Cheng --- fs/ubifs/orphan.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/fs/ubifs/orphan.c b/fs/ubifs/orphan.c index 37d206097112..fb957d963ba6 100644 --- a/fs/ubifs/orphan.c +++ b/fs/ubifs/orphan.c @@ -816,8 +816,12 @@ static int dbg_orphan_check(struct ubifs_info *c, stru= ct ubifs_zbranch *zbr, =20 inum =3D key_inum(c, &zbr->key); if (inum !=3D ci->last_ino) { - /* Lowest node type is the inode node, so it comes first */ - if (key_type(c, &zbr->key) !=3D UBIFS_INO_KEY) + /* + * Lowest node type is the inode node or xattr entry(when + * selinux/encryption is enabled), so it comes first + */ + if (key_type(c, &zbr->key) !=3D UBIFS_INO_KEY && + key_type(c, &zbr->key) !=3D UBIFS_XENT_KEY) ubifs_err(c, "found orphan node ino %lu, type %d", (unsigned long)inum, key_type(c, &zbr->key)); ci->last_ino =3D inum; --=20 2.39.2