Bug 2347914 (CVE-2022-49171)

Summary: CVE-2022-49171 kernel: ext4: don't BUG if someone dirty pages without asking ext4 first
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security DevOps Team <prodsec-dev>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: dfreiber, drow, jburrell, vkumar
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
A flaw in the Linux kernel’s ext4 filesystem allows memory pages to be modified without properly notifying the filesystem. This lack of synchronization can lead to inconsistent file states or system crashes, particularly in high-concurrency scenarios. The vulnerability is caused by a race condition where memory marked as "dirty" isn't communicated correctly to ext4, making it unaware of pending changes. As an interim mitigation, newer kernels issue warnings and mark affected memory pages as clean to prevent exploitation, especially by unprivileged users attempting denial-of-service attacks. Updating to a patched kernel version is recommended to ensure system reliability and data integrity.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2025-02-26 03:11:12 UTC 
In the Linux kernel, the following vulnerability has been resolved:

ext4: don't BUG if someone dirty pages without asking ext4 first

[un]pin_user_pages_remote is dirtying pages without properly warning
the file system in advance.  A related race was noted by Jan Kara in
2018[1]; however, more recently instead of it being a very hard-to-hit
race, it could be reliably triggered by process_vm_writev(2) which was
discovered by Syzbot[2].

This is technically a bug in mm/gup.c, but arguably ext4 is fragile in
that if some other kernel subsystem dirty pages without properly
notifying the file system using page_mkwrite(), ext4 will BUG, while
other file systems will not BUG (although data will still be lost).

So instead of crashing with a BUG, issue a warning (since there may be
potential data loss) and just mark the page as clean to avoid
unprivileged denial of service attacks until the problem can be
properly fixed.  More discussion and background can be found in the
thread starting at [2].

[1] https://lore.kernel.org/linux-mm/20180103100430.GE4911@quack2.suse.cz
[2] https://lore.kernel.org/r/Yg0m6IjcNmfaSokM@google.com
Comment 1 Avinash Hanwate 2025-02-26 12:41:37 UTC 
Upstream advisory:
https://lore.kernel.org/linux-cve-announce/2025022612-CVE-2022-49171-83e6@gregkh/T
Comment 4 Avinash Hanwate 2025-02-26 16:59:19 UTC 
Upstream advisory:
https://lore.kernel.org/linux-cve-announce/2025022612-CVE-2022-49171-83e6@gregkh/T