Answer in brief
CVE-2024-56677 records a High severity (CVSS 7.8) vulnerability in powerpc/fadump: Move fadump_cma_init to setup_arch() after initmem_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 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.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=11ac3e87ce09c27f4587a8c4fe0829d814021a82 <aabef6301dcf410dfd2b8759cd413b2a003c7e3f || >=11ac3e87ce09c27f4587a8c4fe0829d814021a82 <c5c1d1ef70834013fc3bd12b6a0f4664c6d75a74 || >=11ac3e87ce09c27f4587a8c4fe0829d814021a82 <f551637fe9bf863386309e03f9d148d97f535ad1 || >=11ac3e87ce09c27f4587a8c4fe0829d814021a82 <7351c5a6507b4401aeecadb5959131410a339520 || >=11ac3e87ce09c27f4587a8c4fe0829d814021a82 <05b94cae1c47f94588c3e7096963c1007c4d9c1d | aabef6301dcf410dfd2b8759cd413b2a003c7e3f, c5c1d1ef70834013fc3bd12b6a0f4664c6d75a74, f551637fe9bf863386309e03f9d148d97f535ad1, 7351c5a6507b4401aeecadb5959131410a339520, 05b94cae1c47f94588c3e7096963c1007c4d9c1d |
| Linux/Linuxgeneric | 5.19 | Not reported |
Published upstream
Dec 28, 2024
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
In the Linux kernel, the following vulnerability has been resolved: powerpc/fadump: Move fadump_cma_init to setup_arch() after initmem_init() During early init CMA_MIN_ALIGNMENT_BYTES can be PAGE_SIZE, since pageblock_order is still zero and it gets initialized later during initmem_init() e.g. setup_arch() -> initmem_init() -> sparse_init() -> set_pageblock_order() One such use case where this causes issue is - early_setup() -> early_init_devtree() -> fadump_reserve_mem() -> fadump_cma_init() This causes CMA memory alignment check to be bypassed in cma_init_reserved_mem(). Then later cma_activate_area() can hit a VM_BUG_ON_PAGE(pfn & ((1 << order) - 1)) if the reserved memory area was not pageblock_order aligned. Fix it by moving the fadump_cma_init() after initmem_init(), where other such cma reservations also gets called. <stack trace> ============== page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x10010 flags: 0x13ffff800000000(node=1|zone=0|lastcpupid=0x7ffff) CMA raw: 013ffff800000000 5deadbeef0000100 5deadbeef0000122 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: VM_BUG_ON_PAGE(pfn & ((1 << order) - 1)) ------------[ cut here ]------------ kernel BUG at mm/page_alloc.c:778! Call Trace: __free_one_page+0x57c/0x7b0 (unreliable) free_pcppages_bulk+0x1a8/0x2c8 free_unref_page_commit+0x3d4/0x4e4 free_unref_page+0x458/0x6d0 init_cma_reserved_pageblock+0x114/0x198 cma_init_reserved_areas+0x270/0x3e0 do_one_initcall+0x80/0x2f8 kernel_init_freeable+0x33c/0x530 kernel_init+0x34/0x26c ret_from_kernel_user_thread+0x14/0x1c
Quoted source text, attributed separately from HOL analysis.