linux-kernel - Re: Subject: [BUG] Five data races in in XFS Filesystem,one potentially harmful

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 for Android: free password hash cracker in your pocket

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

Message-ID: <aCSX29o_xGAUWtIl@infradead.org>
Date: Wed, 14 May 2025 06:17:15 -0700
From: Christoph Hellwig <hch@...radead.org>
To: cen zhang <zzzccc427@...il.com>
Cc: cem@...nel.org, linux-xfs@...r.kernel.org, linux-kernel@...r.kernel.org,
	baijiaju1990@...il.com, zhenghaoran154@...il.com
Subject: Re: Subject: [BUG] Five data races in in XFS Filesystem,one
 potentially harmful

> 1. Race in `xfs_bmapi_reserve_delalloc()` and  `xfs_vn_getattr()`
> ----------------------------------------------------------------
> 
> A data race on `ip->i_delayed_blks`.

This is indeed a case for data_race as getattr is just reporting without any
locks.  Can you send a patch?

> 2. Race on `xfs_trans_ail_update_bulk` in `xfs_inode_item_format`
> -------------------------------------.
> 
> We observed unsynchronized access to `lip->li_lsn`, which may exhibit
> store/load tearing. However, we did not observe any symptoms
> indicating harmful behavior.

I think we'll need READ_ONCE/WRITE_ONCE here to be safe on 64-bit
systems to avoid tearing/reordering.  But that still won't help
with 32-bit systems.  Other lsn fields use an atomic64_t for, which
is pretty heavy-handed.

> Function: xfs_alloc_longest_free_extent+0x164/0x580

> Function: xfs_alloc_update_counters+0x238/0x720 fs/xfs/libxfs/xfs_alloc.c:908

Both of these should be called with b_sema held.  Does your tool
treat a semaphore with an initial count of 1 as a lock?  That is still
a pattern in Linux as mutexes don't allow non-owner unlocks.

> 4. Race on `pag->pagf_longest`
> ------------------------------
> 
> Similar to the previous race, this field appears to be safely used
> under current access patterns.

Same here I think.
> 
> Possibly Harmful Race
> ======================
> 
> 1. Race on `bp->b_addr` between `xfs_buf_map_pages()` and `xfs_buf_offset()`
> ----------------------------------------------------------------------------

And I think this is another case of b_sema synchronization unless I'm
missing something.