CVE-2022-50730
published 2025-12-24CVE-2022-50730: In the Linux kernel, the following vulnerability has been resolved: ext4: silence the warning when evicting inode with dioread_nolock When evicting an inode…
PriorityP423low3.3
EPSS
0.21%
11.8th percentile
In the Linux kernel, the following vulnerability has been resolved:
ext4: silence the warning when evicting inode with dioread_nolock
When evicting an inode with default dioread_nolock, it could be raced by
the unwritten extents converting kworker after writeback some new
allocated dirty blocks. It convert unwritten extents to written, the
extents could be merged to upper level and free extent blocks, so it
could mark the inode dirty again even this inode has been marked
I_FREEING. But the inode->i_io_list check and warning in
ext4_evict_inode() missing this corner case. Fortunately,
ext4_evict_inode() will wait all extents converting finished before this
check, so it will not lead to inode use-after-free problem, every thing
is OK besides this warning. The WARN_ON_ONCE was originally designed
for finding inode use-after-free issues in advance, but if we add
current dioread_nolock case in, it will become not quite useful, so fix
this warning by just remove this check.
WARNING: CPU: 7 PID: 1092 at fs/ext4/inode.c:227
ext4_evict_inode+0x875/0xc60
...
RIP: 0010:ext4_evict_inode+0x875/0xc60
...
Call Trace:
evict+0x11c/0x2b0
iput+0x236/0x3a0
do_unlinkat+0x1b4/0x490
__x64_sys_unlinkat+0x4c/0xb0
do_syscall_64+0x3b/0x90
entry_SYSCALL_64_after_hwframe+0x46/0xb0
RIP: 0033:0x7fa933c1115b
rm kworker
ext4_end_io_end()
vfs_unlink()
ext4_unlink()
ext4_convert_unwritten_io_end_vec()
ext4_convert_unwritten_extents()
ext4_map_blocks()
ext4_ext_map_blocks()
ext4_ext_try_to_merge_up()
__mark_inode_dirty()
check !I_FREEING
locked_inode_to_wb_and_lock_list()
iput()
iput_final()
evict()
ext4_evict_inode()
truncate_inode_pages_final() //wait release io_end
inode_io_list_move_locked()
ext4_release_io_end()
trigger WARN_ON_ONCE()
Affected
15 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.1.4-1 (bookworm) | linux 6.1.4-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= ceff86fddae8748fe00d4f2d249cb02cae62ad84 < bdc698ce91f232fd5eb11d2373e9f82f687314b8 | bdc698ce91f232fd5eb11d2373e9f82f687314b8 |
| linux | linux | >= ceff86fddae8748fe00d4f2d249cb02cae62ad84 < 0d041b7251c13679a0f6c7926751ce1d8a7237c1 | 0d041b7251c13679a0f6c7926751ce1d8a7237c1 |
| linux | linux | >= ceff86fddae8748fe00d4f2d249cb02cae62ad84 < 3b893cc9a8d8b4e486a6639f5e107b56b7197d2e | 3b893cc9a8d8b4e486a6639f5e107b56b7197d2e |
| linux | linux | >= ceff86fddae8748fe00d4f2d249cb02cae62ad84 < b085fb43feede48ebf80ab7e2dd150c8d9902932 | b085fb43feede48ebf80ab7e2dd150c8d9902932 |
| linux | linux | >= ceff86fddae8748fe00d4f2d249cb02cae62ad84 < bc12ac98ea2e1b70adc6478c8b473a0003b659d3 | bc12ac98ea2e1b70adc6478c8b473a0003b659d3 |
| linux | linux_kernel | >= 0 < 5.10.178-1 | 5.10.178-1 |
| linux | linux_kernel | >= 0 < 6.1.4-1 | 6.1.4-1 |
| linux | linux_kernel | >= 0 < 6.1.4-1 | 6.1.4-1 |
| linux | linux_kernel | >= 0 < 6.1.4-1 | 6.1.4-1 |
| linux | linux_kernel | >= 5.11.0 < 5.15.87 | 5.15.87 |
| linux | linux_kernel | >= 5.16.0 < 6.0.18 | 6.0.18 |
| linux | linux_kernel | >= 5.8.0 < 5.10.163 | 5.10.163 |
| linux | linux_kernel | >= 6.1.0 < 6.1.4 | 6.1.4 |
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.
VulDB
Linux Kernel up to 5.10.162/5.15.86/6.0.17/6.1.3 ext4 fs/ext4/inode.c ext4_evict_inode use after free (Nessus ID 279929 / WID-SEC-2025-2929)
vuldb·2026-04-21
CVE-2022-50730 [CRITICAL] Linux Kernel up to 5.10.162/5.15.86/6.0.17/6.1.3 ext4 fs/ext4/inode.c ext4_evict_inode use after free (Nessus ID 279929 / WID-SEC-2025-2929)
A vulnerability labeled as critical has been found in Linux Kernel up to 5.10.162/5.15.86/6.0.17/6.1.3. This impacts the function ext4_evict_inode of the file fs/ext4/inode.c of the component ext4. Executing a manipulation can lead to use after free.
The identification of this vulnerability is CVE-2022-50730. The attack needs to be done within the local network. There is no exploit available.
The affected component should be upgraded.
OSV
CVE-2022-50730: In the Linux kernel, the following vulnerability has been resolved: ext4: silence the warning when evicting inode with dioread_nolock When evicting an
osv·2025-12-24
CVE-2022-50730 CVE-2022-50730: In the Linux kernel, the following vulnerability has been resolved: ext4: silence the warning when evicting inode with dioread_nolock When evicting an
In the Linux kernel, the following vulnerability has been resolved: ext4: silence the warning when evicting inode with dioread_nolock When evicting an inode with default dioread_nolock, it could be raced by the unwritten extents converting kworker after writeback some new allocated dirty blocks. It convert unwritten extents to written, the extents could be merged to upper level and free extent blocks, so it could mark the inode dirty again even this inode has been marked I_FREEING. But the inode->i_io_list check and warning in ext4_evict_inode() missing this corner case. Fortunately, ext4_evict_inode() will wait all extents converting finished before this check, so it will not lead to inode use-after-free problem, every thing is OK besides this warning. The WARN_ON_ONCE was originally desi
OSV
ext4: silence the warning when evicting inode with dioread_nolock
osv·2025-12-24
CVE-2022-50730 ext4: silence the warning when evicting inode with dioread_nolock
ext4: silence the warning when evicting inode with dioread_nolock
In the Linux kernel, the following vulnerability has been resolved:
ext4: silence the warning when evicting inode with dioread_nolock
When evicting an inode with default dioread_nolock, it could be raced by
the unwritten extents converting kworker after writeback some new
allocated dirty blocks. It convert unwritten extents to written, the
extents could be merged to upper level and free extent blocks, so it
could mark the inode dirty again even this inode has been marked
I_FREEING. But the inode->i_io_list check and warning in
ext4_evict_inode() missing this corner case. Fortunately,
ext4_evict_inode() will wait all extents converting finished before this
check, so it will not lead to inode use-after-free problem, every t
GHSA
GHSA-m98r-2fg7-rppv: In the Linux kernel, the following vulnerability has been resolved:
ext4: silence the warning when evicting inode with dioread_nolock
When evicting
ghsa_unreviewed·2025-12-24
CVE-2022-50730 GHSA-m98r-2fg7-rppv: In the Linux kernel, the following vulnerability has been resolved:
ext4: silence the warning when evicting inode with dioread_nolock
When evicting
In the Linux kernel, the following vulnerability has been resolved:
ext4: silence the warning when evicting inode with dioread_nolock
When evicting an inode with default dioread_nolock, it could be raced by
the unwritten extents converting kworker after writeback some new
allocated dirty blocks. It convert unwritten extents to written, the
extents could be merged to upper level and free extent blocks, so it
could mark the inode dirty again even this inode has been marked
I_FREEING. But the inode->i_io_list check and warning in
ext4_evict_inode() missing this corner case. Fortunately,
ext4_evict_inode() will wait all extents converting finished before this
check, so it will not lead to inode use-after-free problem, every thing
is OK besides this warning. The WARN_ON_ONCE was originally de
Red Hat
kernel: ext4: silence the warning when evicting inode with dioread_nolock
vendor_redhat·2025-12-24·CVSS 3.3
CVE-2022-50730 [LOW] CWE-367 kernel: ext4: silence the warning when evicting inode with dioread_nolock
kernel: ext4: silence the warning when evicting inode with dioread_nolock
In the Linux kernel, the following vulnerability has been resolved:
ext4: silence the warning when evicting inode with dioread_nolock
When evicting an inode with default dioread_nolock, it could be raced by
the unwritten extents converting kworker after writeback some new
allocated dirty blocks. It convert unwritten extents to written, the
extents could be merged to upper level and free extent blocks, so it
could mark the inode dirty again even this inode has been marked
I_FREEING. But the inode->i_io_list check and warning in
ext4_evict_inode() missing this corner case. Fortunately,
ext4_evict_inode() will wait all extents converting finished before this
check, so it will not lead to inode use-after-free problem, e
Debian
CVE-2022-50730: linux - In the Linux kernel, the following vulnerability has been resolved: ext4: silen...
vendor_debian·2022
CVE-2022-50730 CVE-2022-50730: linux - In the Linux kernel, the following vulnerability has been resolved: ext4: silen...
In the Linux kernel, the following vulnerability has been resolved: ext4: silence the warning when evicting inode with dioread_nolock When evicting an inode with default dioread_nolock, it could be raced by the unwritten extents converting kworker after writeback some new allocated dirty blocks. It convert unwritten extents to written, the extents could be merged to upper level and free extent blocks, so it could mark the inode dirty again even this inode has been marked I_FREEING. But the inode->i_io_list check and warning in ext4_evict_inode() missing this corner case. Fortunately, ext4_evict_inode() will wait all extents converting finished before this check, so it will not lead to inode use-after-free problem, every thing is OK besides this warning. The WARN_ON_ONCE was originally desi
No detection rules found.
No public exploits indexed.
Bugzilla
CVE-2022-50730 kernel: ext4: silence the warning when evicting inode with dioread_nolock
bugzilla·2025-12-24
CVE-2022-50730 [LOW] CVE-2022-50730 kernel: ext4: silence the warning when evicting inode with dioread_nolock
CVE-2022-50730 kernel: ext4: silence the warning when evicting inode with dioread_nolock
In the Linux kernel, the following vulnerability has been resolved:
ext4: silence the warning when evicting inode with dioread_nolock
When evicting an inode with default dioread_nolock, it could be raced by
the unwritten extents converting kworker after writeback some new
allocated dirty blocks. It convert unwritten extents to written, the
extents could be merged to upper level and free extent blocks, so it
could mark the inode dirty again even this inode has been marked
I_FREEING. But the inode->i_io_list check and warning in
ext4_evict_inode() missing this corner case. Fortunately,
ext4_evict_inode() will wait all extents converting finished before this
check, so it will not lead to inode use-afte
Wiz
CVE-2022-50730 Impact, Exploitability, and Mitigation Steps | Wiz
blogs_wiz
CVE-2022-50730 CVE-2022-50730 Impact, Exploitability, and Mitigation Steps | Wiz
## CVE-2022-50730 :
Linux Kernel vulnerability analysis and mitigation
In the Linux kernel, the following vulnerability has been resolved:
ext4: silence the warning when evicting inode with dioread_nolock
When evicting an inode with default dioread_nolock, it could be raced by
the unwritten extents converting kworker after writeback some new
allocated dirty blocks. It convert unwritten extents to written, the
extents could be merged to upper level and free extent blocks, so it
could mark the inode dirty again even this inode has been marked
I_FREEING. But the inode->i_io_list check and warning in
ext4_evict_inode() missing this corner case. Fortunately,
ext4_evict_inode() will wait all extents converting finished before this
check, so it will not lead to inode use-after-free problem, e
https://git.kernel.org/stable/c/0d041b7251c13679a0f6c7926751ce1d8a7237c1https://git.kernel.org/stable/c/3b893cc9a8d8b4e486a6639f5e107b56b7197d2ehttps://git.kernel.org/stable/c/b085fb43feede48ebf80ab7e2dd150c8d9902932https://git.kernel.org/stable/c/bc12ac98ea2e1b70adc6478c8b473a0003b659d3https://git.kernel.org/stable/c/bdc698ce91f232fd5eb11d2373e9f82f687314b8
2025-12-24
Published