linux-kernel - Re: [PATCH] btrfs: guard against missing private state in lock_delalloc

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 for Android: free password hash cracker in your pocket

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

Message-ID: <2929917f-fd2b-41d5-a6b0-709c9cd826d0@gmail.com>
Date: Sat, 31 Jan 2026 10:53:30 -0800
From: JP Kobryn <inwardvessel@...il.com>
To: Qu Wenruo <wqu@...e.com>, boris@....io, clm@...com, dsterba@...e.com
Cc: linux-btrfs@...r.kernel.org, linux-kernel@...r.kernel.org,
 kernel-team@...a.com
Subject: Re: [PATCH] btrfs: guard against missing private state in
 lock_delalloc_folios()

On 1/30/26 6:15 PM, Qu Wenruo wrote:
> 
> 
> 在 2026/1/31 12:04, JP Kobryn 写道:
>> Users of filemap_lock_folio() need to guard against the situation where
>> release_folio() has been invoked during reclaim but the folio was
>> ultimately not removed from the page cache. This patch covers one 
>> location
>> which may have been overlooked.
>>
>> After acquiring the folio, use set_folio_extent_mapped() to ensure the
>> folio private state is valid. This is especially important in the subpage
>> case, where the private field is an allocated struct containing bitmap 
>> and
>> lock data.
>>
>> Failing calls (with -ENOMEM) are treated as transient errors and 
>> execution
>> will follow the existing "try again" path.
>>
>> Signed-off-by: JP Kobryn <inwardvessel@...il.com>
>> ---
>>   fs/btrfs/extent_io.c | 12 ++++++++++++
>>   1 file changed, 12 insertions(+)
>>
>> diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
>> index 3df399dc8856..573b29f62bc1 100644
>> --- a/fs/btrfs/extent_io.c
>> +++ b/fs/btrfs/extent_io.c
>> @@ -332,6 +332,18 @@ static noinline int lock_delalloc_folios(struct 
>> inode *inode,
>>                   folio_unlock(folio);
>>                   goto out;
>>               }
>> +
>> +            /*
>> +             * release_folio() could have cleared the folio private data
>> +             * while we were not holding the lock.
>> +             * Reset the mapping if needed so subpage operations can 
>> access
>> +             * a valid private folio state.
>> +             */
>> +            if (set_folio_extent_mapped(folio)) {
>> +                folio_unlock(folio);
>> +                goto out;
>> +            }
> 
> If the folio is released meaning it will not have dirty flag.
> Then the above folio_test_dirty() should be triggered and exit with - 
> EAGAIN. We will re-search the extent io tree to re-grab a proper 
> delalloc range.
> 

Thanks for ruling that one out. It seems that there are no other
vulnerabilities in mainline at the moment. Stand by for one more patch
at a different location targeting the 6.12 stable tree.