From nobody Sun Feb 8 01:33:43 2026 Received: from mail-dy1-f173.google.com (mail-dy1-f173.google.com [74.125.82.173]) (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 121B62E2DF3 for ; Sun, 1 Feb 2026 07:14:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.173 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769930047; cv=none; b=KHvzYLlQSi5fr3pNP7m9qo8fCfoaauoQf0krEGrRAFPsMYq6qLFwUV4gkp1N/y3kbq/SZ5dhSbHfEOtrXIqV87ZexhegjkubnU8D2SmTGWYnAoe5qAwIF96UsBXZuQZznTyNwxmLHjx0GF2Nos2dAVwgXjIoi96yvyr3O1njSI8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769930047; c=relaxed/simple; bh=qQ5jEQwXfoZAkudftg+kXXDEawdvl34d9f7OgSGwN1s=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=EPnYyTcbFF+zkdXyIhf7Il+/ooo6tpxo5XKZnZ9hIVthxM7AjiF9uozASt9Zp5UcG30zJ3rawsTirZTMLRF/j9NMSpQugCvjcK2vpEAvMnl5tSs7LyvnIoS3mIN/2mtoHZ/P4yMjLNSrDYl9g9R0uU3ntIYtPIKKdZn9pYfs4sY= 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=j84VZcJm; arc=none smtp.client-ip=74.125.82.173 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="j84VZcJm" Received: by mail-dy1-f173.google.com with SMTP id 5a478bee46e88-2b7381d2d95so1850255eec.0 for ; Sat, 31 Jan 2026 23:14:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769930045; x=1770534845; 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=qZDw3vdQYiwVFo053FncWzhupEEGPJGFHynGMHSSRHQ=; b=j84VZcJm56RRlmhyhbF6M13TYBZQDSyHfYKj+mPtYXUoZsDZWBB7kRkH/VHfMrTH5Q L9F1vc16YLul8+E7GIG6SQ25m3V/fyg8uNwoin+njU0oHXfWZPw7JRFyFb//1Ur96ZWO DyhzVyI0E0gcpvb1D+6XnkcwStngOy2wn+yjDz64Ci+NUeVgjd7JWHpMcRBGB8yCu4Dz NokUKzIria6aT9Z6ANCXR13jMolZbkFSKv4p6qPKBjldEKYuDzBqEKCLXrrayWCPr1Fb meUBbdPn5cb7qZuiT8FCTKd0ns4FLtCyTH2F9YWiAEVCmpEfW6y0Xbn2VDX2BfW4JcBi QfNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769930045; x=1770534845; 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=qZDw3vdQYiwVFo053FncWzhupEEGPJGFHynGMHSSRHQ=; b=RllZs4YpFewbhxDCo+uUll/ivXb6cqRjuNsSKnjgyGvIxjpHcl8wZouJ8lt0/vf3Rg q/az8RXfLvSB1Z75lM8XbnxdEql4/9Sn4YKwe+MNlS4MIpuu/IkKR1KhSXfrEuF16wUx 7YdL2qHnNYhaZyo/BIpGOXnfINMAMPn1xMOii2b6itqb22nN8AO1KT+fiNsgJKUCdr/P FgHv4fp6BbaNzXPIL+nMTgJv8SeZ31NHSPfCBkJ82TIwDJxPTZuQ0sTM0439JX+bEsmh m1pgL6eOTzhGrEBDZ1ru55fRifKQzjeEbUxiiq4XRuUgk9zm5aGxj3ZO6FkHw9MubDVK uAlg== X-Forwarded-Encrypted: i=1; AJvYcCXoEkiP+G3BJ8KwE26gmdkhmODH16Ek8NZT05Jfv9+HNNL2Nt88a9sS7li8Ndz8EY6JTcA1bKq+xSMeqdA=@vger.kernel.org X-Gm-Message-State: AOJu0YyK/Az+HzWkZiasGAXS//P0w35ONwNVFdyPI4s26uNq5NZR5RYV I01YXznB3/qbr3LknF6WMdIw4zyeDJOgrGfSDQoQ/bQ/YIj42MZVOza6Mqk42g== X-Gm-Gg: AZuq6aJl9dFbJ1LkgVNisZlmR0CmxEMn5TWSFx4J5DLZ2d93PL/ZpaqpG+LW6kcWQdu DMAs6uS9F/91v7ya5fw1ZRA0//3t4FnnHDkVYXynvUZlTD7V0BknQO7gIztLs8prkg5omY6Ialr ymbtOTkZbDEvn6Xgd8kzczzxZqb8N03dDTLlGBrZQXFIBqgbX+0a54JyQ3zne7/A5EPYEiCfLwW A3QWhPAsdtZKbg+N65KvKLAt4AmBuPYqpeoUMzGisyA2F2i+BZyxnL6BxEYtl3eL+B7t9NLBaSl 2HBaySCdAd0H1sDpf3A1pN20yZytkAkiioc5aWg9vwgg6cBUa/CsGbAPA2rxgcRcXSDNVLiQwN/ LNKLoI0x6CacM1OnXx8v/JO9oEFhO23UoqIgCABrs5aYrN6fkKlmd6as0fLI0RynyM0TsBj1MGR 2Zw+t61zZ7J0xyVUA5Njw3PxwEpy2h3OeV4oI/EA== X-Received: by 2002:a05:7300:80cd:b0:2b7:b4f7:27de with SMTP id 5a478bee46e88-2b7c925284bmr3856136eec.6.1769930044963; Sat, 31 Jan 2026 23:14:04 -0800 (PST) Received: from jpkobryn-fedora-PF5CFKNC.lan ([73.222.117.172]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-2b7a1abe92dsm17419076eec.17.2026.01.31.23.14.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 31 Jan 2026 23:14:04 -0800 (PST) From: JP Kobryn To: wqu@suse.com, 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 Subject: [PATCH stable 6.10-6.16] btrfs: prevent use-after-free on folio private data in btrfs_subpage_clear_uptodate() Date: Sat, 31 Jan 2026 23:13:46 -0800 Message-ID: <20260201071346.130641-1-inwardvessel@gmail.com> X-Mailer: git-send-email 2.52.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" This is a stable-only patch. The issue was inadvertently fixed in 6.17 [0] as part of a refactoring, but this patch serves as a minimal targeted fix for prior kernels. 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. 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_subpage() subpage =3D folio_detach_private(folio) btrfs_free_subpage(subpage) kfree(subpage) /* 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_uptodate() /* use-after-free */ subpage =3D folio_get_private(folio) Fixes: 9d9ea1e68a05 ("btrfs: subpage: fix relocation potentially overwritin= g last page data") Cc: stable@vger.kernel.org # 6.10-6.16 Signed-off-by: JP Kobryn Reviewed-by: Qu Wenruo [0] 4e346baee95f ("btrfs: reloc: unconditionally invalidate the page cache = for each cluster") --- v2: - comment text formatting - renamed subject from "prevent use-after-free prealloc_file_extent_cluste= r()" v1: - https://lore.kernel.org/all/20260131185335.72204-1-inwardvessel@gmail.co= m/ fs/btrfs/relocation.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c index 0d5a3846811a..43e8c331168e 100644 --- a/fs/btrfs/relocation.c +++ b/fs/btrfs/relocation.c @@ -2811,6 +2811,20 @@ static noinline_for_stack int prealloc_file_extent_c= luster(struct reloc_control * will re-read the whole page anyway. */ if (!IS_ERR(folio)) { + /* + * release_folio() could have cleared the folio private data + * while we were not holding the lock. Reset the mapping if + * needed so subpage operations can access a valid private + * folio state. + */ + ret =3D set_folio_extent_mapped(folio); + if (ret) { + folio_unlock(folio); + folio_put(folio); + + return ret; + } + btrfs_subpage_clear_uptodate(fs_info, folio, i_size, round_up(i_size, PAGE_SIZE) - i_size); folio_unlock(folio); --=20 2.52.0