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

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