fkie_cve-2023-53989
Vulnerability from fkie_nvd
Published
2025-12-24 11:15
Modified
2025-12-29 15:58
Severity ?
Summary
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.
References
Impacted products
| Vendor | Product | Version |
|---|
{
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\narm64: mm: fix VA-range sanity check\n\nBoth create_mapping_noalloc() and update_mapping_prot() sanity-check\ntheir \u0027virt\u0027 parameter, but the check itself doesn\u0027t make much sense.\nThe condition used today appears to be a historical accident.\n\nThe sanity-check condition:\n\n\tif ((virt \u003e= PAGE_END) \u0026\u0026 (virt \u003c VMALLOC_START)) {\n\t\t[ ... warning here ... ]\n\t\treturn;\n\t}\n\n... can only be true for the KASAN shadow region or the module region,\nand there\u0027s no reason to exclude these specifically for creating and\nupdateing mappings.\n\nWhen arm64 support was first upstreamed in commit:\n\n c1cc1552616d0f35 (\"arm64: MMU initialisation\")\n\n... the condition was:\n\n\tif (virt \u003c VMALLOC_START) {\n\t\t[ ... warning here ... ]\n\t\treturn;\n\t}\n\nAt the time, VMALLOC_START was the lowest kernel address, and this was\nchecking whether \u0027virt\u0027 would be translated via TTBR1.\n\nSubsequently in commit:\n\n 14c127c957c1c607 (\"arm64: mm: Flip kernel VA space\")\n\n... the condition was changed to:\n\n\tif ((virt \u003e= VA_START) \u0026\u0026 (virt \u003c VMALLOC_START)) {\n\t\t[ ... warning here ... ]\n\t\treturn;\n\t}\n\nThis appear to have been a thinko. The commit moved the linear map to\nthe bottom of the kernel address space, with VMALLOC_START being at the\nhalfway point. The old condition would warn for changes to the linear\nmap below this, and at the time VA_START was the end of the linear map.\n\nSubsequently we cleaned up the naming of VA_START in commit:\n\n 77ad4ce69321abbe (\"arm64: memory: rename VA_START to PAGE_END\")\n\n... keeping the erroneous condition as:\n\n\tif ((virt \u003e= PAGE_END) \u0026\u0026 (virt \u003c VMALLOC_START)) {\n\t\t[ ... warning here ... ]\n\t\treturn;\n\t}\n\nCorrect the condition to check against the start of the TTBR1 address\nspace, which is currently PAGE_OFFSET. This simplifies the logic, and\nmore clearly matches the \"outside kernel range\" message in the warning."
}
],
"id": "CVE-2023-53989",
"lastModified": "2025-12-29T15:58:56.260",
"metrics": {},
"published": "2025-12-24T11:15:51.803",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/32020fc2a8373d3de35ae6d029d5969a42651e7a"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/621619f626cbe702ddbdc54117f3868b8ebd8129"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/9d8d3df71516ec3236d8d93ff029d251377ba4b1"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/ab9b4008092c86dc12497af155a0901cc1156999"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/b03c7fcc5ed854d0e1b27e9abf12428bfa751a37"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Awaiting Analysis"
}
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.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- 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.
Loading…
Loading…