Answer in brief
CVE-2022-49174 records a High severity (CVSS 7.8) vulnerability in ext4: fix ext4_mb_mark_bb() with flex_bg with fast_commit. 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.
CVSS is 7.8. 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.
| Product | Affected versions | Fixed versions |
|---|---|---|
| cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | Not reported | Not reported |
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | 5.10 | Not reported |
| Linux/Linuxgeneric | >=8016e29f4362e285f0f7e38fadc61a5b7bdfdfa2 <cd6d719534af993210306f8a13f9cb3e615f7c8d || >=8016e29f4362e285f0f7e38fadc61a5b7bdfdfa2 <6a6beb074186a0452368a023a261c7d0eaebe838 || >=8016e29f4362e285f0f7e38fadc61a5b7bdfdfa2 <b07eedd0222e9548ffc568ec429bb1f61d21a39c || >=8016e29f4362e285f0f7e38fadc61a5b7bdfdfa2 <803fb0e8240cc16585a5c9df76add1dfaa781773 || >=8016e29f4362e285f0f7e38fadc61a5b7bdfdfa2 <bfdc502a4a4c058bf4cbb1df0c297761d528f54d | cd6d719534af993210306f8a13f9cb3e615f7c8d, 6a6beb074186a0452368a023a261c7d0eaebe838, b07eedd0222e9548ffc568ec429bb1f61d21a39c, 803fb0e8240cc16585a5c9df76add1dfaa781773, bfdc502a4a4c058bf4cbb1df0c297761d528f54d |
Published upstream
Feb 26, 2025
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 4, 2026
In the Linux kernel, the following vulnerability has been resolved: ext4: fix ext4_mb_mark_bb() with flex_bg with fast_commit In case of flex_bg feature (which is by default enabled), extents for any given inode might span across blocks from two different block group. ext4_mb_mark_bb() only reads the buffer_head of block bitmap once for the starting block group, but it fails to read it again when the extent length boundary overflows to another block group. Then in this below loop it accesses memory beyond the block group bitmap buffer_head and results into a data abort. for (i = 0; i < clen; i++) if (!mb_test_bit(blkoff + i, bitmap_bh->b_data) == !state) already++; This patch adds this functionality for checking block group boundary in ext4_mb_mark_bb() and update the buffer_head(bitmap_bh) for every different block group. w/o this patch, I was easily able to hit a data access abort using Power platform. <...> [ 74.327662] EXT4-fs error (device loop3): ext4_mb_generate_buddy:1141: group 11, block bitmap and bg descriptor inconsistent: 21248 vs 23294 free clusters [ 74.533214] EXT4-fs (loop3): shut down requested (2) [ 74.536705] Aborting journal on device loop3-8. [ 74.702705] BUG: Unable to handle kernel data access on read at 0xc00000005e980000 [ 74.703727] Faulting instruction address: 0xc0000000007bffb8 cpu 0xd: Vector: 300 (Data Access) at [c000000015db7060] pc: c0000000007bffb8: ext4_mb_mark_bb+0x198/0x5a0 lr: c0000000007bfeec: ext4_mb_mark_bb+0xcc/0x5a0 sp: c000000015db7300 msr: 800000000280b033 dar: c00000005e980000 dsisr: 40000000 current = 0xc000000027af6880 paca = 0xc00000003ffd5200 irqmask: 0x03 irq_happened: 0x01 pid = 5167, comm = mount <...> enter ? for help [c000000015db7380] c000000000782708 ext4_ext_clear_bb+0x378/0x410 [c000000015db7400] c000000000813f14 ext4_fc_replay+0x1794/0x2000 [c000000015db7580] c000000000833f7c do_one_pass+0xe9c/0x12a0 [c000000015db7710] c000000000834504 jbd2_journal_recover+0x184/0x2d0 [c000000015db77c0] c000000000841398 jbd2_journal_load+0x188/0x4a0 [c000000015db7880] c000000000804de8 ext4_fill_super+0x2638/0x3e10 [c000000015db7a40] c0000000005f8404 get_tree_bdev+0x2b4/0x350 [c000000015db7ae0] c0000000007ef058 ext4_get_tree+0x28/0x40 [c000000015db7b00] c0000000005f6344 vfs_get_tree+0x44/0x100 [c000000015db7b70] c00000000063c408 path_mount+0xdd8/0xe70 [c000000015db7c40] c00000000063c8f0 sys_mount+0x450/0x550 [c000000015db7d50] c000000000035770 system_call_exception+0x4a0/0x4e0 [c000000015db7e10] c00000000000c74c system_call_common+0xec/0x250
Quoted source text, attributed separately from HOL analysis.
Answer in brief
CVE-2022-49174 records a High severity (CVSS 7.8) vulnerability in ext4: fix ext4_mb_mark_bb() with flex_bg with fast_commit. 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.
CVSS is 7.8. 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.
| Product | Affected versions | Fixed versions |
|---|---|---|
| cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | Not reported | Not reported |
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | 5.10 | Not reported |
| Linux/Linuxgeneric | >=8016e29f4362e285f0f7e38fadc61a5b7bdfdfa2 <cd6d719534af993210306f8a13f9cb3e615f7c8d || >=8016e29f4362e285f0f7e38fadc61a5b7bdfdfa2 <6a6beb074186a0452368a023a261c7d0eaebe838 || >=8016e29f4362e285f0f7e38fadc61a5b7bdfdfa2 <b07eedd0222e9548ffc568ec429bb1f61d21a39c || >=8016e29f4362e285f0f7e38fadc61a5b7bdfdfa2 <803fb0e8240cc16585a5c9df76add1dfaa781773 || >=8016e29f4362e285f0f7e38fadc61a5b7bdfdfa2 <bfdc502a4a4c058bf4cbb1df0c297761d528f54d | cd6d719534af993210306f8a13f9cb3e615f7c8d, 6a6beb074186a0452368a023a261c7d0eaebe838, b07eedd0222e9548ffc568ec429bb1f61d21a39c, 803fb0e8240cc16585a5c9df76add1dfaa781773, bfdc502a4a4c058bf4cbb1df0c297761d528f54d |
Published upstream
Feb 26, 2025
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 4, 2026
In the Linux kernel, the following vulnerability has been resolved: ext4: fix ext4_mb_mark_bb() with flex_bg with fast_commit In case of flex_bg feature (which is by default enabled), extents for any given inode might span across blocks from two different block group. ext4_mb_mark_bb() only reads the buffer_head of block bitmap once for the starting block group, but it fails to read it again when the extent length boundary overflows to another block group. Then in this below loop it accesses memory beyond the block group bitmap buffer_head and results into a data abort. for (i = 0; i < clen; i++) if (!mb_test_bit(blkoff + i, bitmap_bh->b_data) == !state) already++; This patch adds this functionality for checking block group boundary in ext4_mb_mark_bb() and update the buffer_head(bitmap_bh) for every different block group. w/o this patch, I was easily able to hit a data access abort using Power platform. <...> [ 74.327662] EXT4-fs error (device loop3): ext4_mb_generate_buddy:1141: group 11, block bitmap and bg descriptor inconsistent: 21248 vs 23294 free clusters [ 74.533214] EXT4-fs (loop3): shut down requested (2) [ 74.536705] Aborting journal on device loop3-8. [ 74.702705] BUG: Unable to handle kernel data access on read at 0xc00000005e980000 [ 74.703727] Faulting instruction address: 0xc0000000007bffb8 cpu 0xd: Vector: 300 (Data Access) at [c000000015db7060] pc: c0000000007bffb8: ext4_mb_mark_bb+0x198/0x5a0 lr: c0000000007bfeec: ext4_mb_mark_bb+0xcc/0x5a0 sp: c000000015db7300 msr: 800000000280b033 dar: c00000005e980000 dsisr: 40000000 current = 0xc000000027af6880 paca = 0xc00000003ffd5200 irqmask: 0x03 irq_happened: 0x01 pid = 5167, comm = mount <...> enter ? for help [c000000015db7380] c000000000782708 ext4_ext_clear_bb+0x378/0x410 [c000000015db7400] c000000000813f14 ext4_fc_replay+0x1794/0x2000 [c000000015db7580] c000000000833f7c do_one_pass+0xe9c/0x12a0 [c000000015db7710] c000000000834504 jbd2_journal_recover+0x184/0x2d0 [c000000015db77c0] c000000000841398 jbd2_journal_load+0x188/0x4a0 [c000000015db7880] c000000000804de8 ext4_fill_super+0x2638/0x3e10 [c000000015db7a40] c0000000005f8404 get_tree_bdev+0x2b4/0x350 [c000000015db7ae0] c0000000007ef058 ext4_get_tree+0x28/0x40 [c000000015db7b00] c0000000005f6344 vfs_get_tree+0x44/0x100 [c000000015db7b70] c00000000063c408 path_mount+0xdd8/0xe70 [c000000015db7c40] c00000000063c8f0 sys_mount+0x450/0x550 [c000000015db7d50] c000000000035770 system_call_exception+0x4a0/0x4e0 [c000000015db7e10] c00000000000c74c system_call_common+0xec/0x250
Quoted source text, attributed separately from HOL analysis.