Re: CVE-2022-48900: xen/netfront: react properly to failing gnttab_end_foreign_access_ref()

Re: CVE-2022-48900: xen/netfront: react properly to failing gnttab_end_foreign_access_ref()

[Juergen Gross]

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

Please revoke this CVE, as CVE-2022-23042 has been allocated for this issue
2 years ago already.

This is even clearly visible ...

On 22.08.24 05:31, Greg Kroah-Hartman wrote:
> Description
> ===========
> 
> In the Linux kernel, the following vulnerability has been resolved:
> 
> xen/netfront: react properly to failing gnttab_end_foreign_access_ref()
> 
> When calling gnttab_end_foreign_access_ref() the returned value must
> be tested and the reaction to that value should be appropriate.
> 
> In case of failure in xennet_get_responses() the reaction should not be
> to crash the system, but to disable the network device.
> 
> The calls in setup_netfront() can be replaced by calls of
> gnttab_end_foreign_access(). While at it avoid double free of ring
> pages and grant references via xennet_disconnect_backend() in this case.
> 
> This is CVE-2022-23042 / part of XSA-396.

... here.


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-48900: xen/netfront: react properly to failing gnttab_end_foreign_access_ref()

[Greg Kroah-Hartman]

On Thu, Aug 22, 2024 at 07:46:10AM +0200, Juergen Gross wrote:
> Please revoke this CVE, as CVE-2022-23042 has been allocated for this issue
> 2 years ago already.

Ugh, my fault, I caught many others of these "by hand" but this slipped
through.

> This is even clearly visible ...

Yes, but NOT in the cve.org entry at all, which is what I use to match
against.  Again, why are these commit ids NOT in the cve.org entries?
I know this came up before, but I still find it quite odd.

thanks,

greg k-h