CVE-2022-50673: ext4: fix use-after-free in ext4_orphan_cleanup
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix use-after-free in ext4_orphan_cleanup
I caught a issue as follows:
==================================================================
BUG: KASAN: use-after-free in __list_add_valid+0x28/0x1a0
Read of size 8 at addr ffff88814b13f378 by task mount/710
CPU: 1 PID: 710 Comm: mount Not tainted 6.1.0-rc3-next #370
Call Trace:
<TASK>
dump_stack_lvl+0x73/0x9f
print_report+0x25d/0x759
kasan_report+0xc0/0x120
__asan_load8+0x99/0x140
__list_add_valid+0x28/0x1a0
ext4_orphan_cleanup+0x564/0x9d0 [ext4]
__ext4_fill_super+0x48e2/0x5300 [ext4]
ext4_fill_super+0x19f/0x3a0 [ext4]
get_tree_bdev+0x27b/0x450
ext4_get_tree+0x19/0x30 [ext4]
vfs_get_tree+0x49/0x150
path_mount+0xaae/0x1350
do_mount+0xe2/0x110
__x64_sys_mount+0xf0/0x190
do_syscall_64+0x35/0x80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
</TASK>
[...]
==================================================================
Above issue may happen as follows:
-------------------------------------
ext4_fill_super
ext4_orphan_cleanup
--- loop1: assume last_orphan is 12 ---
list_add(&EXT4_I(inode)->i_orphan, &EXT4_SB(sb)->s_orphan)
ext4_truncate --> return 0
ext4_inode_attach_jinode --> return -ENOMEM
iput(inode) --> free inode<12>
--- loop2: last_orphan is still 12 ---
list_add(&EXT4_I(inode)->i_orphan, &EXT4_SB(sb)->s_orphan);
// use inode<12> and trigger UAF
To solve this issue, we need to propagate the return value of
ext4_inode_attach_jinode() appropriately.
Security readout for executives and security teams
Plain-English summary
This is a Linux kernel ext4 filesystem bug where cleanup during mount can reuse an inode after it has been freed. The public record does not provide CVSS, impact scoring, or confirmed attacker behavior. Treat it as a kernel stability and possible memory-safety exposure for systems running affected Linux versions with ext4.
Executive priority
Handle through normal kernel patch management unless your environment mounts untrusted ext4 media or images. Lack of CVSS and exploitation evidence prevents a stronger emergency rating, but kernel memory-safety bugs still merit timely remediation.
Technical view
The flaw is a use-after-free in ext4_orphan_cleanup during ext4 mount handling. If ext4_inode_attach_jinode() fails, its return value was not propagated correctly, allowing orphan cleanup to revisit a freed inode. Kernel stable commits are listed as fixes across multiple branches.
Likely exposure
Likely limited to Linux systems using affected kernel versions and ext4. Exposure depends on whether the system can enter ext4 orphan cleanup during mount. The source bundle does not identify specific distributions, appliances, cloud images, or userland packages.
Exploitation context
The bundle shows a KASAN-detected use-after-free during mount and says KEV is false. It does not cite active exploitation, public exploit code, exploit prerequisites, or attacker-controlled inputs. Do not assume exploitation in the wild from the provided evidence.
Researcher notes
Focus review on ext4 orphan cleanup during mount and error propagation from ext4_inode_attach_jinode(). The provided trace shows reuse of inode 12 after iput frees it. Impact beyond memory corruption is not established in the bundle.
Mitigation direction
Update to a kernel package containing the listed upstream stable fixes.
Check your Linux distribution advisory for the exact fixed package version.
Avoid unnecessary mounting of untrusted ext4 filesystems until patched.
Prioritize systems where users or services can trigger filesystem mounts.
Validation and detection
Inventory Linux kernel versions across ext4-using systems.
Map deployed kernels to vendor advisories or the listed stable commits.
Confirm patched hosts no longer run affected kernel builds.
Review logs for ext4 mount failures or kernel memory-safety warnings.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2022-50673 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.