On 2026/6/23 10:49, Zhan Xusheng wrote:
From: Zhan Xusheng <[email protected]> Hi Xiang, Following the race model established by commit 1aee05e814d2 ("erofs: fix use-after-free on sbi->sync_decompress") -- i.e. unmount does not drain the async decompress kworker, and unlocking the output folios lets inode eviction (truncate_inode_pages waits on the locked folios) and thus the unmount path proceed to kfree(sbi) -- I'd like to ask about another sbi access that also happens after the unlock, in the same kworker. In z_erofs_decompress_pcluster(): erofs_onlinefolio_end(page_folio(page), err, true); /* unlock */ ... z_erofs_put_pcluster(sbi, pcl, try_free); and in z_erofs_put_pcluster(): if (try_free && xa_trylock(&sbi->managed_pslots)) { free = __erofs_try_to_release_pcluster(sbi, pcl); xa_unlock(&sbi->managed_pslots); } So in the try_free path it dereferences sbi->managed_pslots after the output folios have been unlocked, which on control-flow alone looks similar to the UAF fixed by 1aee05e814d2. What makes me unsure, though, is a difference from the sync_decompress case: sync_decompress is just a plain sbi member, whereas here z_erofs_put_pcluster() is still operating on a live pcluster that is registered in sbi->managed_pslots / the managed cache. So it's not clear to me whether the pcluster / managed-cache lifetime rules implicitly pin the filesystem instance and keep sbi valid across this window. This also seems much harder to hit than the sync_decompress case: it is conditional (try_free, i.e. non-managed compressed pages, plus the pcluster refcount reaching zero), the window between the unlock and put_pcluster is narrow, and unmount still has evict_inodes/put_super work to do before kfree(sbi) -- which may be why syzbot didn't reach it. Is there any guarantee that sbi stays valid here after the output folios are unlocked (e.g. via pcluster / managed-cache lifetime or RCU), or could unmount race with this path similarly to 1aee05e814d2? I'm asking rather than sending a patch since I couldn't convince myself either way.
No, this is totally false-positive.
Thanks, Zhan Xusheng
