Description
This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Analysis
Analysis and contextual insights are available on OpenCVE Cloud.
No data.
No data.
No data available yet.
Remediation
No vendor fix or workaround currently provided.
Additional remediation guidance may be available on OpenCVE Cloud.
Tracking
Sign in to view the affected projects.
Advisories
| Source | ID | Title |
|---|---|---|
 EUVD |
EUVD-2022-54499 | This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. |
References
History
Thu, 27 Feb 2025 01:45:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Title | kernel: xen/arm: Fix race in RB-tree based P2M accounting | |
| References |
| |
| Metrics |
threat_severity
|
cvssV3_1
|
Wed, 26 Feb 2025 11:45:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | In the Linux kernel, the following vulnerability has been resolved: xen/arm: Fix race in RB-tree based P2M accounting During the PV driver life cycle the mappings are added to the RB-tree by set_foreign_p2m_mapping(), which is called from gnttab_map_refs() and are removed by clear_foreign_p2m_mapping() which is called from gnttab_unmap_refs(). As both functions end up calling __set_phys_to_machine_multi() which updates the RB-tree, this function can be called concurrently. There is already a "p2m_lock" to protect against concurrent accesses, but the problem is that the first read of "phys_to_mach.rb_node" in __set_phys_to_machine_multi() is not covered by it, so this might lead to the incorrect mappings update (removing in our case) in RB-tree. In my environment the related issue happens rarely and only when PV net backend is running, the xen_add_phys_to_mach_entry() claims that it cannot add new pfn <-> mfn mapping to the tree since it is already exists which results in a failure when mapping foreign pages. But there might be other bad consequences related to the non-protected root reads such use-after-free, etc. While at it, also fix the similar usage in __pfn_to_mfn(), so initialize "struct rb_node *n" with the "p2m_lock" held in both functions to avoid possible bad consequences. This is CVE-2022-33744 / XSA-406. | This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. |
| Title | xen/arm: Fix race in RB-tree based P2M accounting | |
| References |
|
|
Wed, 26 Feb 2025 02:45:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | In the Linux kernel, the following vulnerability has been resolved: xen/arm: Fix race in RB-tree based P2M accounting During the PV driver life cycle the mappings are added to the RB-tree by set_foreign_p2m_mapping(), which is called from gnttab_map_refs() and are removed by clear_foreign_p2m_mapping() which is called from gnttab_unmap_refs(). As both functions end up calling __set_phys_to_machine_multi() which updates the RB-tree, this function can be called concurrently. There is already a "p2m_lock" to protect against concurrent accesses, but the problem is that the first read of "phys_to_mach.rb_node" in __set_phys_to_machine_multi() is not covered by it, so this might lead to the incorrect mappings update (removing in our case) in RB-tree. In my environment the related issue happens rarely and only when PV net backend is running, the xen_add_phys_to_mach_entry() claims that it cannot add new pfn <-> mfn mapping to the tree since it is already exists which results in a failure when mapping foreign pages. But there might be other bad consequences related to the non-protected root reads such use-after-free, etc. While at it, also fix the similar usage in __pfn_to_mfn(), so initialize "struct rb_node *n" with the "p2m_lock" held in both functions to avoid possible bad consequences. This is CVE-2022-33744 / XSA-406. | |
| Title | xen/arm: Fix race in RB-tree based P2M accounting | |
| References |
|
|
Subscriptions
No data.
MITRE
Status: REJECTED
Assigner: Linux
Published:
Updated: 2025-02-26T11:30:26.041Z
Reserved: 2025-02-26T02:21:30.435Z
Link: CVE-2022-49660
Vulnrichment
No data.
NVD
Status : Rejected
Published: 2025-02-26T07:01:41.043
Modified: 2025-02-26T13:15:34.227
Link: CVE-2022-49660
Redhat
OpenCVE Enrichment
No data.
Weaknesses
No weakness.