From nobody Sat Feb 7 17:41:59 2026 Received: from mail-dl1-f48.google.com (mail-dl1-f48.google.com [74.125.82.48]) (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 17006284895 for ; Sun, 1 Feb 2026 07:10:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.48 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769929836; cv=none; b=uI7+u2dwcaORxhgYgN/v6ruxPvA+wz3dpfC/6TcdPLbJXWb3I0C8Mg+Y7w/w2U5r2HbxugqBrXEmhnC1oiN4GN0slak7S/6wV0vk8+s9Us81yeC+KppHX2d6QkEf833ZSO3ax65ZuOaD4Qf+2I3ja3+F1Fg7hE9ALIRMwSjytjw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769929836; c=relaxed/simple; bh=/+vbohuWCeA5apK0xQZdqX1BArl3qOvcWSMuYG2I2XM=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=HQ5E6Qt2yBwGsV2aqf85YmfnYXvXUlRTue15hUV+Z+45MgAV6cbVrJYVvivHjtV++wgHPcZgW+SLhyUR3RWCfaDKJKZiO76NG/XF/nMRvypOOBU2MGz6OleYYiGIqbeOEfcUpL+OgrXS7X5ofckTeiCky+8MWtowdw6L5gqfQGE= 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=QT2zH3zP; arc=none smtp.client-ip=74.125.82.48 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="QT2zH3zP" Received: by mail-dl1-f48.google.com with SMTP id a92af1059eb24-124a635476fso5023639c88.0 for ; Sat, 31 Jan 2026 23:10:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769929834; x=1770534634; 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=wzXD3tBTqqP8oZwwUMhbpbowxhGXxwF671sYxC/ntIA=; b=QT2zH3zPCQnaqkgMKXnabxiywIRFiR9McJxKxMOf7c0tLMmQuHhGWxJjcpVKXEA+uc gCxH1cAJ6gkU10dRj5oDwXt9IaQPZAj/RUCdldUMoKaQ4AMkpFWewsW0pCoJTd+Tytck U4Wqf7i68iygwYSVRnx8YLc5R2Z9UgWYuYgz+QYp1ea5c/iNEvVUIJcJ8ZUnku1fT1Tc 1B4yzd04iAvGVU58k1jBH0BSCMOatxHp9AEDnVK18ZHFr8iEA/5YJ8mQIQP9E/e1w3Qg UlGxY8jGJ9F8oWT5+T/sGviYu8ncau21QDL8/+TnM1tuyH+Na4fmyW+oOBw5gstIYrN/ qG4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769929834; x=1770534634; 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=wzXD3tBTqqP8oZwwUMhbpbowxhGXxwF671sYxC/ntIA=; b=tjpzKspxE0BTP+YG06w1l/5JeSjaZ3ywptMBhVKnBCw/utVwv6z8c5UYHnbjzOBmCJ Xv2lzZqs+OZEqYh7F0Ep64GHGJIaztzc/GflJGsTjVP8eH54PPmSkud3lxhzojnV33rG o7hxst4lCcXb8nPca1exN9apCgRVBWzQPKbxmZF5ZifBaOgi5ZJMn+dM8ipdylSkt3KN qMjP2FhDjgeWso5e8piQ+z9mgr5X3oO9N7MvBCsoff11NsbbkF0nz6CQt+cLk+ZTNncc MNU7qjjvg07t1psPZAYC2wGKRNvO0kcW7x5iXa7tjjt7oBaJLX6FCJRew5pQND1dxg55 wOow== X-Forwarded-Encrypted: i=1; AJvYcCWQ3xawlB/16Fc+YJUKNev10yK0kDpOceyhSCueHCN2IszBjyUcuuCXNrY46CNoKHAGcA+7HCK3KvEkEKY=@vger.kernel.org X-Gm-Message-State: AOJu0YwzQZ6ySQlXOrvTEMNssBW+DMFY07iM+tHosPLtFI71GtpPF+k0 YH95nI4OdyVfOBBQoerOpHwIdyXbXLedmojIZnKh96ZlrDPDi87ttA75 X-Gm-Gg: AZuq6aIEVRr4nx0h91vW8BsqjNavuuFKi+dzc3klPKOy6HyP9a7rmUycnEbfXqH9DBe lLU0vPwQaFFT+//HCbfLi8zmnX4t3ZSJ4oEjCpIy8fw46jQMaOJR426CGCHzQU0Zz0k/9swV6u+ xocvTOyl10FAqUSMTqTbHDlOvFFAo3RV0Th0rU9NXEXPkSnotEQ9ekcQ6lpT38l62jVx4CLSqFd RtncRmn8DqKFm3SHKWWZsxSlkTflFW98pzXZxLT8zKV5bdLgm5IL1x+tymMVQfcwdTHg2g/KdTn 8nBIlO7pg98tOwCJZpZJDoa2JV0Cpvi3kqXEEr4qH//jbTdG5k3QjUQQARB1pannCDr9CIYqAlr AVqWgMgv6hF66uPGJ3I2kuYr8Bf8JV+AFWc1v3T91Te+hNlpih0ZmZjqX+zVAGf4a0dBqjeKJOp Lsr/B4QdSPpGFHaC2okqO5rTpdLH8scsG7m7dfqQ== X-Received: by 2002:a05:7022:e1f:b0:11e:3e9:3e8c with SMTP id a92af1059eb24-125c101b3demr4250108c88.49.1769929834048; Sat, 31 Jan 2026 23:10:34 -0800 (PST) Received: from jpkobryn-fedora-PF5CFKNC.lan ([73.222.117.172]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-124a9d6b663sm15486422c88.1.2026.01.31.23.10.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 31 Jan 2026 23:10:33 -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 5.15-6.9] btrfs: prevent use-after-free on page private data in btrfs_subpage_clear_uptodate() Date: Sat, 31 Jan 2026 23:09:53 -0800 Message-ID: <20260201070953.129723-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 find_lock_page() need to guard against the situation where releasepage() has been invoked during reclaim but the page was ultimately not removed from the page cache. This patch covers one location that was overlooked. After acquiring the page, use set_page_extent_mapped() to ensure the page 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_page_list() trylock_page() /* lock acquired */ try_to_release_page() mapping->a_ops->releasepage() btrfs_releasepage() __btrfs_releasepage() clear_page_extent_mapped() btrfs_detach_subpage() subpage =3D detach_page_private(page) btrfs_free_subpage(subpage) kfree(subpage) /* point A */ prealloc_file_extent_cluster() find_lock_page() page_cache_get_speculative() lock_page() /* wait for lock */ if (...) ... else if (!mapping || !__remove_mapping(..)) /* * __remove_mapping() returns zero when * page_ref_freeze(page, refcount) fails /* point B */ */ goto keep_locked /* page remains in cache */ keep_locked: unlock_page(page) /* lock released */ /* lock acquired */ btrfs_subpage_clear_uptodate() /* use-after-free */ subpage =3D page->private Fixes: 9d9ea1e68a05 ("btrfs: subpage: fix relocation potentially overwritin= g last page data") Cc: stable@vger.kernel.org # 5.15 - 6.9 Signed-off-by: JP Kobryn [0] 4e346baee95f ("btrfs: reloc: unconditionally invalidate the page cache = for each cluster") --- fs/btrfs/relocation.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c index 96c89884988b..e66ec0c23153 100644 --- a/fs/btrfs/relocation.c +++ b/fs/btrfs/relocation.c @@ -2900,6 +2900,19 @@ static noinline_for_stack int prealloc_file_extent_c= luster( * will re-read the whole page anyway. */ if (page) { + /* + * releasepage() could have cleared the page private data while + * we were not holding the lock. Reset the mapping if needed so + * subpage operations can access a valid private page state. + */ + ret =3D set_page_extent_mapped(page); + if (ret) { + unlock_page(page); + put_page(page); + + return ret; + } + btrfs_subpage_clear_uptodate(fs_info, page, i_size, round_up(i_size, PAGE_SIZE) - i_size); unlock_page(page); --=20 2.52.0