CVE-2022-49171
published 2025-02-26CVE-2022-49171: 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…
PriorityP420medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.27%
19.0th percentile
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/[email protected]
[2] https://lore.kernel.org/r/[email protected]
Affected
23 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 5.17.3-1 (bookworm) | linux 5.17.3-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= a42afc5f56f319107e987aa6adf2f65d93d527c7 < 5db60e76edf5680ff1f3a7221036fc44b308f146 | 5db60e76edf5680ff1f3a7221036fc44b308f146 |
| linux | linux | >= a42afc5f56f319107e987aa6adf2f65d93d527c7 < d666dfaa571465a19f014534a214c255ea33f301 | d666dfaa571465a19f014534a214c255ea33f301 |
| linux | linux | >= a42afc5f56f319107e987aa6adf2f65d93d527c7 < 0d3a6926f7e8be3c897fa46216ce13b119a9f56a | 0d3a6926f7e8be3c897fa46216ce13b119a9f56a |
| linux | linux | >= a42afc5f56f319107e987aa6adf2f65d93d527c7 < 5a016c053f426a73752c3b41b60b497b58694d48 | 5a016c053f426a73752c3b41b60b497b58694d48 |
| linux | linux | >= a42afc5f56f319107e987aa6adf2f65d93d527c7 < 330d0e44fc5a47c27df958ecdd4693a3cb1d8b81 | 330d0e44fc5a47c27df958ecdd4693a3cb1d8b81 |
| linux | linux | >= a42afc5f56f319107e987aa6adf2f65d93d527c7 < a0856764dc1276ad2dc7891288c2e9246bf11a37 | a0856764dc1276ad2dc7891288c2e9246bf11a37 |
| linux | linux | >= a42afc5f56f319107e987aa6adf2f65d93d527c7 < 343117559ef41e992e326f7a92da1a8f254dfa8c | 343117559ef41e992e326f7a92da1a8f254dfa8c |
| linux | linux | >= a42afc5f56f319107e987aa6adf2f65d93d527c7 < 677c9d30e8487bee6c8e3b034070319d98f6e203 | 677c9d30e8487bee6c8e3b034070319d98f6e203 |
| linux | linux | >= a42afc5f56f319107e987aa6adf2f65d93d527c7 < cc5095747edfb054ca2068d01af20be3fcc3634f | cc5095747edfb054ca2068d01af20be3fcc3634f |
| linux | linux_kernel | < 4.9.311 | 4.9.311 |
| linux | linux_kernel | >= 0 < 5.10.113-1 | 5.10.113-1 |
| linux | linux_kernel | >= 0 < 5.17.3-1 | 5.17.3-1 |
| linux | linux_kernel | >= 0 < 5.17.3-1 | 5.17.3-1 |
| linux | linux_kernel | >= 0 < 5.17.3-1 | 5.17.3-1 |
| linux | linux_kernel | >= 4.10 < 4.14.276 | 4.14.276 |
| linux | linux_kernel | >= 4.15 < 4.19.238 | 4.19.238 |
| linux | linux_kernel | >= 4.20 < 5.4.189 | 5.4.189 |
| linux | linux_kernel | >= 5.11 < 5.15.33 | 5.15.33 |
| linux | linux_kernel | >= 5.16 < 5.16.19 | 5.16.19 |
| linux | linux_kernel | >= 5.17 < 5.17.2 | 5.17.2 |
| linux | linux_kernel | >= 5.5 < 5.10.110 | 5.10.110 |
CVSS provenance
nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_debian5.5MEDIUM
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Red Hat
kernel: ext4: don't BUG if someone dirty pages without asking ext4 first
vendor_redhat·2025-02-26·CVSS 5.5
CVE-2022-49171 [MEDIUM] CWE-99 kernel: ext4: don't BUG if someone dirty pages without asking ext4 first
kernel: ext4: don't BUG if someone dirty pages without asking ext4 first
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 cr
Debian
CVE-2022-49171: linux - In the Linux kernel, the following vulnerability has been resolved: ext4: don't...
vendor_debian·2022·CVSS 5.5
CVE-2022-49171 [MEDIUM] CVE-2022-49171: linux - In the Linux kernel, the following vulnerability has been resolved: ext4: don't...
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
GHSA
GHSA-qgfx-vv83-vj4g: 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_pa
ghsa_unreviewed·2025-09-23
CVE-2022-49171 [MEDIUM] CWE-617 GHSA-qgfx-vv83-vj4g: 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_pa
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
OSV
CVE-2022-49171: 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_page
osv·2025-02-26·CVSS 5.5
CVE-2022-49171 [MEDIUM] CVE-2022-49171: 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_page
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
No detection rules found.
No public exploits indexed.
https://git.kernel.org/stable/c/0d3a6926f7e8be3c897fa46216ce13b119a9f56ahttps://git.kernel.org/stable/c/330d0e44fc5a47c27df958ecdd4693a3cb1d8b81https://git.kernel.org/stable/c/343117559ef41e992e326f7a92da1a8f254dfa8chttps://git.kernel.org/stable/c/5a016c053f426a73752c3b41b60b497b58694d48https://git.kernel.org/stable/c/5db60e76edf5680ff1f3a7221036fc44b308f146https://git.kernel.org/stable/c/677c9d30e8487bee6c8e3b034070319d98f6e203https://git.kernel.org/stable/c/a0856764dc1276ad2dc7891288c2e9246bf11a37https://git.kernel.org/stable/c/cc5095747edfb054ca2068d01af20be3fcc3634fhttps://git.kernel.org/stable/c/d666dfaa571465a19f014534a214c255ea33f301
2025-02-26
Published