ghsa-f5pw-c669-x4x7
Vulnerability from github
In the Linux kernel, the following vulnerability has been resolved:
iommu/iova: Fix alloc iova overflows issue
In __alloc_and_insert_iova_range, there is an issue that retry_pfn overflows. The value of iovad->anchor.pfn_hi is ~0UL, then when iovad->cached_node is iovad->anchor, curr_iova->pfn_hi + 1 will overflow. As a result, if the retry logic is executed, low_pfn is updated to 0, and then new_pfn < low_pfn returns false to make the allocation successful.
This issue occurs in the following two situations: 1. The first iova size exceeds the domain size. When initializing iova domain, iovad->cached_node is assigned as iovad->anchor. For example, the iova domain size is 10M, start_pfn is 0x1_F000_0000, and the iova size allocated for the first time is 11M. The following is the log information, new->pfn_lo is smaller than iovad->cached_node.
Example log as follows: [ 223.798112][T1705487] sh: [name:iova&]__alloc_and_insert_iova_range start_pfn:0x1f0000,retry_pfn:0x0,size:0xb00,limit_pfn:0x1f0a00 [ 223.799590][T1705487] sh: [name:iova&]__alloc_and_insert_iova_range success start_pfn:0x1f0000,new->pfn_lo:0x1efe00,new->pfn_hi:0x1f08ff
- The node with the largest iova->pfn_lo value in the iova domain is deleted, iovad->cached_node will be updated to iovad->anchor, and then the alloc iova size exceeds the maximum iova size that can be allocated in the domain.
After judging that retry_pfn is less than limit_pfn, call retry_pfn+1 to fix the overflow issue.
{
"affected": [],
"aliases": [
"CVE-2023-52910"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-21T07:15:06Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\niommu/iova: Fix alloc iova overflows issue\n\nIn __alloc_and_insert_iova_range, there is an issue that retry_pfn\noverflows. The value of iovad-\u003eanchor.pfn_hi is ~0UL, then when\niovad-\u003ecached_node is iovad-\u003eanchor, curr_iova-\u003epfn_hi + 1 will\noverflow. As a result, if the retry logic is executed, low_pfn is\nupdated to 0, and then new_pfn \u003c low_pfn returns false to make the\nallocation successful.\n\nThis issue occurs in the following two situations:\n1. The first iova size exceeds the domain size. When initializing\niova domain, iovad-\u003ecached_node is assigned as iovad-\u003eanchor. For\nexample, the iova domain size is 10M, start_pfn is 0x1_F000_0000,\nand the iova size allocated for the first time is 11M. The\nfollowing is the log information, new-\u003epfn_lo is smaller than\niovad-\u003ecached_node.\n\nExample log as follows:\n[ 223.798112][T1705487] sh: [name:iova\u0026]__alloc_and_insert_iova_range\nstart_pfn:0x1f0000,retry_pfn:0x0,size:0xb00,limit_pfn:0x1f0a00\n[ 223.799590][T1705487] sh: [name:iova\u0026]__alloc_and_insert_iova_range\nsuccess start_pfn:0x1f0000,new-\u003epfn_lo:0x1efe00,new-\u003epfn_hi:0x1f08ff\n\n2. The node with the largest iova-\u003epfn_lo value in the iova domain\nis deleted, iovad-\u003ecached_node will be updated to iovad-\u003eanchor,\nand then the alloc iova size exceeds the maximum iova size that can\nbe allocated in the domain.\n\nAfter judging that retry_pfn is less than limit_pfn, call retry_pfn+1\nto fix the overflow issue.",
"id": "GHSA-f5pw-c669-x4x7",
"modified": "2024-09-12T15:32:59Z",
"published": "2024-08-21T09:31:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52910"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/61cbf790e7329ed78877560be7136f0b911bba7f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c929a230c84441e400c32e7b7b4ab763711fb63e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dcdb3ba7e2a8caae7bfefd603bc22fd0ce9a389c"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
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.