From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f181.google.com (mail-pf1-f181.google.com [209.85.210.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DFB6212C534 for ; Tue, 23 Jun 2026 02:50:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.181 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782183005; cv=none; b=kk9pY/osP6m5eaqxQNbvgbdtdLkJ3x4pOshRfQnHkKe9f5UBzg5dJSclhHBsmFji7e23ifvoRG4e8vrvAVQiLP54TgcNNcJ2neh9WE4/GLKjYOA8i9PqNwDej5fwZuYpc1dlR5o0UvyEx6TBnZ/wCFDa+t8VLg8EqV+DpozhZLU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782183005; c=relaxed/simple; bh=Cs9MUM3ZBEfgwOxbSjpVW914JYeSvbtYrx7ZIsBBj40=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=DedcQnMU8Z4cDx4MTULYTvVUgeUoFYP2AMUEi9tUIWsyixIw+zohxDRHltm5mezcDzq/Uv3kyiWc3M8H/79sdTof3GraQJruWyMIp0DFhMS1oD1MBR4GPjujvrkFf5ZczYfwl4sInW3vlTUUae3wz2FA55T5ar9+e4LmoHo1pME= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=gCTZnIPD; arc=none smtp.client-ip=209.85.210.181 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="gCTZnIPD" Received: by mail-pf1-f181.google.com with SMTP id d2e1a72fcca58-84531988438so264612b3a.0 for ; Mon, 22 Jun 2026 19:50:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1782183003; x=1782787803; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=lr4xgVO18u2WbaGeP1+M4CIAnONQq7B3nOwFcr50zAo=; b=gCTZnIPDMMALM97U55Pwqsrsv5pusHpnX40ss4wqrIJ+H3+AY0A1WwaSnkqkIEFU8s IgpRy/1UDIpJHxSArkNKJ8vgECxR8bTCszQLuOAgE/+E2I3Jg5T3+sN65iBHw8zpJIBM GUwYPN/DWRgHCrO4I+3cTVkjhtjYonebwOFWBrVTrYPTMDmeYyKNwHyQwb44jRDrl+Yx Cwv61PLw320NHxifcxoJ6ngELcBn+Ns4Vhj9a0zn8EsU1D0gvoEUE/a3Q9Rhrsu/HeF/ J17NuBNe2rwwMEtRbiz2sUs38YE9Gosn9+LVgDG/J/3FollQIUopfzhwvaQkruwyoVJJ 170A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782183003; x=1782787803; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=lr4xgVO18u2WbaGeP1+M4CIAnONQq7B3nOwFcr50zAo=; b=bjsFZgJiOhO6ZzjtKhj7+foCgej2hlicHFD4DkRiYmW6On7asV8LiYeS1UUi2r/FEQ K1gPBbEew1ywvdHmHfJi2r/atwQJP93RJ113QtsFo3pouOisAhi8B0XJq4hzctgRLRfT bWVaWJxQmRGS28OaotZW1+Xqi1FNhWUMritIu0I4HzK+xj71V05xppNw1ST7FH8Dj3Oi GvN8RIm1vIvcVjYtEbZzcFHVKSc2tgqpX0B5bggQOZMn5S63nNoUCuoURdFTilJMCa3V 2YNwaXi56rZMd7ztCUpdhiOzOzdNN8pfXf0dgf/oj/nPL4mIb2nCbBAgVwmj/re9G+su pCsA== X-Forwarded-Encrypted: i=1; AFNElJ8PxpatnnxMMJSfPxJVZxqXdEYI1AwB73KcrSGiLzbLqnpiFuJnZi34VVgytXSsHiVTYDmxPRJ+UvpeP9c=@vger.kernel.org X-Gm-Message-State: AOJu0YyQ0ziqfW6RU72/0sgPQeSpFWJnhnskU4FK26c1+OhIR6Jj3EhS hBt/jSpl7fKU/t2Kt3T9h5LXzdPVWa0iAw4bvb5t9Z9NUjAdl1SlIiBM3RC6xA== X-Gm-Gg: AfdE7cnqKGpHq/St7vnTBPTXsHPRjC3Gwby477FwKZ3Q2GeNz8NFn7i6ON4KrqSHlEv eef5KnPvYodfJWkqu+3NSWQONY/LVMLZmT3vOh04dHTq5Mfb1ynJqAffqkamObBHQbLmYxU3Oi8 qaU2cyfQ1Tuq8ldx2PDS1uUtKcJgD5HRdrSba27k5ZfaOo33LmwbD8iDzxPnEbunUYWZp3un98k SWs5DNAWNvwuS2uu+NwogAoE0BA1Eu0PXJ5v70JXa8GbRZr8A+JGeIVqzXZ817lIykNbpx7HH3l ozzyxr2WkoCIw7mOyro+DJ24vLrTBKv+abopT4Cf0KHdFN6pueo0yMJ4vq7SRw/bXjdXxT0ZRou Vxr2CxUZDSbXd5qGTl3WvkoOwfMeAw6DBQA/ugrbmDWE+mhVxo0mUS7izQZEc6JzOkkXJzLe1Vg TMKIFeouA0DPo4HyVwdqVXeqU= X-Received: by 2002:a05:6a00:1742:b0:842:50fd:4c13 with SMTP id d2e1a72fcca58-84591b50e5emr1566841b3a.4.1782183003157; Mon, 22 Jun 2026 19:50:03 -0700 (PDT) Received: from osman.mioffice.cn ([43.224.245.178]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-84564ed3212sm9178123b3a.55.2026.06.22.19.50.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Jun 2026 19:50:02 -0700 (PDT) From: Zhan Xusheng X-Google-Original-From: Zhan Xusheng To: Gao Xiang Cc: Gao Xiang , Chao Yu , Jianan Huang , linux-erofs@lists.ozlabs.org, linux-kernel@vger.kernel.org, Zhan Xusheng , Zhan Xusheng Subject: erofs: is z_erofs_put_pcluster()'s sbi access in the same UAF window as 1aee05e814d2? Date: Tue, 23 Jun 2026 10:49:46 +0800 Message-ID: <20260623024946.3420476-1-zhanxusheng@xiaomi.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Zhan Xusheng 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. Thanks, Zhan Xusheng