From: Ahmet Eray Karadag <eraykrdg1@gmail.com>
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 <eraykrdg1@gmail.com>,
syzbot+55c40ae8a0e5f3659f2b@syzkaller.appspotmail.com,
Albin Babu Varghese <albinbabuvarghese20@gmail.com>
Subject: [PATCH v6] ocfs2: Invalidate inode if i_mode is zero after block read
Date: Wed, 3 Dec 2025 01:45:08 +0300 [thread overview]
Message-ID: <20251202224507.53452-2-eraykrdg1@gmail.com> (raw)
In-Reply-To: <20251108120133.37443-3-eraykrdg1@gmail.com>
A panic occurs in ocfs2_unlink due to WARN_ON(inode->i_nlink == 0) when
handling a corrupted inode with i_mode=0 and i_nlink=0 in memory.
This "zombie" inode is created because ocfs2_read_locked_inode proceeds
even after ocfs2_validate_inode_block successfully validates a block
that structurally looks okay (passes checksum, signature etc.) but
contains semantically invalid data (specifically i_mode=0). The current
validation function doesn't check for i_mode being zero.
This results in an in-memory inode with i_mode=0 being added to the VFS
cache, which later triggers the panic during unlink.
Prevent this by adding an explicit check for (i_mode == 0, i_nlink == 0, non-orphan)
within ocfs2_validate_inode_block. If the check is true, return -EFSCORRUPTED to signal
corruption. This causes the caller (ocfs2_read_locked_inode) to invoke
make_bad_inode(), correctly preventing the zombie inode from entering
the cache.
Reported-by: syzbot+55c40ae8a0e5f3659f2b@syzkaller.appspotmail.com
Fixes: https://syzkaller.appspot.com/bug?extid=55c40ae8a0e5f3659f2b
Co-developed-by: Albin Babu Varghese <albinbabuvarghese20@gmail.com>
Signed-off-by: Albin Babu Varghese <albinbabuvarghese20@gmail.com>
Signed-off-by: Ahmet Eray Karadag <eraykrdg1@gmail.com>
Previous link: https://lore.kernel.org/all/20251022222752.46758-2-eraykrdg1@gmail.com/T/
---
v2:
- Only checking either i_links_count == 0 or i_mode == 0
- Not performing le16_to_cpu() anymore
- Tested with ocfs2-test
---
v3:
- Add checking both high and low bits of i_links_count
---
v4:
- Reading i_links_count hi and low bits without helper function
to save few cpu cycles
---
v5:
- Clear i_links_count check
- Log the actual i_nlink/i_mode
---
v6:
- Use `ocfs2_read_links_count` to get nlink
- Convert di->imode to cpu endian
---
fs/ocfs2/inode.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/fs/ocfs2/inode.c b/fs/ocfs2/inode.c
index 14bf440ea4df..f83b8e4f4d8b 100644
--- a/fs/ocfs2/inode.c
+++ b/fs/ocfs2/inode.c
@@ -1456,6 +1456,14 @@ int ocfs2_validate_inode_block(struct super_block *sb,
goto bail;
}
+ if ((!di->i_links_count && !di->i_links_count_hi) || !di->i_mode) {
+ mlog(ML_ERROR, "Invalid dinode #%llu: "
+ "Corrupt state (nlink = %u or mode = %u) detected!\n",
+ (unsigned long long)bh->b_blocknr,
+ ocfs2_read_links_count(di), le16_to_cpu(di->i_mode));
+ rc = -EFSCORRUPTED;
+ goto bail;
+ }
/*
* Errors after here are fatal.
*/
--
2.43.0
next prev parent reply other threads:[~2025-12-02 22:46 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-08 12:01 [RFT PATCH] ocfs2: Invalidate inode if i_mode is zero after block read Ahmet Eray Karadag
2025-11-11 3:44 ` Heming Zhao
2025-11-17 22:35 ` [PATCH v2] " Ahmet Eray Karadag
2025-11-19 14:27 ` Heming Zhao
2025-11-19 22:17 ` [PATCH v3] " Ahmet Eray Karadag
2025-11-20 2:32 ` Heming Zhao
2025-11-28 14:36 ` Ahmet Eray Karadag
2025-12-01 2:17 ` Heming Zhao
2025-12-02 1:25 ` Joseph Qi
2025-12-02 1:51 ` Ahmet Eray Karadag
2025-12-02 0:32 ` [PATCH v4] " Ahmet Eray Karadag
2025-12-02 2:44 ` Joseph Qi
2025-12-02 2:52 ` Heming Zhao
2025-12-02 3:52 ` [PATCH v5] " Ahmet Eray Karadag
2025-12-02 6:15 ` Heming Zhao
2025-12-02 6:16 ` Joseph Qi
2025-12-02 22:45 ` Ahmet Eray Karadag [this message]
2025-12-03 1:04 ` [PATCH v6] " Joseph Qi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251202224507.53452-2-eraykrdg1@gmail.com \
--to=eraykrdg1@gmail.com \
--cc=albinbabuvarghese20@gmail.com \
--cc=david.hunter.linux@gmail.com \
--cc=jlbec@evilplan.org \
--cc=joseph.qi@linux.alibaba.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mark@fasheh.com \
--cc=ocfs2-devel@lists.linux.dev \
--cc=skhan@linuxfoundation.org \
--cc=syzbot+55c40ae8a0e5f3659f2b@syzkaller.appspotmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.