linux-kernel - [PATCH v3] ext4: unmap invalidated folios from page tables in mpage_release_unused

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20251205055914.1393799-1-kartikey406@gmail.com>
Date: Fri,  5 Dec 2025 11:29:14 +0530
From: Deepanshu Kartikey <kartikey406@...il.com>
To: tytso@....edu,
	adilger.kernel@...ger.ca,
	willy@...radead.org
Cc: linux-ext4@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	yi.zhang@...weicloud.com,
	djwong@...nel.org,
	Deepanshu Kartikey <kartikey406@...il.com>,
	syzbot+b0a0670332b6b3230a0a@...kaller.appspotmail.com
Subject: [PATCH v3] ext4: unmap invalidated folios from page tables in mpage_release_unused_pages()

When delayed block allocation fails (e.g., due to filesystem corruption
detected in ext4_map_blocks()), the writeback error handler calls
mpage_release_unused_pages(invalidate=true) which invalidates affected
folios by clearing their uptodate flag via folio_clear_uptodate().

However, these folios may still be mapped in process page tables. If a
subsequent operation (such as ftruncate calling ext4_block_truncate_page)
triggers a write fault, the existing page table entry allows access to
the now-invalidated folio. This leads to ext4_page_mkwrite() being called
with a non-uptodate folio, which then gets marked dirty, triggering:

    WARNING: CPU: 0 PID: 5 at mm/page-writeback.c:2960
    __folio_mark_dirty+0x578/0x880

    Call Trace:
     fault_dirty_shared_page+0x16e/0x2d0
     do_wp_page+0x38b/0xd20
     handle_pte_fault+0x1da/0x450

The sequence leading to this warning is:

1. Process writes to mmap'd file, folio becomes uptodate and dirty
2. Writeback begins, but delayed allocation fails due to corruption
3. mpage_release_unused_pages(invalidate=true) is called:
   - block_invalidate_folio() clears dirty flag
   - folio_clear_uptodate() clears uptodate flag
   - But folio remains mapped in page tables
4. Later, ftruncate triggers ext4_block_truncate_page()
5. This causes a write fault on the still-mapped folio
6. ext4_page_mkwrite() is called with folio that is !uptodate
7. block_page_mkwrite() marks buffers dirty
8. fault_dirty_shared_page() tries to mark folio dirty
9. block_dirty_folio() calls __folio_mark_dirty(warn=1)
10. WARNING triggers: WARN_ON_ONCE(warn && !uptodate && !dirty)

Fix this by unmapping folios from page tables before invalidating them
using unmap_mapping_pages(). This ensures that subsequent accesses
trigger new page faults rather than reusing invalidated folios through
stale page table entries.

Note that this results in data loss for any writes to the mmap'd region
that couldn't be written back, but this is expected behavior when
writeback fails due to filesystem corruption. The existing error message
already states "This should not happen!! Data will be lost".

Changes in v3:
- Complete redesign based on feedback from Matthew Wilcox and Ted Ts'o
- Moved fix from ext4_page_mkwrite() to mpage_release_unused_pages()
- Now unmaps folios from page tables before invalidation using
  unmap_mapping_pages()
- Prevents non-uptodate folios from being accessible via stale PTEs
- No performance impact (only affects error path with invalidate=true)
- Removed folio_lock() overhead from page fault path

Changes in v2:
- Corrected explanation of when folios become non-uptodate
- Added detailed description of mpage_release_unused_pages() invocation
- Clarified that folio_clear_uptodate() is explicitly called during
  error handling, not a side effect

Reported-by: syzbot+b0a0670332b6b3230a0a@...kaller.appspotmail.com
Tested-by: syzbot+b0a0670332b6b3230a0a@...kaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=b0a0670332b6b3230a0a
Suggested-by: Matthew Wilcox <willy@...radead.org>
Signed-off-by: Deepanshu Kartikey <kartikey406@...il.com>
---
 fs/ext4/inode.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index e99306a8f47c..16f73c0c33c4 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -1749,8 +1749,17 @@ static void mpage_release_unused_pages(struct mpage_da_data *mpd,
 			BUG_ON(!folio_test_locked(folio));
 			BUG_ON(folio_test_writeback(folio));
 			if (invalidate) {
-				if (folio_mapped(folio))
+				if (folio_mapped(folio)) {
 					folio_clear_dirty_for_io(folio);
+					/*
+					 * Unmap folio from page tables to prevent subsequent
+					 * accesses through stale PTEs. This ensures future
+					 * accesses trigger new page faults rather than reusing
+					 * the invalidated folio.
+					 */
+					unmap_mapping_pages(folio->mapping, folio->index,
+							    folio_nr_pages(folio), false);
+				}
 				block_invalidate_folio(folio, 0,
 						folio_size(folio));
 				folio_clear_uptodate(folio);
-- 
2.43.0