From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8A58A5218B0 for ; Thu, 17 Sep 2026 16:32:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789662764; cv=none; b=b1V4nms9BAQaGfk1kqZfjwah1iWP6Amhheb+zTywhJCYbWf7wAKCEP9gHj7gHNJwf+Tca8XbNxeaUFh8Z3jOOJjZ4xiBiaUbyNNg2bFoMJMIY1Njxu0IVzsiOR4hPz4nMKafDF/MML69IiSoz04ebl21i+Bq1rT2LLQ2sWaB8nk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789662764; c=relaxed/simple; bh=AjbaFhfm6c+81Pw59fEDwqSPMeden7ac4eYkmwtnwT4=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=Xk9ITd9U0TmdZ07FkVq7EseBWrYFUdtVAnmejZduTw1rEZL3I7kGxyCPrVipvbWEWFpfS+z43CK5kTdB/iNdeDlpFxt6BriU37PtC4+qn2vw4vQow8At1W08wXtqrIgJ6FBowQxtz4cOkpg5W0Sak9vhHohtR7ox6No7VsH9wbU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=v8cH/NFb; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="v8cH/NFb" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7B6851F000FF; Thu, 17 Sep 2026 16:32:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1789662763; bh=yTVqxoQqA7GGgx4dZKz3HBtoJ1vsmvsS9W7jvDow6oU=; h=From:To:Cc:Subject:Date:Reply-To; b=v8cH/NFbVYWHRNWpUJg1lqdmZniwMb+BmIeWCfvJVsmo/CSFQx2kHWM5djtFe/qXa MfKSJSvUZ56JnKIYjM1B+hwFPLHnZPl3A5vPr753jYeQB/zM05X6CbF/F0OkmbMc07 sucCIgzkwnH+rOKbtzmVEM9B9BunpMpgQKVifD+Q= From: Greg Kroah-Hartman To: linux-cve-announce@vger.kernel.org Cc: Greg Kroah-Hartman Subject: CVE-2026-92502: ext4: clear stale xarray tags on folios skipped during writeback Date: Thu, 17 Sep 2026 17:14:52 +0100 Message-ID: <2026091727-CVE-2026-92502-e027@gregkh> X-Mailer: git-send-email 2.55.0 Reply-To: , Precedence: bulk X-Mailing-List: linux-cve-announce@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=4942; i=gregkh@linuxfoundation.org; h=from:subject:message-id; bh=JMoGazlVge3Z2NXMidcAT0Vttl1mbCK7sLyciX3FbpQ=; b=owGbwMvMwCRo6H6F97bub03G02pJDFlrBLavUBJZdfjqmrBbJr+KfV/dvP+oYKZcoqbH30WHQ ndu3q6V3BHLwiDIxCArpsjyZRvP0f0VhxS9DG1Pw8xhZQIZwsDFKQAT2RbEMD/pwWNPWfGGY+se m1+8MLFfcl1MzDyGBduOTTqzd5PC1PK5B6xVynMYZjeoSQEA X-Developer-Key: i=gregkh@linuxfoundation.org; a=openpgp; fpr=F4B60CC5BF78C2214A313DCB3147D40DDB2DFB29 Content-Transfer-Encoding: 8bit From: Greg Kroah-Hartman Description =========== In the Linux kernel, the following vulnerability has been resolved: ext4: clear stale xarray tags on folios skipped during writeback In data=journal mode, the writeback thread can hit the WARN_ON_ONCE(sb_rdonly(sb)) in ext4_journal_check_start() while the superblock is being remounted read-only during reboot: Workqueue: writeback wb_workfn (flush-253:0) RIP: 0010:ext4_journal_check_start+0x8b/0xd0 Call Trace: __ext4_journal_start_sb+0x3c/0x1e0 mpage_prepare_extent_to_map+0x4af/0x580 ext4_do_writepages+0x3c0/0x1080 ext4_writepages+0xc8/0x1a0 do_writepages+0xc4/0x180 __writeback_single_inode+0x45/0x2f0 writeback_sb_inodes+0x26b/0x5d0 __writeback_inodes_wb+0x54/0x100 wb_writeback+0x1ac/0x320 wb_workfn+0x394/0x470 And followed by the warning: EXT4-fs warning (device vda1): ext4_evict_inode:195: inode #6263: comm (sd-umount): data will be lost This issue is not reproduced every time, but frequently. The reproduction step is to create a VM with 8 CPUs, 16G memory and setup data=journal: sudo tune2fs -o journal_data /dev/vda1 Run fio: rm -f fiotest fio --name=fiotest --rw=randwrite --bs=4k --runtime=6 --ioengine=libaio --iodepth=256 --numjobs=8 --filename=fiotest --filesize=30G --group_reporting Reboot the VM, and check the console output from: virsh console testvm But there is no dirty inode, folio_clear_dirty_for_io clears PG_dirty but leaves tags PAGECACHE_TAG_DIRTY and PAGECACHE_TAG_TOWRITE set which are only cleared by __folio_start_writeback. In data=journal mode, jbd2 checkpoints the journalled data to its final location and clears its own dirty flag without touching folio PG_dirty or xarray dirty flags. The commit f4a2b42e7891 ("ext4: fix stale xarray tags after writeback") fixes when PG_dirty is still set but there is no dirty page. Another case is PG_dirty is cleared, but PAGECACHE_TAG_DIRTY and PAGECACHE_TAG_TOWRITE is still set. In this case, writeback thread checks clean folio and skips it in mpage_prepare_extent_to_map: if (!folio_test_dirty(folio) || ... folio_unlcok(folio); continue And never reaches ext4_bio_write_folio where the commit f4a2b42e7891 clears the stale xarray tags. Print debug logs after the filesystem is remounted read-only: writepages RDONLY nrpages=2048 dirtytag=1 wbtag=0 towrite=1 sync=0 And all folios are actually clean: folio idx=3 dirty=0 wb=0 checked=0 dirtybuf=0 jbddirty=0 mapped=1 ... We need to clear the xarray stale tags for such clean folios by cycling them through writeback in the skip path, the same way f4a2b42e7891 does in ext4_bio_write_folio. The Linux kernel CVE team has assigned CVE-2026-92502 to this issue. Affected and fixed versions =========================== Issue introduced in 6.2 with commit dff4ac75eeeefc4397fe7cf8ce559425bf46b1f7 and fixed in 6.6.157 with commit f82a4929d0ef7ddf254c1c295ec1dfd24094f2de Issue introduced in 6.2 with commit dff4ac75eeeefc4397fe7cf8ce559425bf46b1f7 and fixed in 6.12.110 with commit a450ab88bfd57b227d72c7a3faad54d16c3fc099 Issue introduced in 6.2 with commit dff4ac75eeeefc4397fe7cf8ce559425bf46b1f7 and fixed in 6.18.52 with commit aa0042630b1f7cab735b0a168539281198822586 Issue introduced in 6.2 with commit dff4ac75eeeefc4397fe7cf8ce559425bf46b1f7 and fixed in 7.2.6 with commit 43ae387c3ae6a11227d096669ddf883e27a39a11 Issue introduced in 6.2 with commit dff4ac75eeeefc4397fe7cf8ce559425bf46b1f7 and fixed in 7.3-rc1 with commit ec524aae479b4b2078c47492b90ec21200bce434 Please see https://www.kernel.org for a full list of currently supported kernel versions by the kernel community. Unaffected versions might change over time as fixes are backported to older supported kernel versions. The official CVE entry at https://cve.org/CVERecord/?id=CVE-2026-92502 will be updated if fixes are backported, please check that for the most up to date information about this issue. Affected files ============== The file(s) affected by this issue are: fs/ext4/inode.c Mitigation ========== The Linux kernel CVE team recommends that you update to the latest stable kernel version for this, and many other bugfixes. Individual changes are never tested alone, but rather are part of a larger kernel release. Cherry-picking individual commits is not recommended or supported by the Linux kernel community at all. If however, updating to the latest release is impossible, the individual changes to resolve this issue can be found at these commits: https://git.kernel.org/stable/c/f82a4929d0ef7ddf254c1c295ec1dfd24094f2de https://git.kernel.org/stable/c/a450ab88bfd57b227d72c7a3faad54d16c3fc099 https://git.kernel.org/stable/c/aa0042630b1f7cab735b0a168539281198822586 https://git.kernel.org/stable/c/43ae387c3ae6a11227d096669ddf883e27a39a11 https://git.kernel.org/stable/c/ec524aae479b4b2078c47492b90ec21200bce434