linux-kernel - Re: [PATCH] ocfs2: fix stale extent map cache during COW operations

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20251011074226.821546-1-kartikey406@gmail.com>
Date: Sat, 11 Oct 2025 13:12:26 +0530
From: Deepanshu Kartikey <kartikey406@...il.com>
To: heming.zhao@...e.com,
	joseph.qi@...ux.alibaba.com,
	mark@...heh.com,
	jlbec@...lplan.org
Cc: ocfs2-devel@...ts.linux.dev,
	linux-kernel@...r.kernel.org,
	syzbot+6fdd8fa3380730a4b22c@...kaller.appspotmail.com
Subject: Re: [PATCH] ocfs2: fix stale extent map cache during COW operations

Hi Heming,

Thank you for the detailed analysis and feedback.

I appreciate your review. However, I'm trying to understand your explanation 
better. You mentioned that step 5 (write with zeros) cleans the file data 
and causes the refcount flag mismatch. 

Looking at the C reproducer, I see:
- Step 7: copy_file_range() creates reflinked extent (flags=0x2)
- Step 8: ioctl(fd, 0x40406f06, ...) which is FITRIM
- Step 9: write() triggers the BUG_ON

In my analysis, step 8 (FITRIM) calls ocfs2_move_extents() -> 
__ocfs2_move_extents_range() -> ocfs2_move_extent() -> __ocfs2_move_extent().

Inside __ocfs2_move_extent() at line 50, I found:
    replace_rec.e_flags = ext_flags & ~OCFS2_EXT_REFCOUNTED;

This explicitly clears the OCFS2_EXT_REFCOUNTED flag when writing to disk, 
but the extent cache is not invalidated afterward.

Could you help me understand:
1. How does the write operation in step 5 clear the refcount flag on disk?
2. Are you suggesting there might be two separate bugs - one in the FITRIM 
   path (which v2 fixes) and another in a different path (which v1 would fix)?

My v2 patch has been merged into linux-next. If you believe v1 addresses a 
different bug scenario, I'm happy to submit it as an additional patch.

Thanks for your time and expertise!

Best regards,
Deepanshu