All of lore.kernel.org
 help / color / mirror / Atom feed
From: syzbot <syzbot+b0a0670332b6b3230a0a@syzkaller.appspotmail.com>
To: linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com
Subject: Forwarded: [PATCH] ext4: check folio uptodate state in ext4_page_mkwrite()
Date: Fri, 21 Nov 2025 04:41:09 -0800	[thread overview]
Message-ID: <69205de5.a70a0220.2ea503.0052.GAE@google.com> (raw)
In-Reply-To: <691f44bb.a70a0220.2ea503.0032.GAE@google.com>

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com.

***

Subject: [PATCH] ext4: check folio uptodate state in ext4_page_mkwrite()
Author: kartikey406@gmail.com

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master


When a write fault occurs on a memory-mapped ext4 file, ext4_page_mkwrite()
is called to prepare the folio for writing. However, if the folio could
not be read successfully due to filesystem corruption or I/O errors, it
will not be marked uptodate.

Attempting to write to a non-uptodate folio is problematic because:
1. We don't have valid data from the backing store to preserve
2. A subsequent writeback could write uninitialized data to disk
3. It triggers a warning in __folio_mark_dirty():
   WARN_ON_ONCE(warn && !folio_test_uptodate(folio))

This issue can be reproduced by:
1. Creating a corrupted ext4 filesystem with invalid extent entries
2. Memory-mapping a file on that filesystem
3. Attempting to write to the mapped region

The sequence of events is:
- User accesses mmap region -> page fault
- ext4_filemap_fault() -> ext4_map_blocks() detects corruption
- Returns error, folio allocated but NOT marked uptodate
- User writes to same region -> ext4_page_mkwrite() called
- Without check: folio marked dirty -> WARNING
- With check: return VM_FAULT_SIGBUS immediately

Fix this by checking folio_test_uptodate() early in ext4_page_mkwrite(),
before any code paths (delalloc, journal data, or normal). This ensures
all paths are protected. If the folio is not uptodate, unlock it and
return VM_FAULT_SIGBUS to signal the error to userspace.

Reported-by: syzbot+b0a0670332b6b3230a0a@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=b0a0670332b6b3230a0a
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
 fs/ext4/inode.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index e99306a8f47c..18a029362c1f 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -6688,6 +6688,14 @@ vm_fault_t ext4_page_mkwrite(struct vm_fault *vmf)
 	if (err)
 		goto out_ret;
 
+	folio_lock(folio);
+	if (!folio_test_uptodate(folio)) {
+		folio_unlock(folio);
+		ret = VM_FAULT_SIGBUS;
+		goto out;
+	}
+	folio_unlock(folio);
+
 	/*
 	 * On data journalling we skip straight to the transaction handle:
 	 * there's no delalloc; page truncated will be checked later; the
-- 
2.43.0


  parent reply	other threads:[~2025-11-21 12:41 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-20 16:41 [syzbot] [ext4?] WARNING in __folio_mark_dirty (3) syzbot
2025-11-21  1:34 ` Forwarded: [PATCH] ext4: check folio uptodate state in ext4_page_mkwrite() syzbot
2025-11-21 10:44 ` syzbot
2025-11-21 11:52 ` syzbot
2025-11-21 12:41 ` syzbot [this message]
2025-11-21 18:11 ` [syzbot] [ext4?] WARNING in __folio_mark_dirty (3) Andrew Morton
2025-11-21 19:02   ` Matthew Wilcox
2025-11-21 19:14     ` Andrew Morton
2025-12-02 13:25 ` Theodore Tso
2025-12-02 13:47   ` syzbot
2025-12-05  4:54 ` Forwarded: [PATCH v3] ext4: unmap invalidated folios from page tables in mpage_release_unused_pages() syzbot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=69205de5.a70a0220.2ea503.0052.GAE@google.com \
    --to=syzbot+b0a0670332b6b3230a0a@syzkaller.appspotmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=syzkaller-bugs@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.