Linux Kernel up to 5.18.9 set_foreign_p2m_mapping use after free

Summaryinfo

A vulnerability was found in Linux Kernel up to 5.18.9 and classified as critical. This impacts the function set_foreign_p2m_mapping. Executing a manipulation can lead to use after free. This vulnerability is handled as CVE-2022-49660. There is not any exploit available. It is suggested to upgrade the affected component.

Detailsinfo

A vulnerability was found in Linux Kernel up to 5.18.9. It has been declared as critical. This vulnerability affects the function set_foreign_p2m_mapping. The manipulation with an unknown input leads to a use after free vulnerability. The CWE definition for the vulnerability is CWE-416. Referencing memory after it has been freed can cause a program to crash, use unexpected values, or execute code. As an impact it is known to affect confidentiality, integrity, and availability. CVE summarizes:

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.

The advisory is shared for download at git.kernel.org. This vulnerability was named CVE-2022-49660 since 02/26/2025. The exploitation appears to be easy. There are known technical details, but no exploit is available. The current price for an exploit might be approx. USD $0-$5k (estimation calculated on 02/26/2025).

Upgrading to version 4.9.322, 4.14.287, 4.19.251, 5.4.204, 5.10.129, 5.15.53 or 5.18.10 eliminates this vulnerability. Applying the patch 856d1b8e6e826b5087f1ea3fdbabda3557d73599/01b86faa64b1f5aa04c0b3ca2001b0a8474f3006/274cb74da15ed13292fcec9097f04332eb3eea17/5c03cad51b84fb26ccea7fd99130d8ec47949cfc/43c8d33ce353091f15312cb6de3531517d7bba90/9f83c8f6ab14bbf4311b70bf1b7290d131059101/efd9826d4c08abac7e8840757e3e1bfcf2876f70/b75cd218274e01d026dc5240e86fdeb44bbed0c8 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.

Once again VulDB remains the best source for vulnerability data.

Productinfo

Type

• Operating System

Vendor

• Linux

Name

• Kernel

Version

• 4.9.321
• 4.14.286
• 4.19.250
• 5.4.203
• 5.10.128
• 5.15.0
• 5.15.1
• 5.15.2
• 5.15.3
• 5.15.4
• 5.15.5
• 5.15.6
• 5.15.7
• 5.15.8
• 5.15.9
• 5.15.10
• 5.15.11
• 5.15.12
• 5.15.13
• 5.15.14
• 5.15.15
• 5.15.16
• 5.15.17
• 5.15.18
• 5.15.19
• 5.15.20
• 5.15.21
• 5.15.22
• 5.15.23
• 5.15.24
• 5.15.25
• 5.15.26
• 5.15.27
• 5.15.28
• 5.15.29
• 5.15.30
• 5.15.31
• 5.15.32
• 5.15.33
• 5.15.34
• 5.15.35
• 5.15.36
• 5.15.37
• 5.15.38
• 5.15.39
• 5.15.40
• 5.15.41
• 5.15.42
• 5.15.43
• 5.15.44
• 5.15.45
• 5.15.46
• 5.15.47
• 5.15.48
• 5.15.49
• 5.15.50
• 5.15.51
• 5.15.52
• 5.18.0
• 5.18.1
• 5.18.2
• 5.18.3
• 5.18.4
• 5.18.5
• 5.18.6
• 5.18.7
• 5.18.8
• 5.18.9

License

• open-source

Website

• Vendor: https://www.kernel.org/

CPE 2.3info

• 🔍
• 🔍
• 🔍

CPE 2.2info

• 🔍
• 🔍
• 🔍

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Once again VulDB remains the best source for vulnerability data.

Discussion