From: Joseph Qi <joseph.qi@linux.alibaba.com>
To: Ahmet Eray Karadag <eraykrdg1@gmail.com>,
mark@fasheh.com, jlbec@evilplan.org,
akpm <akpm@linux-foundation.org>
Cc: ocfs2-devel@lists.linux.dev, linux-kernel@vger.kernel.org,
david.hunter.linux@gmail.com, skhan@linuxfoundation.org,
syzbot+55c40ae8a0e5f3659f2b@syzkaller.appspotmail.com,
Albin Babu Varghese <albinbabuvarghese20@gmail.com>
Subject: Re: [PATCH v6] ocfs2: Invalidate inode if i_mode is zero after block read
Date: Wed, 3 Dec 2025 09:04:13 +0800 [thread overview]
Message-ID: <ad0b67fb-9af6-4179-a4e5-032d749f50d6@linux.alibaba.com> (raw)
In-Reply-To: <20251202224507.53452-2-eraykrdg1@gmail.com>
On 2025/12/3 06:45, Ahmet Eray Karadag wrote:
> 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>
Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.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.
> */
prev parent reply other threads:[~2025-12-03 1:04 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 ` [PATCH v6] " Ahmet Eray Karadag
2025-12-03 1:04 ` Joseph Qi [this message]
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=ad0b67fb-9af6-4179-a4e5-032d749f50d6@linux.alibaba.com \
--to=joseph.qi@linux.alibaba.com \
--cc=akpm@linux-foundation.org \
--cc=albinbabuvarghese20@gmail.com \
--cc=david.hunter.linux@gmail.com \
--cc=eraykrdg1@gmail.com \
--cc=jlbec@evilplan.org \
--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.