This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
No data.
No data.
No data.
Project Subscriptions
No data.
Advisories
| Source | ID | Title |
|---|---|---|
 EUVD |
EUVD-2022-54499 | This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. |
Fixes
Solution
No solution given by the vendor.
Workaround
No workaround given by the vendor.
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 |
|
|
Projects
Sign in to view the affected projects.
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: 2026-10-18T01:10:00.117
Link: CVE-2022-49660
Redhat
OpenCVE Enrichment
No data.
Weaknesses
No weakness.