fkie_cve-2024-56677
Vulnerability from fkie_nvd
Published
2024-12-28 10:15
Modified
2024-12-28 10:15
Severity ?
Summary
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
Impacted products
Vendor Product Version



{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/fadump: Move fadump_cma_init to setup_arch() after initmem_init()\n\nDuring early init CMA_MIN_ALIGNMENT_BYTES can be PAGE_SIZE,\nsince pageblock_order is still zero and it gets initialized\nlater during initmem_init() e.g.\nsetup_arch() -\u003e initmem_init() -\u003e sparse_init() -\u003e set_pageblock_order()\n\nOne such use case where this causes issue is -\nearly_setup() -\u003e early_init_devtree() -\u003e fadump_reserve_mem() -\u003e fadump_cma_init()\n\nThis causes CMA memory alignment check to be bypassed in\ncma_init_reserved_mem(). Then later cma_activate_area() can hit\na VM_BUG_ON_PAGE(pfn \u0026 ((1 \u003c\u003c order) - 1)) if the reserved memory\narea was not pageblock_order aligned.\n\nFix it by moving the fadump_cma_init() after initmem_init(),\nwhere other such cma reservations also gets called.\n\n\u003cstack trace\u003e\n==============\npage: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x10010\nflags: 0x13ffff800000000(node=1|zone=0|lastcpupid=0x7ffff) CMA\nraw: 013ffff800000000 5deadbeef0000100 5deadbeef0000122 0000000000000000\nraw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000\npage dumped because: VM_BUG_ON_PAGE(pfn \u0026 ((1 \u003c\u003c order) - 1))\n------------[ cut here ]------------\nkernel BUG at mm/page_alloc.c:778!\n\nCall Trace:\n__free_one_page+0x57c/0x7b0 (unreliable)\nfree_pcppages_bulk+0x1a8/0x2c8\nfree_unref_page_commit+0x3d4/0x4e4\nfree_unref_page+0x458/0x6d0\ninit_cma_reserved_pageblock+0x114/0x198\ncma_init_reserved_areas+0x270/0x3e0\ndo_one_initcall+0x80/0x2f8\nkernel_init_freeable+0x33c/0x530\nkernel_init+0x34/0x26c\nret_from_kernel_user_thread+0x14/0x1c"
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/fadump: mover fadump_cma_init a setup_arch() despu\u00e9s de initmem_init() Durante la inicializaci\u00f3n temprana, CMA_MIN_ALIGNMENT_BYTES puede ser PAGE_SIZE, ya que pageblock_order sigue siendo cero y se inicializa m\u00e1s tarde durante initmem_init(), por ejemplo, setup_arch() -\u0026gt; initmem_init() -\u0026gt; sparse_init() -\u0026gt; set_pageblock_order() Un caso de uso en el que esto causa problemas es: early_setup() -\u0026gt; early_init_devtree() -\u0026gt; fadump_reserve_mem() -\u0026gt; fadump_cma_init() Esto hace que la verificaci\u00f3n de alineaci\u00f3n de memoria de CMA se omita en cma_init_reserved_mem(). Luego, m\u00e1s adelante, cma_activate_area() puede generar un error VM_BUG_ON_PAGE(pfn \u0026amp; ((1 \u0026lt;\u0026lt; order) - 1)) si el \u00e1rea de memoria reservada no estaba alineada con pageblock_order. Solucione este problema moviendo fadump_cma_init() despu\u00e9s de initmem_init(), donde tambi\u00e9n se invocan otras reservas de cma similares.  ============== p\u00e1gina: refcount:0 mapcount:0 mapping:0000000000000000 \u00edndice:0x0 pfn:0x10010 indicadores: 0x13ffff800000000(nodo=1|zona=0|lastcpupid=0x7ffff) CMA sin procesar: 013ffff800000000 5deadbeef0000100 5deadbeef0000122 000000000000000 sin procesar: 000000000000000 00000000000000 000000000000 00000000ffffffff 0000000000000000 p\u00e1gina volcada porque: VM_BUG_ON_PAGE(pfn \u0026amp; ((1 \u0026lt;\u0026lt; orden) - 1)) ------------[ cortar aqu\u00ed ]------------ \u00a1ERROR del kernel en mm/page_alloc.c:778! Seguimiento de llamadas: __free_one_page+0x57c/0x7b0 (no confiable) 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"
    }
  ],
  "id": "CVE-2024-56677",
  "lastModified": "2024-12-28T10:15:08.277",
  "metrics": {},
  "published": "2024-12-28T10:15:08.277",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/05b94cae1c47f94588c3e7096963c1007c4d9c1d"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/7351c5a6507b4401aeecadb5959131410a339520"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/aabef6301dcf410dfd2b8759cd413b2a003c7e3f"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/c5c1d1ef70834013fc3bd12b6a0f4664c6d75a74"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/f551637fe9bf863386309e03f9d148d97f535ad1"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Awaiting Analysis"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.