LiveActive security incident?Get immediate response
CVE Record

CVE-2023-53989: arm64: mm: fix VA-range sanity check

In the Linux kernel, the following vulnerability has been resolved: arm64: mm: fix VA-range sanity check Both create_mapping_noalloc() and update_mapping_prot() sanity-check their 'virt' parameter, but the check itself doesn't make much sense. The condition used today appears to be a historical accident. The sanity-check condition: if ((virt >= PAGE_END) && (virt < VMALLOC_START)) { [ ... warning here ... ] return; } ... can only be true for the KASAN shadow region or the module region, and there's no reason to exclude these specifically for creating and updateing mappings. When arm64 support was first upstreamed in commit: c1cc1552616d0f35 ("arm64: MMU initialisation") ... the condition was: if (virt < VMALLOC_START) { [ ... warning here ... ] return; } At the time, VMALLOC_START was the lowest kernel address, and this was checking whether 'virt' would be translated via TTBR1. Subsequently in commit: 14c127c957c1c607 ("arm64: mm: Flip kernel VA space") ... the condition was changed to: if ((virt >= VA_START) && (virt < VMALLOC_START)) { [ ... warning here ... ] return; } This appear to have been a thinko. The commit moved the linear map to the bottom of the kernel address space, with VMALLOC_START being at the halfway point. The old condition would warn for changes to the linear map below this, and at the time VA_START was the end of the linear map. Subsequently we cleaned up the naming of VA_START in commit: 77ad4ce69321abbe ("arm64: memory: rename VA_START to PAGE_END") ... keeping the erroneous condition as: if ((virt >= PAGE_END) && (virt < VMALLOC_START)) { [ ... warning here ... ] return; } Correct the condition to check against the start of the TTBR1 address space, which is currently PAGE_OFFSET. This simplifies the logic, and more clearly matches the "outside kernel range" message in the warning.

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

Security readout for executives and security teams

Plain-English summary

This Linux kernel issue is a faulty arm64 memory-range sanity check. The source describes an incorrect guard in internal mapping helpers, not a confirmed remote attack path. Business urgency is mainly about keeping arm64 Linux kernels on vendor-supported stable updates, especially where kernel integrity matters.

Executive priority

Handle through normal kernel maintenance unless arm64 Linux systems support critical workloads. There is no source-backed active exploitation signal, but kernel fixes should not be deferred indefinitely.

Technical view

On arm64, create_mapping_noalloc() and update_mapping_prot() checked virt against the wrong virtual-address range. The old condition could reject KASAN shadow or module-region mappings without a stated reason. The fix changes the check to use PAGE_OFFSET, matching the intended TTBR1 kernel address-space boundary.

Likely exposure

Exposure appears limited to Linux arm64 kernels in the affected ranges listed by the CVE record. The bundle does not identify affected distributions, appliances, cloud images, or non-arm64 platforms. Confirm exposure through kernel version, architecture, and vendor backport status.

Exploitation context

The source bundle marks KEV as false and provides no cited evidence of active exploitation, public exploit code, or a practical attack chain. The available evidence is a kernel correctness fix with incomplete security-impact detail.

Researcher notes

The record lacks CVSS, CWE, and exploitability detail. Analysis should focus on affected arm64 kernel lineage, the PAGE_OFFSET boundary correction, and whether downstream vendors shipped equivalent backports.

Mitigation direction

  • Update affected arm64 Linux kernels to vendor-supported builds containing the referenced stable fixes.
  • Check distribution advisories for backported fixes before relying on upstream version numbers.
  • Prioritize systems where kernel compromise or instability has high operational impact.
  • If no vendor fix is available, follow vendor guidance for compensating controls.

Validation and detection

  • Inventory Linux systems running on arm64 architecture.
  • Compare kernel versions and commits against the CVE record and stable fix references.
  • Confirm whether your distribution has backported the relevant stable commit.
  • Record systems that remain on affected kernels for patch tracking.
Prepared
Confidence
medium
Sources
8

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-53989 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
7Source 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
LinuxLinux14c127c957c1c6070647c171e72f06e0db275ebf, 14c127c957c1c6070647c171e72f06e0db275ebf, 14c127c957c1c6070647c171e72f06e0db275ebf, 14c127c957c1c6070647c171e72f06e0db275ebf, 14c127c957c1c6070647c171e72f06e0db275ebf, 14c127c957c1c6070647c171e72f06e0db275ebfunaffected
LinuxLinux5.4, 0, 5.4.251, 5.10.188, 5.15.150, 6.1.175, 6.4.7, 6.5affected
Weakness

CWE details

No CWE listed

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