Answer in brief
CVE-2026-43288 records a Medium severity (CVSS 5.5) vulnerability in ext4: move ext4_percpu_param_init() before ext4_mb_init(). 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 5.5. 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 |
| cpe:2.3:o:linux:linux_kernel:7.0:rc1:*:*:*:*:*:* | Not reported | Not reported |
| cpe:2.3:o:linux:linux_kernel:7.0:rc2:*:*:*:*:*:* | Not reported | Not reported |
| cpe:2.3:o:linux:linux_kernel:7.0:rc3:*:*:*:*:*:* | Not reported | Not reported |
| cpe:2.3:o:linux:linux_kernel:7.0:rc4:*:*:*:*:*:* | Not reported | Not reported |
| cpe:2.3:o:linux:linux_kernel:7.0:rc5:*:*:*:*:*:* | Not reported | Not reported |
| cpe:2.3:o:linux:linux_kernel:7.0:rc6:*:*:*:*:*:* | Not reported | Not reported |
| cpe:2.3:o:linux:linux_kernel:7.0:rc7:*:*:*:*:*:* | Not reported | Not reported |
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | 3.17 | Not reported |
| Linux/Linuxgeneric | >=d5e03cbb0c88cd1be39f2adc37d602230045964b <0b3d80c56957862ba477ca0ce30c12cad9179c2b || >=d5e03cbb0c88cd1be39f2adc37d602230045964b <0d5fcb063cdabb9aeaa8554b7fedad2092c4150e || >=d5e03cbb0c88cd1be39f2adc37d602230045964b <9e9fb259bcddf459a0168f4a964e979e500a68a5 || >=d5e03cbb0c88cd1be39f2adc37d602230045964b <bf5b609524497c195f801cd5707252384aed8149 || >=d5e03cbb0c88cd1be39f2adc37d602230045964b <aec095f3cc6cf209effd93278ce35be27db81d73 || >=d5e03cbb0c88cd1be39f2adc37d602230045964b <270564513489d98b721a1e4a10017978d5213bff | 0b3d80c56957862ba477ca0ce30c12cad9179c2b, 0d5fcb063cdabb9aeaa8554b7fedad2092c4150e, 9e9fb259bcddf459a0168f4a964e979e500a68a5, bf5b609524497c195f801cd5707252384aed8149, aec095f3cc6cf209effd93278ce35be27db81d73, 270564513489d98b721a1e4a10017978d5213bff |
Published upstream
May 8, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Sep 14, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Sep 14, 2026
In the Linux kernel, the following vulnerability has been resolved: ext4: move ext4_percpu_param_init() before ext4_mb_init() When running `kvm-xfstests -c ext4/1k -C 1 generic/383` with the `DOUBLE_CHECK` macro defined, the following panic is triggered: ================================================================== EXT4-fs error (device vdc): ext4_validate_block_bitmap:423: comm mount: bg 0: bad block bitmap checksum BUG: unable to handle page fault for address: ff110000fa2cc000 PGD 3e01067 P4D 3e02067 PUD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 2386 Comm: mount Tainted: G W 6.18.0-gba65a4e7120a-dirty #1152 PREEMPT(none) RIP: 0010:percpu_counter_add_batch+0x13/0xa0 Call Trace: <TASK> ext4_mark_group_bitmap_corrupted+0xcb/0xe0 ext4_validate_block_bitmap+0x2a1/0x2f0 ext4_read_block_bitmap+0x33/0x50 mb_group_bb_bitmap_alloc+0x33/0x80 ext4_mb_add_groupinfo+0x190/0x250 ext4_mb_init_backend+0x87/0x290 ext4_mb_init+0x456/0x640 __ext4_fill_super+0x1072/0x1680 ext4_fill_super+0xd3/0x280 get_tree_bdev_flags+0x132/0x1d0 vfs_get_tree+0x29/0xd0 vfs_cmd_create+0x59/0xe0 __do_sys_fsconfig+0x4f6/0x6b0 do_syscall_64+0x50/0x1f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e ================================================================== This issue can be reproduced using the following commands: mkfs.ext4 -F -q -b 1024 /dev/sda 5G tune2fs -O quota,project /dev/sda mount /dev/sda /tmp/test With DOUBLE_CHECK defined, mb_group_bb_bitmap_alloc() reads and validates the block bitmap. When the validation fails, ext4_mark_group_bitmap_corrupted() attempts to update sbi->s_freeclusters_counter. However, this percpu_counter has not been initialized yet at this point, which leads to the panic described above. Fix this by moving the execution of ext4_percpu_param_init() to occur before ext4_mb_init(), ensuring the per-CPU counters are initialized before they are used.
Quoted source text, attributed separately from HOL analysis.