linux-kernel - Re: [PATCH] ext4: check folio uptodate state in ext4_page

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>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CADhLXY7ZUmCFd07_DwwXhiQ3v4chjT7Zwv2=F9YKZiEqSTWCUg@mail.gmail.com>
Date: Fri, 21 Nov 2025 22:19:08 +0530
From: Deepanshu Kartikey <kartikey406@...il.com>
To: "Darrick J. Wong" <djwong@...nel.org>
Cc: tytso@....edu, adilger.kernel@...ger.ca, linux-ext4@...r.kernel.org, 
	linux-kernel@...r.kernel.org, 
	syzbot+b0a0670332b6b3230a0a@...kaller.appspotmail.com
Subject: Re: [PATCH] ext4: check folio uptodate state in ext4_page_mkwrite()

On Fri, Nov 21, 2025 at 9:57 PM Darrick J. Wong <djwong@...nel.org> wrote:
>
> On Fri, Nov 21, 2025 at 06:43:05PM +0530, Deepanshu Kartikey wrote:
> > 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
>
>     ^^^^^^^^^^^^^^^^^^ what function is this?
>
> $ grep ext4_filemap_fault fs/ext4/
> $
>
> > - 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
>
> Doesn't filemap_fault bring the contents into the folio and return
> VM_FAULT_SIGBUS if that fails?
>

Thank you for the review and for catching these issues!

You're absolutely right - ext4_filemap_fault() doesn't exist, and I
apologize for the confusion in my commit message. I need to do a more
thorough investigation of the actual code paths and understand precisely
when and how a non-uptodate folio can reach ext4_page_mkwrite().

I'll trace through the code more carefully, verify the exact reproduction
scenario with the syzbot reproducer, and ensure my analysis is accurate
before sending a v2. I want to make sure I fully understand:

1. The actual function call path (filemap_fault() and its error handling)
2. Under what conditions a non-uptodate folio can exist at mkwrite time
3. Whether filemap_fault() already handles all error cases appropriately

I'll get back to you once I have a clearer understanding of the issue.

Thank you again for your patience and guidance!

Best regards,
Deepanshu