linux-kernel - Re: [PATCH v2] 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251205021818.GF71988@macsyma.lan>
Date: Thu, 4 Dec 2025 21:18:18 -0500
From: "Theodore Tso" <tytso@....edu>
To: Deepanshu Kartikey <kartikey406@...il.com>
Cc: Matthew Wilcox <willy@...radead.org>, Zhang Yi <yi.zhang@...weicloud.com>,
        linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org,
        syzbot+b0a0670332b6b3230a0a@...kaller.appspotmail.com,
        adilger.kernel@...ger.ca, djwong@...nel.org
Subject: Re: [PATCH v2] ext4: check folio uptodate state in
 ext4_page_mkwrite()

On Thu, Dec 04, 2025 at 03:24:50PM +0530, Deepanshu Kartikey wrote:
> Based on Matthew's earlier feedback that we need to "prevent !uptodate
> folios from being referenced by the page tables," I believe the
> correct fix is not in ext4_page_mkwrite() at all, but rather in
> mpage_release_unused_pages().
> 
> When we invalidate folios due to writeback failure, we should also
> unmap them from page tables....

Hmm.... if the page is mmap'ed into the user process, on a writeback
failure, the page contents will suddenly and without any warning,
*disappear*.

So the other option is we could simply *not* invalidate the folio, but
instead leave the folio dirty.  In some cases, where a particular
block group is corrupted, if we retry the block allocation, the
corrupted block group will be busied out, and so when the write back
is retried, it's possible that the data will be actually be persisted.

We do need to make sure the right thing we unmount the filesystem,
since at that point, we have no choice but the invalidate the page and
the data will get lost when the file system is unmounted.  So it's a
more complicated approach.  But if this is happening when the file
system is corrupted, especially if it was maliciously corrupted, all
bets are off anyway, so maybe it's not worth the complexity.

     	     	     	      	       - Ted