From nobody Tue Jun 9 01:18:55 2026 Received: from mail-pj1-f48.google.com (mail-pj1-f48.google.com [209.85.216.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 920342030A for ; Mon, 25 May 2026 05:30:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.48 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779687025; cv=none; b=mLuAK6uA3yCDq1qHBAHnekHJ+mLgH7C1cIL94Ricggh2bc65nqd1XkebKuc78UAJA03Q+JRlr1KYmKl9ZanAQN6yw7XQfWHTX1IMt0rRL+bcTI3BIyQ4hTFucjB1/0JhEs7ndSggWJccNbvRa+hBwPyzVk6VyAKDm5a35H8i5eo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779687025; c=relaxed/simple; bh=CSAAJChMjln2dRVEBUauXYZprWkb+dBQHIMXx/aiSHo=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=OEMv2q6lEngyV3TfetU1XwMCTJDqaN9GHF4bBEYw3wNgElWb5Ja48SKU1GxjF5xNgabo/G6Zb9J2Sg08oOW7xff8mj2h84sRT1ybar8A/3MwjykRiTm7CWi+KtxCluKOCA+0aOK4wPRHwFwW1NHcDhNTtt76xOPonARKhGs54nw= 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=jfKdGjAs; arc=none smtp.client-ip=209.85.216.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="jfKdGjAs" Received: by mail-pj1-f48.google.com with SMTP id 98e67ed59e1d1-36a7bbb9698so1438673a91.2 for ; Sun, 24 May 2026 22:30:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779687024; x=1780291824; 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=mmULhzMqQgIJ++PNrW86VNXnjitDHbIlXJa6RMFWk4k=; b=jfKdGjAstp1ytP4OW1lEcaGtq9GA4441SfdLDyid/HMh8wPNEiMGqVlh+iUuNgJBTg f1kakCxUl3nWNUBp5D7HdPysbYgtZGPhLUSPI00fYqEQ7wa+kAE6pgCObvMNLbGm6ggh A0Cy44Vg/gfXh4W/N2mUzgM109By9V19ZTG+lBiirkMOPDki6Cu1ixhdUAhsq+xEITX5 +SENfeIsrkCKcNao/p+FLZza6Hh1NFlS4RqfPEQJhUMJKWMe9IBO9p7uIs2Sk1sheJ8E oas2n72O1wKyzzmbZtEsGB1pt9nLAgBUprEWfnRRa2g/TyakQ8rP8bjDaChLcyKmp14a ysdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779687024; x=1780291824; 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=mmULhzMqQgIJ++PNrW86VNXnjitDHbIlXJa6RMFWk4k=; b=LEMxgoSDp+jCIWc97VD35YBlshQpTTVmJ26bchvnz5jZ9pDzc4bvd0MqtZJx880bHD gHnbky9YuAFhNIblg0AAh9AuSBDhwaVf0+/SUBoutMRYzLxzLR+bat2+Dq4H2RIZQqsj B0Yyu3bo0PJKHx1XnGskWImrBw+p1Gge2sHshlGVm9Wwr9FqfZLz+QwkqmED+VGsw3YL NUQ09WXCZ+9yycceKlPmYOMYrVoFbG2QaO5JO6DEN88zJQ6bBJhJo1RgkjYDUlNnDRWC nymUk6la+lgGSqc5dMynGAC7Df0lcz8998Raxj0LTU6KEfcv5uUC9ZaeCxqM0Djz2/f9 fpiQ== X-Forwarded-Encrypted: i=1; AFNElJ9p/piPycfkYzZalpT9SaPoVufaK7XRo5pfKtQM3vU/UB/PdM1oYT7qhmZINVbFZQkJPdobXHW/v5hdL4M=@vger.kernel.org X-Gm-Message-State: AOJu0YwlZtdpanXRs2B+oJQDsWh2jXgPY4cZ9d2VIWAfj+xMEevJIRy1 aWY1TTUYIFdmEujdvqwvZJyhjffSZgfuKRijBw+60IkHjnL14N6jSXCD X-Gm-Gg: Acq92OHhQKUBMO5RArJBNfOB1FqLNsoCiVVfK6EmtWcIyccvnj38CBsViTucDw7qoOg sNs22/mpe88bY1FlVIhWqmAjFLup4Bvdo5LW5LRb/2VgBvsoXBx9m0Xc++CZ8bWSofX2k72tMmB LYhsZMCbpyifdhrGCDIf3vo6gRdDyomMMcfecVwvj8ibbSzMoLDSHnZ/4518kJFzL7OVnkp3ZZM RkLNo2aDERX7usKMQnqJNxDDQrlFuqGFFxWd288LaEAscH2wXbMELEpNywhiNUMrtB46Nleu2nc aPbIwI/GbEMgWCN9Z/CEArqkMteIsf1xbffr+di0NkMK6UDOenNCoHrDLaf//XxyVkzh/C400aS hQ4zrHh661KfJN3tzaE9NSh9e9RMeoNpqC1VGqharMpLK4yGAvuPe2/gZmtk3KfkHTLfkiDc/Oc IU3w5LJyTCGZlSwCeYJILhXYPDAsnS81bMGCxSs+390SjqZhmHaaDaMssvyCcg7lim8S0R5g== X-Received: by 2002:a17:90b:4fc2:b0:368:3854:3a2e with SMTP id 98e67ed59e1d1-36a676d2e82mr14823899a91.26.1779687023292; Sun, 24 May 2026 22:30:23 -0700 (PDT) Received: from qiwenjie-ThinkCentre-M760t.mioffice.cn ([43.224.245.241]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-36a72c4cd92sm8554452a91.10.2026.05.24.22.30.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 24 May 2026 22:30:22 -0700 (PDT) From: Wenjie Qi X-Google-Original-From: Wenjie Qi To: jaegeuk@kernel.org, chao@kernel.org Cc: yangyongpeng@xiaomi.com, geoo115@gmail.com, linux-f2fs-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, qiwenjie@xiaomi.com, qwjhust@gmail.com, stable@kernel.org Subject: [PATCH] f2fs: avoid cp_wait use-after-free in f2fs_write_end_io() Date: Mon, 25 May 2026 13:30:16 +0800 Message-ID: <20260525053016.169150-1-qiwenjie@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: quoted-printable Content-Type: text/plain; charset="utf-8" f2fs_write_end_io() currently decrements the writeback page counter before waking sbi->cp_wait for the last F2FS_WB_CP_DATA completion. That decrement can drop the F2FS_WB_CP_DATA count to zero. It can unblock a concurrent unmount path waiting in f2fs_wait_on_all_pages(). Unmount can continue through f2fs_put_super() and eventually free sbi while the end_io callback is still about to evaluate wq_has_sleeper() and wake_up() on sbi->cp_wait. Commit 2d9c4a4ed4ee ("f2fs: fix UAF caused by decrementing sbi->nr_pages[] in f2fs_write_end_io()") fixed one post-decrement sbi access by moving the warm-node-list handling before dec_page_count(). The compressed writeback path follows the same rule and documents that dec_page_count() must be the last access to sbi when it can drop F2FS_WB_CP_DATA to zero. Apply the same ordering rule to the cp_wait wakeup. Check whether this is the last F2FS_WB_CP_DATA completion and wake the waiter before the counter decrement. Then the callback no longer dereferences sbi->cp_wait after the lifetime boundary. A waiter that runs before the decrement may observe old count and sleep until the one-jiffy timeout, but correctness no longer depends on touching sbi after the counter reaches zero. Fixes: ce2739e482bc ("f2fs: fix to avoid UAF in f2fs_write_end_io()") Cc: stable@kernel.org Signed-off-by: Wenjie Qi --- fs/f2fs/data.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c index d83a21998ec2..b1e9fb5ca159 100644 --- a/fs/f2fs/data.c +++ b/fs/f2fs/data.c @@ -392,16 +392,16 @@ static void f2fs_write_end_io(struct bio *bio) if (f2fs_in_warm_node_list(folio)) f2fs_del_fsync_node_entry(sbi, folio); =20 - dec_page_count(sbi, type); - /* - * we should access sbi before folio_end_writeback() to - * avoid racing w/ kill_f2fs_super() + * Access sbi before dec_page_count() and folio_end_writeback() + * to avoid racing w/ kill_f2fs_super(). */ - if (type =3D=3D F2FS_WB_CP_DATA && !get_pages(sbi, type) && - wq_has_sleeper(&sbi->cp_wait)) + if (type =3D=3D F2FS_WB_CP_DATA && get_pages(sbi, type) =3D=3D 1 && + wq_has_sleeper(&sbi->cp_wait)) wake_up(&sbi->cp_wait); =20 + dec_page_count(sbi, type); + folio_clear_f2fs_gcing(folio); folio_end_writeback(folio); } --=20 2.43.0