From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f178.google.com (mail-pf1-f178.google.com [209.85.210.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7542523395F for ; Mon, 3 Aug 2026 03:00:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785726049; cv=none; b=uWdbMMO2azrnrjyjxD/3aI/bA0XgUQuzGQsEJEOUuTKV+sa/AY9IbcR1OZvRIo5ALR1O0eCqNagDjFbWEAN5FQehLJc+qX7vxoqZg3Rn8PicWV+RwZxXTIqWxZYkyUkYG6FaUJBfwX95e1DklnzxB38aDg51Nu/5uFNou5/TaAY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785726049; c=relaxed/simple; bh=IL4PPdL89KrYlb+3vsLpx0jYYpLzXSAWBppKnDP13KU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=hw8rMNPrA9xUDqExslzmcFh/RetR8pKMHs57E+wZAysqx8SFPDuZVfnz1M9yPKGfQ1lHjs8Ekg7l5M1WHcinQyt9LcAvtFYj8TRHiGQlb8l6fT1Wy+6HpyxH6sD8OqSsO+/emWzZjUNuSDEt7696O0/bg2Nu5qiPZ2hdZqZKtdo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=nCrAChfu; arc=none smtp.client-ip=209.85.210.178 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="nCrAChfu" Received: by mail-pf1-f178.google.com with SMTP id d2e1a72fcca58-84e84a6c4bfso2408943b3a.1 for ; Sun, 02 Aug 2026 20:00:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785726048; x=1786330848; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=X9ddKkl1cDb08a4csiFm959vb9khfkPCLClK+RZwmRE=; b=nCrAChfuiQnOKMmZdNZZ/qbl7O6AhpBsAcGjQsSrdsuOMJlfyPH11u/OI72sqfW8I9 Q/4tU94nEHw76Dg1AahX4i5BJutqiTxplOnWCyKAYKZmzc+OWeK0O2GbuDL6aGpinxu9 V0OB3i2ywqq0jlgN+lIx6hER5CQCwhLui5u40y9o8t/LuAqYR7qi/nvjA4cvFl5RC/RF TNoZ0tfWiJTTy2gi/wRN+5j2E5ZEpXZ+AmASI5u7syXIVEx6rFij+qLteWM7n4sMeAn1 JqMI6mcN5D0gKFOB57892h20mGNtv1A9PXHf6Vlmb86FiUWgyVvyg45PwIZlorAuFutv VCoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785726048; x=1786330848; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=X9ddKkl1cDb08a4csiFm959vb9khfkPCLClK+RZwmRE=; b=fde4MxhIqUz83vmW6wT0v31exfvC0UnQOa0SFgRCei1GCYMxZka6bPsltBu88YrNbT eq3buDhZc9qiKjDSswL3jUodVIGcOHchAQn/25Tv7qQsKzVsuoEX1DXTTbPssqRDYeVP g8UHHWG5ctMGb26yFCeMM99jbfOPX9oQAUsmL89U8okpqRrKzdihM+5afGRjjk3499aG 5T5r2iBEDeGnZRIvF3yfhYtHxwGg4ElXAknY8YH9JBerLFT1Stk8QVineyC6KPfz7muN kQn+l0qF2LdfnXrzcvBglAuWRzZurnkoHgmWl03W2My8T+wJvxiVE4zpUYjBUJ3rJ5c4 aiRw== X-Forwarded-Encrypted: i=1; AHgh+RpVCYzNViFFyECILF1M9KIPf4pD9qNju8GYh7KNwN1I564Zpbg5IZVBaUtVYxt/IJinmWq9ySO6Y+HVdVI=@vger.kernel.org X-Gm-Message-State: AOJu0Yx8CoU5ufuM2LNszgBJbpew0/gFiAdk2UWZFcDSDH0Tq7LW7rfh Wi/CbRlWui9Yb/kEJy5kCfrWwbkXAo53zb+S5FnaqHTn3r8DHMM5vgWV X-Gm-Gg: AR+sD11sQDgOPMU++Zw8T55p0bC7e/YzRgqdRKXBx362FLbGBijXjZ5QNE2aK3qtSqi xsDPxogEZQGq5pgE/S4Gl6Swlw6yTDgmWozWc5xnFeNb34cgQCgPQ11557hT1Ts6ViMkHmbAsrZ bgnGpaYP6Nk5Rgniev/KMbm6CVHTebfzaGLCBZDsTl61g5TNdTE9Ohqrk1MYjeFnzUR28CQVfRF vsTOFDryjZ8BKLA00CGN735q5GcauiIBGi7KCMMocPw5L6ghk9zY3pkPrYBHQXJljlzQ8WKpR56 4gU0ihZnVS2kRNUKE1JYYnQI7bWpXEbnWV3mcIPOffva3JuqoPyJrcXoAYjx0OqTXpc7zjMa+rq +gowXa0U/Bqy/gx6KY9Slm7vy6t3idZnG0z0KrDIIjZjJH4u7c4w9eaQaiBenpu+Zi5MZ1deXTf hrn6mu30peG9RgC5b3QE+SH0v9tlyfN80qGrbf4P0DE91Lulcimo//TJ58DWc9TD8LD11qgpDtl FddeXK7DanxHhXk5mCAHMj0Ue4Awg== X-Received: by 2002:a05:6a00:22d1:b0:848:7bbd:2851 with SMTP id d2e1a72fcca58-84ed74bdcf0mr8930419b3a.29.1785726047593; Sun, 02 Aug 2026 20:00:47 -0700 (PDT) Received: from gmail.com ([138.199.21.246]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-84edc29f2b9sm2962878b3a.35.2026.08.02.20.00.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 02 Aug 2026 20:00:47 -0700 (PDT) From: ZhengYuan Huang To: mark@fasheh.com, jlbec@evilplan.org, joseph.qi@linux.alibaba.com, akpm@linux-foundation.org Cc: ocfs2-devel@lists.linux.dev, linux-kernel@vger.kernel.org, baijiaju1990@gmail.com, r33s3n6@gmail.com, zzzccc427@gmail.com, tom442288@tuta.io, ZhengYuan Huang Subject: [PATCH 1/2] ocfs2: validate orphan slot during inode read Date: Mon, 3 Aug 2026 11:00:06 +0800 Message-ID: <20260803030007.3993199-2-gality369@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260803030007.3993199-1-gality369@gmail.com> References: <20260803030007.3993199-1-gality369@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit [BUG] A corrupted dinode with OCFS2_ORPHANED_FL can carry an i_orphaned_slot outside the mounted filesystem slot range. ocfs2_wipe_inode() uses it to index osb_orphan_wipes before looking up the orphan directory, causing an out-of-bounds memory access. BUG: KASAN: slab-use-after-free in ocfs2_get_system_file_inode+0x780/0x820 fs/ocfs2/sysfile.c:102 Read of size 8 at addr ffff88800b767c00 by task kworker/u8:3/85 Call Trace: ... ocfs2_get_system_file_inode+0x780/0x820 fs/ocfs2/sysfile.c:102 ocfs2_wipe_inode+0x292/0xf70 fs/ocfs2/inode.c:840 ocfs2_delete_inode fs/ocfs2/inode.c:1155 [inline] ocfs2_evict_inode+0x6c9/0x1170 fs/ocfs2/inode.c:1295 evict+0x38e/0x8f0 fs/inode.c:810 iput_final fs/inode.c:1914 [inline] iput fs/inode.c:1966 [inline] iput+0x55b/0x8b0 fs/inode.c:1926 ocfs2_recover_orphans+0x610/0xe40 fs/ocfs2/journal.c:2374 ocfs2_complete_recovery+0x5af/0xd00 fs/ocfs2/journal.c:1373 ... [CAUSE] ocfs2_validate_inode_block() validates i_suballoc_slot but leaves the active ordinary orphan slot unchecked. Downstream consumers assume that the value is smaller than osb->max_slots. [FIX] Reject an active i_orphaned_slot outside the slot range during dinode validation, before the inode reaches orphan wipe processing. Fixes: b4df6ed8db0c ("[PATCH] ocfs2: fix orphan recovery deadlock") Signed-off-by: ZhengYuan Huang --- fs/ocfs2/inode.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/fs/ocfs2/inode.c b/fs/ocfs2/inode.c index 41db7dd39ed9..358ab3535366 100644 --- a/fs/ocfs2/inode.c +++ b/fs/ocfs2/inode.c @@ -1528,6 +1528,14 @@ int ocfs2_validate_inode_block(struct super_block *sb, goto bail; } + if ((le32_to_cpu(di->i_flags) & OCFS2_ORPHANED_FL) && + le16_to_cpu(di->i_orphaned_slot) >= OCFS2_SB(sb)->max_slots) { + rc = ocfs2_error(sb, "Invalid dinode %llu: orphaned slot %u\n", + (unsigned long long)bh->b_blocknr, + le16_to_cpu(di->i_orphaned_slot)); + goto bail; + } + /* * Reject dinodes whose i_mode does not name one of the seven * canonical POSIX file types. ocfs2_populate_inode() copies -- 2.43.0