Answer in brief
CVE-2022-50273 records a Unknown severity vulnerability in f2fs: fix to do sanity check on destination blkaddr during recovery. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=d624c96fb3249e5d3dcf4e60a805e5e6b0dd7d91 <68b1e607559d3dc85f94b0d738d7c4e8029b0cfa || >=d624c96fb3249e5d3dcf4e60a805e5e6b0dd7d91 <73fb4bd2c055a393816f078f158cdd3025006f1d || >=d624c96fb3249e5d3dcf4e60a805e5e6b0dd7d91 <ed854f10e6afd5cbd5c3274d4c4df4bfe0ab4362 || >=d624c96fb3249e5d3dcf4e60a805e5e6b0dd7d91 <8f0a47def4722c5fd8d6b9268b5ffed8a249e2db || >=d624c96fb3249e5d3dcf4e60a805e5e6b0dd7d91 <3a4d24d746866dd45d970bd565ff3886e839366a || >=d624c96fb3249e5d3dcf4e60a805e5e6b0dd7d91 <0ef4ca04a3f9223ff8bc440041c524b2123e09a3 | 68b1e607559d3dc85f94b0d738d7c4e8029b0cfa, 73fb4bd2c055a393816f078f158cdd3025006f1d, ed854f10e6afd5cbd5c3274d4c4df4bfe0ab4362, 8f0a47def4722c5fd8d6b9268b5ffed8a249e2db, 3a4d24d746866dd45d970bd565ff3886e839366a, 0ef4ca04a3f9223ff8bc440041c524b2123e09a3 |
| Linux/Linuxgeneric | 3.8 | Not reported |
Published upstream
Sep 15, 2025
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 15, 2026
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.
Quoted source text, attributed separately from HOL analysis.
Answer in brief
CVE-2022-50273 records a Unknown severity vulnerability in f2fs: fix to do sanity check on destination blkaddr during recovery. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=d624c96fb3249e5d3dcf4e60a805e5e6b0dd7d91 <68b1e607559d3dc85f94b0d738d7c4e8029b0cfa || >=d624c96fb3249e5d3dcf4e60a805e5e6b0dd7d91 <73fb4bd2c055a393816f078f158cdd3025006f1d || >=d624c96fb3249e5d3dcf4e60a805e5e6b0dd7d91 <ed854f10e6afd5cbd5c3274d4c4df4bfe0ab4362 || >=d624c96fb3249e5d3dcf4e60a805e5e6b0dd7d91 <8f0a47def4722c5fd8d6b9268b5ffed8a249e2db || >=d624c96fb3249e5d3dcf4e60a805e5e6b0dd7d91 <3a4d24d746866dd45d970bd565ff3886e839366a || >=d624c96fb3249e5d3dcf4e60a805e5e6b0dd7d91 <0ef4ca04a3f9223ff8bc440041c524b2123e09a3 | 68b1e607559d3dc85f94b0d738d7c4e8029b0cfa, 73fb4bd2c055a393816f078f158cdd3025006f1d, ed854f10e6afd5cbd5c3274d4c4df4bfe0ab4362, 8f0a47def4722c5fd8d6b9268b5ffed8a249e2db, 3a4d24d746866dd45d970bd565ff3886e839366a, 0ef4ca04a3f9223ff8bc440041c524b2123e09a3 |
| Linux/Linuxgeneric | 3.8 | Not reported |
Published upstream
Sep 15, 2025
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 15, 2026
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.
Quoted source text, attributed separately from HOL analysis.