CVE-2022-49660: xen/arm: Fix race in RB-tree based P2M accounting

CVE-2022-49660: xen/arm: Fix race in RB-tree based P2M accounting

[Greg Kroah-Hartman]

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.

The Linux kernel CVE team has assigned CVE-2022-49660 to this issue.


Affected and fixed versions
===========================

	Fixed in 4.9.322 with commit 856d1b8e6e826b5087f1ea3fdbabda3557d73599
	Fixed in 4.14.287 with commit 01b86faa64b1f5aa04c0b3ca2001b0a8474f3006
	Fixed in 4.19.251 with commit 274cb74da15ed13292fcec9097f04332eb3eea17
	Fixed in 5.4.204 with commit 5c03cad51b84fb26ccea7fd99130d8ec47949cfc
	Fixed in 5.10.129 with commit 43c8d33ce353091f15312cb6de3531517d7bba90
	Fixed in 5.15.53 with commit 9f83c8f6ab14bbf4311b70bf1b7290d131059101
	Fixed in 5.18.10 with commit efd9826d4c08abac7e8840757e3e1bfcf2876f70
	Fixed in 5.19 with commit b75cd218274e01d026dc5240e86fdeb44bbed0c8

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2022-49660
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	arch/arm/xen/p2m.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/856d1b8e6e826b5087f1ea3fdbabda3557d73599
	https://git.kernel.org/stable/c/01b86faa64b1f5aa04c0b3ca2001b0a8474f3006
	https://git.kernel.org/stable/c/274cb74da15ed13292fcec9097f04332eb3eea17
	https://git.kernel.org/stable/c/5c03cad51b84fb26ccea7fd99130d8ec47949cfc
	https://git.kernel.org/stable/c/43c8d33ce353091f15312cb6de3531517d7bba90
	https://git.kernel.org/stable/c/9f83c8f6ab14bbf4311b70bf1b7290d131059101
	https://git.kernel.org/stable/c/efd9826d4c08abac7e8840757e3e1bfcf2876f70
	https://git.kernel.org/stable/c/b75cd218274e01d026dc5240e86fdeb44bbed0c8

Re: CVE-2022-49660: xen/arm: Fix race in RB-tree based P2M accounting

[Juergen Gross]

[-- Attachment #1.1.1: Type: text/plain, Size: 1636 bytes --]

On 26.02.25 03:23, Greg Kroah-Hartman wrote:
> 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.

As clearly visible in the commit message: there is already a CVE assigned.

Please revoke CVE-2022-49660.


Juergen

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3743 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: CVE-2022-49660: xen/arm: Fix race in RB-tree based P2M accounting

[Greg Kroah-Hartman]

On Wed, Feb 26, 2025 at 08:01:04AM +0100, Juergen Gross wrote:
> On 26.02.25 03:23, Greg Kroah-Hartman wrote:
> > 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.
> 
> As clearly visible in the commit message: there is already a CVE assigned.
> 
> Please revoke CVE-2022-49660.

Ugh, I thought I caught all of these in doing my reviews, sorry about
that.

And any reason why the cve.org record does NOT have this git id in it
for this CVE record?  I check them all before assigning new ids like
this (it was part of the big GSD dump that we are slowly backfilling)
and I use that to prevent duplicate ids from being created.

Also thanks for the review of all of the other xen cves, I'll go revoke
them now as well.

thanks,

greg k-h