All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joseph Qi <joseph.qi@linux.alibaba.com>
To: Heming Zhao <heming.zhao@suse.com>,
	Ahmet Eray Karadag <eraykrdg1@gmail.com>
Cc: mark@fasheh.com, jlbec@evilplan.org, 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 v5] ocfs2: Invalidate inode if i_mode is zero after block read
Date: Tue, 2 Dec 2025 14:16:55 +0800	[thread overview]
Message-ID: <8ede6a79-adb8-4b89-a8c2-d0cf57ff2267@linux.alibaba.com> (raw)
In-Reply-To: <r3mqyzrky6pamao7b4tsobdqqybhmyt6dg7jao76ho24kph3aq@wfwbzjqzury5>



On 2025/12/2 14:15, Heming Zhao wrote:
> On Tue, Dec 02, 2025 at 06:52:14AM +0300, 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>
>> 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
>> ---
>>  fs/ocfs2/inode.c | 8 ++++++++
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/fs/ocfs2/inode.c b/fs/ocfs2/inode.c
>> index 14bf440ea4df..08ce0846289c 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,
>> +			(di->i_links_count_hi | di->i_links_count), di->i_mode);
> 
> The '|' logic is meaningless here. Because the error case is rare, you can simply
> call ocfs2_read_links_count(di).
> 
Yes, also 'di->i_mode' should be converted to cpu endian as well.

Joseph


  reply	other threads:[~2025-12-02  6:17 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 [this message]
2025-12-02 22:45 ` [PATCH v6] " Ahmet Eray Karadag
2025-12-03  1:04   ` 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=8ede6a79-adb8-4b89-a8c2-d0cf57ff2267@linux.alibaba.com \
    --to=joseph.qi@linux.alibaba.com \
    --cc=albinbabuvarghese20@gmail.com \
    --cc=david.hunter.linux@gmail.com \
    --cc=eraykrdg1@gmail.com \
    --cc=heming.zhao@suse.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.