From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dy1-f177.google.com (mail-dy1-f177.google.com [74.125.82.177]) (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 00C53279DC2 for ; Sat, 31 Jan 2026 23:23:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.177 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769901790; cv=none; b=ca1ZNPbMsmDPGz4lgnlX8xiBDIlfFFOWPYnTyzeFiO4EZIvMXPJh13obnKtwmzM1aeIY7PwCuJ87oo9ae8aUtgto1VAwJ1BTDnJS7OBjlih//PyhIKFdaHnlR60pQyPM5VAWX/INjYmPob4IiZ1xfp3Tcv5UYH0Mn+CG/P7wn24= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769901790; c=relaxed/simple; bh=vDsnU2x0CZEhfPxslXsANrVY4khVb45H4Spc+iE5rqc=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=XdA9tNU5q3zVDyeT7uIIyXtTeVK3rdSkFaG/vKj3bK8wAR02TRny46l4u4+kDbS3cEIMP89KjfsbZLyHlQSC35VuWbrRbbd84Ydh+nyJR9cscb3GHzMsX2b27AqHMO2yZcQCLm5C4gRJH63KUHkjjEJKl/M809dxYqadMZDB8so= 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=hBrgdyiE; arc=none smtp.client-ip=74.125.82.177 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="hBrgdyiE" Received: by mail-dy1-f177.google.com with SMTP id 5a478bee46e88-2b7da62b487so2984645eec.1 for ; Sat, 31 Jan 2026 15:23:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769901788; x=1770506588; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=odLopdMOFuzazlxMO/Jvqpu3SpD1lqSt4vEe+VI2wxE=; b=hBrgdyiEo1bR0a+j3rJEkbY4wgKrWbkB1duJAopz9OGB1abf3DkekGuy8a2BQDQZCV MvVUe2jNjzFK67C1E+FmpJTVNJaql7mrznXLhvZO7YKLGnfKEp6QLUJpW/z/p/hWv1CN z9AbNm56Vn/nEU8H6tfqnKiO9dBuW9ItOLxlb8s5+5TPynwEzCs9UzQAiT/RPO5ABLka k7b+hB1T+WsTryoqJft8xfniMLZZ69jaZoKAEX+92p5NaenJNT2etT0OUiIn0xOPDTVW lbH8nW059chm7JZHME39FQoJogweePGlAnhE5coyWs5NgAnf+Kr4rSIp2FMRBizCH0/I 2ekQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769901788; x=1770506588; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=odLopdMOFuzazlxMO/Jvqpu3SpD1lqSt4vEe+VI2wxE=; b=h5XOeH+YKEc2N6gaLjHXft4MlAXadDo75waXyVNdwwqyglGd6HwrwJA7Jxgmy/s7CT h6BzZSKnPqigYFKH0FWCi9ed1NwsBeT64xQIkp0eOxnzfI1kE8Mljwv+Lt8ZqtXx7iiK gTlrEBYKab57uQk4Y4PTQvooPVXC7AHr0WD8Yv2fajaFCuZCjnFOZuARoPGnRK8Z53gc bbLIy2I734WbHSeQ3+BzqU3JS7d1/UhGclaXIOfnR8hxKCCB1Omtn7SPHMdBCv2KUm/5 aQLXIThwN+549iJ+7uiw+1pqxhuKKgrEOFjqrdSZci3OjJZrPY17M5TSleN7EKEG/iCS ImXQ== X-Forwarded-Encrypted: i=1; AJvYcCUYOetXSRFp3M+trN9YKgy0Wj/d8mQoE2KHCa5yV2zybLQBimeJnTbCBDRjM4T3ICLGt/LHD95oX02eHas=@vger.kernel.org X-Gm-Message-State: AOJu0Yz+pV+SsV8LftyhLhgikbMHzVosk/uGd7XBl3rVYXHnq7QysR01 zmqYHG6ZhNLO8GL957jSdT5uzdCYlH+6TuG+VJQ6chjLuSkifZcwsZX/ X-Gm-Gg: AZuq6aK3XT70fWf3pR5Bi2exdZ1yk9vwvkoEMZAbr6CAx7ti0+rodKYKfpka9tyaZUI YMo9J333tDmtogmno9VXWXHzWHI0kMCae3T1rfKIqAnOdFPRYQvVwniSamfqxc57Q2QblEZVPfM daf3iFygm1N+icH+3ZeBMfayDCHAf1OqJnQ3ZXqWp0+dKZsfWLcmu2XWhat85Jt6ADkk+JFt7kc m8VDBgUwc9w60+zDHpTBpWZTNmaXB7Mr822Y0I9s7Q0rSnTbB4Prjc9gO4zoKPij1AD7Mfxxd8j jt83HfauwhfbhkSf4MIwPj/dBQCgs/uuJVYAFIG9fIJV/PXvCfd4vEyvRpuh2UBCj1TTHm/n0Dh 0kkQ7tI3zQu5p24QFmRI9oHGpl9djuokFrWnBZN5PuNtaAQxKh7pM/qjXk+ZM6clwoKSrrFRhxL NQnjxDeCQ3/6h4bjAhSnAn X-Received: by 2002:a05:7300:cd8d:b0:2b7:f7f:6ad with SMTP id 5a478bee46e88-2b7c88e2b66mr3514159eec.26.1769901787970; Sat, 31 Jan 2026 15:23:07 -0800 (PST) Received: from [192.168.4.196] ([73.222.117.172]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-2b7a16d01c4sm16774899eec.2.2026.01.31.15.23.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 31 Jan 2026 15:23:07 -0800 (PST) Message-ID: Date: Sat, 31 Jan 2026 15:23:06 -0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 6.12] btrfs: prevent use-after-free prealloc_file_extent_cluster() To: Qu Wenruo , boris@bur.io, clm@fb.com, dsterba@suse.com Cc: linux-btrfs@vger.kernel.org, stable@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@meta.com References: <20260131185335.72204-1-inwardvessel@gmail.com> <4c37d4e1-e656-48e3-ac80-83c09fe92625@suse.com> Content-Language: en-US From: JP Kobryn In-Reply-To: <4c37d4e1-e656-48e3-ac80-83c09fe92625@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 1/31/26 1:08 PM, Qu Wenruo wrote: > > > 在 2026/2/1 05:23, JP Kobryn 写道: >> Users of filemap_lock_folio() need to guard against the situation where >> release_folio() has been invoked during reclaim but the folio was >> ultimately not removed from the page cache. This patch covers one >> location >> that was overlooked. Affected code has changed as of 6.17, so this >> patch is >> only targeting stable trees prior. >> >> After acquiring the folio, use set_folio_extent_mapped() to ensure the >> folio private state is valid. This is especially important in the subpage >> case, where the private field is an allocated struct containing bitmap >> and >> lock data. >> >> Without this protection, the race below is possible: >> >> [mm] page cache reclaim path        [fs] relocation in subpage mode >> shrink_folio_list() >>    folio_trylock() /* lock acquired */ >>    filemap_release_folio() >>      mapping->a_ops->release_folio() >>        btrfs_release_folio() >>          __btrfs_release_folio() >>            clear_folio_extent_mapped() >>              btrfs_detach_folio_state() >>                bfs = folio_detach_private(folio) >>                btrfs_free_folio_state(folio) >>                  kfree(bfs) /* point A */ >> >>                                     prealloc_file_extent_cluster() >>                                       filemap_lock_folio() >>                                         folio_try_get() /* inc >> refcount */ >>                                         folio_lock() /* wait for lock */ >> >>    if (...) >>      ... >>    else if (!mapping || !__remove_mapping(..)) >>      /* >>       * __remove_mapping() returns zero when >>       * folio_ref_freeze(folio, refcount) fails /* point B */ >>       */ >>      goto keep_locked /* folio remains in cache */ >> >> keep_locked: >>    folio_unlock(folio) /* lock released */ >> >>                                     /* lock acquired */ >>                                     btrfs_subpage_clear_updodate() >>                                       bfs = folio->priv /* use-after- >> free */ > > This patch itself and the root cause look good to me. > > Reviewed-by: Qu Wenruo > Much appreciated :) >> >> This patch is intended as a minimal fix for backporting to affected >> kernels. As of 6.17, a commit [0] replaced the vulnerable >> filemap_lock_folio() + btrfs_subpage_clear_uptodate() sequence with >> filemap_invalidate_inode() avoiding the race entirely. That commit was >> part >> of a series with a different goal of preparing for large folio support so >> backporting may not be straight forward. > > However I'm not sure if stable tree even accepts non-upstreamed patches. > > Thus the stable maintainer may ask you the same question as I did > before, why not backport the upstream commit 4e346baee95f? That commit relies on filemap_invalidate_folio() which was introduced in 6.10 so it would not apply to earlier stable branches. We need to fix as far back as 5.15 so I can send one additional patch to cover stable trees 5.15 to 6.6. The patch would be almost identical, with the only change being using the page API instead of the folio API (set_folio_extent_mapped() -> set_page_extent_mapped()). Let me know if you're in agreement and I can send the extra patch. > > If it's lacking the reason why it's a bug fix, I believe you can modify > the commit message to include the analyze and the fixes tag. > > > I'm also curious to learn the proper way for such situation. It's new to me as well. For reference, there are some commits on the list that have language like this: "This is a stable-only fix".