CVE-2022-50273
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-09-15

Last updated on: 2025-12-03

Assigner: kernel.org

Description
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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-09-15
Last Modified
2025-12-03
Generated
2026-05-07
AI Q&A
2025-09-15
EPSS Evaluated
2026-05-05
NVD
CVE-2022-50273
Affected Vendors & Products
Showing 5 associated CPEs
Vendor Product Version / Range
linux linux_kernel From 3.8 (inc) to 5.4.220 (exc)
linux linux_kernel From 5.5 (inc) to 5.10.150 (exc)
linux linux_kernel From 5.11 (inc) to 5.15.75 (exc)
linux linux_kernel From 5.16 (inc) to 5.19.17 (exc)
linux linux_kernel From 6.0 (inc) to 6.0.3 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-NVD-CWE-noinfo
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability is in the Linux kernel's F2FS filesystem. It involves an inconsistency between the SIT (Segment Information Table) and the inode mapping table during recovery, which can cause warnings or kernel panic if CONFIG_F2FS_CHECK_FS is enabled. The issue arises because the destination block address (blkaddr) is not properly sanity-checked during recovery, leading to potential inconsistent filesystem states. The patch fixes this by adding a flag that enables validation of the destination block address to avoid replacing blocks incorrectly.


How can this vulnerability impact me? :

This vulnerability can cause the Linux kernel to issue warnings or even panic (crash) during filesystem recovery on F2FS filesystems. This can lead to system instability or downtime, especially if the filesystem is mounted with the CONFIG_F2FS_CHECK_FS option enabled. It may also result in inconsistent filesystem states, potentially causing data corruption or loss.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by monitoring kernel logs for specific warnings related to the f2fs filesystem, such as messages indicating inconsistent SIT table updates or warnings like 'Bitmap was wrongly set, blk:xxxx' and call traces involving f2fs functions (e.g., update_sit_entry, f2fs_replace_block). Enabling CONFIG_F2FS_CHECK_FS in the kernel configuration can cause a kernel panic on detection, which is a strong indicator. Commands to check kernel logs include: 'dmesg | grep f2fs' or 'journalctl -k | grep f2fs'.


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation involves applying the patch that introduces the DATA_GENERIC_ENHANCE_UPDATE flag, which adds validation checks on destination block addresses during data block recovery to avoid inconsistent states. Additionally, enabling CONFIG_F2FS_CHECK_FS can help detect the issue early by triggering a kernel panic instead of a warning. Updating the Linux kernel to a version that includes this fix is the recommended step.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart