All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joseph Qi <joseph.qi@linux.alibaba.com>
To: Ahmet Eray Karadag <eraykrdg1@gmail.com>,
	mark@fasheh.com, jlbec@evilplan.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 v3] ocfs2: Invalidate inode if i_mode is zero after block read
Date: Sat, 25 Oct 2025 20:24:29 +0800	[thread overview]
Message-ID: <192fd326-2963-4839-8a4b-79abfc4ad3bd@linux.alibaba.com> (raw)
In-Reply-To: <20251025111355.32045-2-eraykrdg1@gmail.com>



On 2025/10/25 19:13, 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 within
> ocfs2_validate_inode_block. If i_mode is zero, 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.
> 
> ---
> [RFC]:
> The current fix handles i_mode=0 corruption detected during inode read
> by returning -EFSCORRUPTED from ocfs2_validate_inode_block, which leads to
> make_bad_inode() being called, preventing the corrupted inode from
> entering the cache. This approach avoids immediately forcing the entire
> filesystem read-only, assuming the corruption might be localized to
> this inode.
> 
> Is this less aggressive error handling strategy appropriate for i_mode=0
> corruption? Or is this condition considered severe enough that we *should*
> explicitly call ocfs2_error() within the validation function to guarantee
> the filesystem is marked read-only immediately upon detection?
> Feedback and testing on the correct severity assessment and error
> handling for this type of corruption would be appreciated.
> 
> 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>
> ---
> v2:
>  - Reviewed how ext4 handling same situation and we come up with this
>    solution
> ---
> v3:
>  - Implement combined check for nlink=0, mode=0 and non-orphan
>    as requested.
> ---
>  fs/ocfs2/inode.c | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/ocfs2/inode.c b/fs/ocfs2/inode.c
> index 14bf440ea4df..3feeaa475b62 100644
> --- a/fs/ocfs2/inode.c
> +++ b/fs/ocfs2/inode.c
> @@ -1455,7 +1455,14 @@ int ocfs2_validate_inode_block(struct super_block *sb,
>  		     (unsigned long long)bh->b_blocknr);
>  		goto bail;
>  	}
> -
> +	if (!le16_to_cpu(di->i_links_count) && !le16_to_cpu(di->i_mode) &&
> +		!(le32_to_cpu(di->i_flags) & OCFS2_ORPHANED_FL)) {

	    ^Better to align here.

> +			mlog(ML_ERROR, "Invalid dinode #%llu: "

One tab is engough.

Joseph
> +				"Corrupt state (nlink=0, mode=0, !orphan) detected!\n",
> +			        (unsigned long long)bh->b_blocknr);
> +			rc = -EFSCORRUPTED;
> +			goto bail;
> +	}
>  	/*
>  	 * Errors after here are fatal.
>  	 */


  reply	other threads:[~2025-10-25 12:24 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-22 22:27 [RFC RFT PATCH] ocfs2: Invalidate inode if i_mode is zero after block read Ahmet Eray Karadag
2025-10-23  0:34 ` Joseph Qi
2025-10-24  2:30 ` [PATCH v2] " Ahmet Eray Karadag
2025-10-24  9:05   ` Joseph Qi
2025-10-25 11:13 ` [PATCH v3] " Ahmet Eray Karadag
2025-10-25 12:24   ` Joseph Qi [this message]
2025-10-25 14:39 ` [PATCH v4] " Ahmet Eray Karadag
  -- strict thread matches above, loose matches on Subject: below --
2025-11-08 12:01 [RFT PATCH] " Ahmet Eray Karadag
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

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=192fd326-2963-4839-8a4b-79abfc4ad3bd@linux.alibaba.com \
    --to=joseph.qi@linux.alibaba.com \
    --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.