LiveActive security incident?Get immediate response
CVE Record

CVE-2023-54167: m68k: mm: Move initrd phys_to_virt handling after paging_init()

In the Linux kernel, the following vulnerability has been resolved: m68k: mm: Move initrd phys_to_virt handling after paging_init() When booting with an initial ramdisk on platforms where physical memory does not start at address zero (e.g. on Amiga): initrd: 0ef0602c - 0f800000 Zone ranges: DMA [mem 0x0000000008000000-0x000000f7ffffffff] Normal empty Movable zone start for each node Early memory node ranges node 0: [mem 0x0000000008000000-0x000000000f7fffff] Initmem setup node 0 [mem 0x0000000008000000-0x000000000f7fffff] Unable to handle kernel access at virtual address (ptrval) Oops: 00000000 Modules linked in: PC: [<00201d3c>] memcmp+0x28/0x56 As phys_to_virt() relies on m68k_memoffset and module_fixup(), it must not be called before paging_init(). Hence postpone the phys_to_virt handling for the initial ramdisk until after calling paging_init(). While at it, reduce #ifdef clutter by using IS_ENABLED() instead.

UnknownCVSS not scoredNot KEV-listedUpdated
Discuss exposureBack to CVEs
Glexia's TakeAutomated analysislow

Security readout for executives and security teams

Plain-English summary

This is a Linux kernel m68k boot-time bug. On systems such as Amiga where physical memory does not start at zero, booting with an initial ramdisk can trigger a kernel oops. The provided evidence points to availability impact during boot, not remote compromise.

Executive priority

Low for most organizations because exposure is narrow and no exploitation is reported. Prioritize only if the business operates m68k Linux devices where boot reliability matters.

Technical view

The m68k kernel called phys_to_virt() for initrd handling before paging_init(). Because phys_to_virt() depends on m68k_memoffset and module_fixup(), this ordering could fault during early boot on non-zero-based physical memory platforms. Stable commits move initrd phys_to_virt handling after paging_init().

Likely exposure

Exposure appears limited to Linux m68k systems using an initial ramdisk on platforms where physical memory does not begin at address zero. Mainstream x86, Arm, and cloud Linux deployments are not identified as affected in the provided bundle.

Exploitation context

No active exploitation is cited, and KEV is false. The source describes a boot oops condition rather than an attacker-driven exploit path. Evidence is incomplete for CVSS, CWE, or broader security impact.

Researcher notes

The record lacks CVSS, CWE, and detailed affected version boundaries. Analysis should stay tied to m68k initrd boot behavior and the three kernel stable commits. Do not generalize this to all Linux systems.

Mitigation direction

  • Inventory any Linux m68k systems, especially Amiga-like platforms.
  • Check whether deployed kernels include the referenced stable fixes.
  • Update to a vendor kernel containing the initrd handling fix.
  • If unsupported, request vendor guidance for an appropriate backport.
  • Treat boot failures as availability incidents on affected devices.

Validation and detection

  • Confirm the system architecture is m68k before prioritizing remediation.
  • Check whether boot uses an initial ramdisk.
  • Review kernel version and applied stable commit history.
  • Test fixed kernels on representative non-zero physical memory hardware.
  • Monitor boot logs for early initrd-related oops messages.
Prepared
Confidence
medium
Sources
5

Public sources used

Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.

Potential ATT&CK relevance

Conservative CVE-to-ATT&CK context

These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.

ATT&CK lookup starting points

Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.

cve · low confidence lookup

CVE-2023-54167 mapping review

Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.

Open ATT&CK lookup
Vulnerability profileCVE Program record
Severity
Unknown
CVSS
Not scored
Known Exploited
No
Published
Official CVE source material

CNA and ADP enrichment extracted from CVE v5

These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.

0CVSS vectors
3Timeline events
0ADP providers
4Source links

Vulnerability timeline

Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.

  1. CVE reservedCVE Program

    The CVE ID was reserved by the assigning CNA.

  2. CVE publishedCVE Program

    The CVE record was published.

  3. CVE updatedCVE Program

    The CVE record metadata indicates this as the latest update time.

Source materials

Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
LinuxLinux376e3fdecb0dcae216c0ac559cff066f460bf47b, 376e3fdecb0dcae216c0ac559cff066f460bf47b, 376e3fdecb0dcae216c0ac559cff066f460bf47bunaffected
LinuxLinux5.17, 0, 6.1.20, 6.2.7, 6.3affected
Weakness

CWE details

No CWE listed

CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.