CVE-2022-50273: f2fs: fix to do sanity check on destination blkaddr during recovery
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to do sanity check on destination blkaddr during recovery
As Wenqing Liu reported in bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=216456
loop5: detected capacity change from 0 to 131072
F2FS-fs (loop5): recover_inode: ino = 6, name = hln, inline = 1
F2FS-fs (loop5): recover_data: ino = 6 (i_size: recover) err = 0
F2FS-fs (loop5): recover_inode: ino = 6, name = hln, inline = 1
F2FS-fs (loop5): recover_data: ino = 6 (i_size: recover) err = 0
F2FS-fs (loop5): recover_inode: ino = 6, name = hln, inline = 1
F2FS-fs (loop5): recover_data: ino = 6 (i_size: recover) err = 0
F2FS-fs (loop5): Bitmap was wrongly set, blk:5634
------------[ cut here ]------------
WARNING: CPU: 3 PID: 1013 at fs/f2fs/segment.c:2198
RIP: 0010:update_sit_entry+0xa55/0x10b0 [f2fs]
Call Trace:
<TASK>
f2fs_do_replace_block+0xa98/0x1890 [f2fs]
f2fs_replace_block+0xeb/0x180 [f2fs]
recover_data+0x1a69/0x6ae0 [f2fs]
f2fs_recover_fsync_data+0x120d/0x1fc0 [f2fs]
f2fs_fill_super+0x4665/0x61e0 [f2fs]
mount_bdev+0x2cf/0x3b0
legacy_get_tree+0xed/0x1d0
vfs_get_tree+0x81/0x2b0
path_mount+0x47e/0x19d0
do_mount+0xce/0xf0
__x64_sys_mount+0x12c/0x1a0
do_syscall_64+0x38/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd
If we enable CONFIG_F2FS_CHECK_FS config, it will trigger a kernel panic
instead of warning.
The root cause is: in fuzzed image, SIT table is inconsistent with inode
mapping table, result in triggering such warning during SIT table update.
This patch introduces a new flag DATA_GENERIC_ENHANCE_UPDATE, w/ this
flag, data block recovery flow can check destination blkaddr's validation
in SIT table, and skip f2fs_replace_block() to avoid inconsistent status.
Security readout for executives and security teams
Plain-English summary
CVE-2022-50273 is a Linux kernel F2FS recovery flaw. A malformed F2FS image can leave filesystem metadata inconsistent, causing a kernel warning or panic when recovery updates block state. The main business risk is availability on systems that mount untrusted or corrupted F2FS filesystems.
Executive priority
Treat this as a targeted availability risk, not a broadly proven internet-facing emergency. Prioritize patching where F2FS is used with removable, user-supplied, or automated image mounting workflows.
Technical view
During F2FS fsync data recovery, the kernel could call f2fs_replace_block() with a destination block address whose SIT state did not match inode mapping metadata. The fix adds DATA_GENERIC_ENHANCE_UPDATE validation so recovery checks the destination block in the SIT table and skips replacement when inconsistent.
Likely exposure
Exposure is most plausible where Linux systems mount F2FS media, disk images, mobile/embedded storage, or test artifacts from untrusted sources. Systems not using F2FS, or not mounting attacker-controlled F2FS filesystems, have much lower practical exposure.
Exploitation context
The source describes a fuzzed image triggering warnings and, with CONFIG_F2FS_CHECK_FS, a kernel panic. It does not cite active exploitation, public weaponization, privilege escalation, or remote reachability. KEV status is false in the provided bundle.
Researcher notes
The evidence points to malformed filesystem recovery handling, not a network attack path. The bundle lacks CVSS, CWE, exploit status, and detailed affected range semantics beyond Linux kernel version markers and stable commit references.
Mitigation direction
Inventory Linux systems that enable or mount F2FS filesystems.
Apply the relevant Linux stable kernel update containing the referenced fixes.
Restrict mounting of untrusted F2FS media or disk images.
Check vendor or distribution advisories for packaged kernel availability.
Prioritize systems where kernel panics affect production availability.
Validation and detection
Confirm whether F2FS is enabled and used on affected Linux hosts.
Compare running kernel versions against vendor fixed kernel packages.
Review kernel logs for F2FS recovery warnings or panic reports.
Check whether CONFIG_F2FS_CHECK_FS is enabled in deployed kernels.
Verify update status using distribution-supported kernel metadata.
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-50273 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.
0CVSS vectors
3Timeline events
0ADP providers
7Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Sep 15, 2025, 14:21 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.