Answer in brief
CVE-2024-56677 records a Unknown severity 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.
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 | >=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.
Answer in brief
CVE-2024-56677 records a Unknown severity 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.
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 | >=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.