From nobody Tue Dec 2 02:51:51 2025 Received: from mail-ej1-f43.google.com (mail-ej1-f43.google.com [209.85.218.43]) (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 B277E24A067 for ; Tue, 18 Nov 2025 00:19:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.43 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763425160; cv=none; b=jszOyg2VmBvYHJoyWRvxTkAXCzBByZz+elgYWcUnmYWTidvknjJaFMPUAIpBRjHOBrS6Pz+P2x/AOIB5dp4BD26KblTEUb7HezEJtn6+jQwZWNUqK1tykjDwIM1gtQfg7+LFis8zIkHa75ngM7VmMmtxntEEo+EH5NMuXf0qeIU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763425160; c=relaxed/simple; bh=DSmw1+Vwv0HnRD3Enwa7AilcMKynWxy31iZgq6F6580=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=GdfbhG6x3Jzew0/6XsZcB2eMsBzUH7AXORWvjlKt7Zv54NY5uYQmyBrK8qUSfwReIcXTCGwypwm7VeKj0GBOywyLtZ5nUzhGGV1NvEVu1vma/8zgXZFPiHN0eeSrXrRlvSpAS1qATG2oWBBDTags1JLW7cwNqii/Thgv1XVkZd4= 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=WnJ/q/YM; arc=none smtp.client-ip=209.85.218.43 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="WnJ/q/YM" Received: by mail-ej1-f43.google.com with SMTP id a640c23a62f3a-b71397df721so702813966b.1 for ; Mon, 17 Nov 2025 16:19:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763425157; x=1764029957; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=mOw6IYtde1FQUWe/T9xO6OJOvT24+LmnbLN8DYc/tME=; b=WnJ/q/YMbCGzc1ft9FJLpQnuXHqg/w2hPbnXxIWNcb/QNeOcFgN6T+iO4rBOddDcnR xPhNA9O00//nv+VTnoK9rnw2Usmaanmi54uV0uf9Cy6VULf16IteKQE1yHkk8ARb6YzW 3S36SsBIrE/II1aUTQqtggpBTXAu1Bjp6NZQp5L7Lx8daZS2O9u571McSEU+6++H+oom +Ls3ovqiz1ntk5q355WSEdPcusLr6k1DfaW1duZTWvf2KJ6K0O+9MPQs0XFwYDRiJMIu I4HRZd55MhALs3BN5TzHQOtQHRl2Sdu3YvPeT7oMgD6Awu4B10dLkHdpp0flNOqlk7l8 Gwuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763425157; x=1764029957; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=mOw6IYtde1FQUWe/T9xO6OJOvT24+LmnbLN8DYc/tME=; b=Zg0rSsBlaVjdbcJXgtJ2KVpZTUnI9cbk4qFKeJqSsCl2D1w6aeoCnTWy2dxvxWNYmA eE0xmn1mg13pjUEwoIu61LVmJE/Yi8qN+yFQjdKGkKyoN5je6OgmMmwnjhkAVVyLa/tb lT+fMCcNVOSeYdhTD9oSSqj1ytkk/vv3RDXYcOW0r+KuhjQJpln0zalqyYsXAta5sqBi 2SVkG6unI6c0hOlDMCjXbhggNqcXHumOyTGnci4DW32axQIASyh2gkMCdVphGk527fgG 5AP7W3hYl7MlldfhFRkmrPDUyLbUNdfRgKXCtoi6HorxrtYBNHwtWTdJKiAmBQV27oRW 80HA== X-Forwarded-Encrypted: i=1; AJvYcCUMpf6cu/KGS1H6ySfWEDJE6xpwum/NHn0MfnB5e2+Z96PyrDTNJvwb+GRt0XeqgGOf17luN8pITThGhJ0=@vger.kernel.org X-Gm-Message-State: AOJu0Yz1l+T6hcmxYpwcNeyOi1VMRC97gcdZvpYSP1EKwba0OphGwP8J tt9vk1zAlen3wab0SEmONiC0tOd1jlziQOrbex2Tq3MlOBI0JTkik6tc X-Gm-Gg: ASbGncv6s8cX6MmK7gM3+A66mapWGqcMPcWfCoHmABGOlbVQLMms329jC56vCOkMa1t J2Hi3cX+ExZ2DsXqzBZg1Kh2NN7E2Z+s+CIDmXYGinyNdBQ3GwpPtF3s/y0r+W/gsXYtHbnty4t UZ/l06KuWPrFMwEz0Ju/z/QUHpIh+2G27N/xU0oGpDBl9aL/7mmge41dl5rn1A0BPwIY0V1rG7R iY06pLQgLHusqzmVZ3V5rM5gprNa3zVQq3DBZCTUfVQsenqOqT1hTC2WWPq9Z3QP+G7cjC14cGV egSnY7nQG4qN2yo0uomMMrJhaiixEnxJ6r4QqGhJZTjZMD+FurGnD/Cr/uRMaMrK8a7N42nhamE 2RX4SXwCSs+FSTdChAbeuc6+R5TguUjsnKihttG3K4xVK+AJY+7w0WSbRe/wZ75++tt4BYvcT4R eu X-Google-Smtp-Source: AGHT+IHe0KzCc+DIGyOFPlhlYxfYHGdklwVpQeXrG5useC/dPcZwppTwyWJSrB0BBPWbH0B71uf7og== X-Received: by 2002:a17:906:7309:b0:b45:60ad:daf9 with SMTP id a640c23a62f3a-b73677ed721mr1536042766b.3.1763425156745; Mon, 17 Nov 2025 16:19:16 -0800 (PST) Received: from eray-kasa.. ([2a02:4e0:2d08:f72:eb64:1d0d:5855:afe7]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b734fedb2cfsm1190334166b.71.2025.11.17.16.19.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 17 Nov 2025 16:19:16 -0800 (PST) From: Ahmet Eray Karadag To: mark@fasheh.com, jlbec@evilplan.org, joseph.qi@linux.alibaba.com Cc: ocfs2-devel@lists.linux.dev, linux-kernel@vger.kernel.org, david.hunter.linux@gmail.com, skhan@linuxfoundation.org, Ahmet Eray Karadag , syzbot+b93b65ee321c97861072@syzkaller.appspotmail.com, Heming Zhao , Albin Babu Varghese Subject: [PATCH] ocfs2: Mark inode bad upon validation failure during read Date: Tue, 18 Nov 2025 03:18:34 +0300 Message-ID: <20251118001833.423470-2-eraykrdg1@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: quoted-printable Content-Type: text/plain; charset="utf-8" A VFS cache inconsistency, potentially triggered by sequences like buffered writes followed by open(O_DIRECT), can result in an invalid on-disk inode block (e.g., bad signature). OCFS2 detects this corruption when reading the inode block via ocfs2_validate_inode_block(), logs "Invalid dinode", and often switches the filesystem to read-only mode. The VFS open(O_DIRECT) operation appears to incorrectly clear the inode's I_DIRTY flag without ensuring the dirty metadata (reflecting the earlier buffered write, e.g., an updated i_size) is flushed to disk. This leaves the in-memory VFS inode object "in limbo" with an updated size (e.g., 38639 from the write) but marked clean, while its on-disk counterpart remains stale (e.g., size 0) or invalid. Currently, the function reading the inode block (ocfs2_read_inode_block_ful= l()) fails to call make_bad_inode() upon detecting the validation error. Because the in-memory inode is not marked bad, subsequent operations (like ftruncate) proceed erroneously. They eventually reach code (e.g., ocfs2_truncate_file()) that compares the inconsistent in-memory size (38639) against the invalid/stale on-disk size (0), leading to kernel crashes via BUG_ON. Fix this by calling make_bad_inode(inode) within the error handling path of ocfs2_read_inode_block_full() immediately after a block read or validation error occurs. This ensures VFS is properly notified about the corrupt inode at the point of detection. Marking the inode bad allows VFS to correctly fail subsequent operations targeting this inode early, preventing kernel panics caused by operating on known inconsistent inode st= ates. Reported-by: syzbot+b93b65ee321c97861072@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=3Db93b65ee321c97861072 Reviewed-by: Heming Zhao Co-developed-by: Albin Babu Varghese Signed-off-by: Albin Babu Varghese Signed-off-by: Ahmet Eray Karadag Previous-link: https://lore.kernel.org/all/20251029225748.11361-2-eraykrdg1= @gmail.com/T/ Acked-by: Joseph Qi --- fs/ocfs2/inode.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/ocfs2/inode.c b/fs/ocfs2/inode.c index fcc89856ab95..415ad29ec758 100644 --- a/fs/ocfs2/inode.c +++ b/fs/ocfs2/inode.c @@ -1690,6 +1690,8 @@ int ocfs2_read_inode_block_full(struct inode *inode, = struct buffer_head **bh, rc =3D ocfs2_read_blocks(INODE_CACHE(inode), OCFS2_I(inode)->ip_blkno, 1, &tmp, flags, ocfs2_validate_inode_block); =20 + if (rc < 0) + make_bad_inode(inode); /* If ocfs2_read_blocks() got us a new bh, pass it up. */ if (!rc && !*bh) *bh =3D tmp; --=20 2.43.0