Pkg xen devel - Oct 2022 - Bug#1021668: xen: CVE-2022-33749 CVE-2022-33748 CVE-2022-33747 CVE-2022-33746

Source: xen
X-Debbugs-CC: team at security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerabilities were published for xen.

CVE-2022-33749[0]:
| XAPI open file limit DoS It is possible for an unauthenticated client
| on the network to cause XAPI to hit its file-descriptor limit. This
| causes XAPI to be unable to accept new requests for other (trusted)
| clients, and blocks XAPI from carrying out any tasks that require the
| opening of file descriptors.

https://xenbits.xen.org/xsa/advisory-413.html

CVE-2022-33748[1]:
| lock order inversion in transitive grant copy handling As part of
| XSA-226 a missing cleanup call was inserted on an error handling path.
| While doing so, locking requirements were not paid attention to. As a
| result two cooperating guests granting each other transitive grants
| can cause locks to be acquired nested within one another, but in
| respectively opposite order. With suitable timing between the involved
| grant copy operations this may result in the locking up of a CPU.

https://xenbits.xen.org/xsa/advisory-411.html

CVE-2022-33747[2]:
| Arm: unbounded memory consumption for 2nd-level page tables Certain
| actions require e.g. removing pages from a guest's P2M (Physical-to-
| Machine) mapping. When large pages are in use to map guest pages in
| the 2nd-stage page tables, such a removal operation may incur a memory
| allocation (to replace a large mapping with individual smaller ones).
| These memory allocations are taken from the global memory pool. A
| malicious guest might be able to cause the global memory pool to be
| exhausted by manipulating its own P2M mappings.

https://xenbits.xen.org/xsa/advisory-409.html

CVE-2022-33746[3]:
| P2M pool freeing may take excessively long The P2M pool backing second
| level address translation for guests may be of significant size.
| Therefore its freeing may take more time than is reasonable without
| intermediate preemption checks. Such checking for the need to preempt
| was so far missing.

https://xenbits.xen.org/xsa/advisory-410.html

If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-33749
    https://www.cve.org/CVERecord?id=CVE-2022-33749
[1] https://security-tracker.debian.org/tracker/CVE-2022-33748
    https://www.cve.org/CVERecord?id=CVE-2022-33748
[2] https://security-tracker.debian.org/tracker/CVE-2022-33747
    https://www.cve.org/CVERecord?id=CVE-2022-33747
[3] https://security-tracker.debian.org/tracker/CVE-2022-33746
    https://www.cve.org/CVERecord?id=CVE-2022-33746

Please adjust the affected versions in the BTS as needed.

Hi,

On Wed, Oct 12, 2022 at 07:38:17PM +0200, Moritz M?hlenhoff
wrote:
> Source: xen
> X-Debbugs-CC: team at security.debian.org
> Severity: important
> Tags: security
> 
> Hi,
> 
> The following vulnerabilities were published for xen.
> 
> CVE-2022-33749[0]:
> | XAPI open file limit DoS It is possible for an unauthenticated client
> | on the network to cause XAPI to hit its file-descriptor limit. This
> | causes XAPI to be unable to accept new requests for other (trusted)
> | clients, and blocks XAPI from carrying out any tasks that require the
> | opening of file descriptors.
> 
> https://xenbits.xen.org/xsa/advisory-413.html
FTR, I think this should not be tracked for src:xen (and upated the
security-tracker already earlier), as it is for xapi (not found in
src:xen but in the earlier removed src:xen-api).

Regards,
Salvatore

Hi!

On 10/12/22 19:38, Moritz M?hlenhoff wrote:
> Source: xen
> X-Debbugs-CC: team at security.debian.org
> Severity: important
> Tags: security
> 
> Hi,
> 
> The following vulnerabilities were published for xen.
> 
> CVE-[...]
Thanks for the overview. The XAPI one indeed does not apply to src:xen.

I have a question, since the 'bug' report does not contain a question,
or explicit call for action, and I have not seen it in this way before.

Does explicitly opening a BTS bug mean that, like we use to call it,
"these CVEs warrant a DSA", and that it is a request for an ASAP
package
update and preparing a security update for stable, or, is this a new
thing where BTS bugs are opened for packages, just in case the
maintainer did not already track security issues themselves actively?

I'm just wondering...

Thanks,
Hans

Hi Hans,

On Tue, Oct 18, 2022 at 02:17:32PM +0200, Hans van Kranenburg
wrote:
> Hi!
> 
> On 10/12/22 19:38, Moritz M?hlenhoff wrote:
> > Source: xen
> > X-Debbugs-CC: team at security.debian.org
> > Severity: important
> > Tags: security
> > 
> > Hi,
> > 
> > The following vulnerabilities were published for xen.
> > 
> > CVE-[...]
> Thanks for the overview. The XAPI one indeed does not apply to src:xen.
> 
> I have a question, since the 'bug' report does not contain a
question,
> or explicit call for action, and I have not seen it in this way before.
> 
> Does explicitly opening a BTS bug mean that, like we use to call it,
> "these CVEs warrant a DSA", and that it is a request for an ASAP
package
> update and preparing a security update for stable, or, is this a new
> thing where BTS bugs are opened for packages, just in case the
> maintainer did not already track security issues themselves actively?
Filling a bug or even it's severity may be completely orthogonal to
the question if something warrants a DSA. In fact you will notice
in the security-tracker issues triaged as no-dsa, not warranting a DSA
but which could be fixed in a point release or piggy-backed as well in
a later update filled as bug for tracking as well in the BTS with
severity grave, indicating though that the issue should be assumed RC
and be fixed in testing so that the next stable version will include a
fix.

Filling a bug make sure maintaines are aware of the issues.

Hope this helps,

Regards,
Salvatore

On Tue, Oct 18, 2022 at 02:17:32PM +0200, Hans van Kranenburg
wrote:
> Does explicitly opening a BTS bug mean that, like we use to call it,
> "these CVEs warrant a DSA",
No, in general we aim to file bugs for any open CVEs regardless of
the DSA state. This allows people to see that an issue is known
(and some maintainers might also not have noticed in time).
> and that it is a request for an ASAP package
> update and preparing a security update for stable, or, is this a new
> thing where BTS bugs are opened for packages, just in case the
> maintainer did not already track security issues themselves actively?
For the latest set of Xen issues my estimate is that we can postpone
them until the next batch, they seem all of moderate/limited impact.
But let me know if you think otherwise.

Cheers,
        Moritz

Hi,

On 18/10/2022 22:31, Moritz Muehlenhoff wrote:
> On Tue, Oct 18, 2022 at 02:17:32PM +0200, Hans van Kranenburg wrote:
>> Does explicitly opening a BTS bug mean that, like we use to call it,
>> "these CVEs warrant a DSA",
> 
> No, in general we aim to file bugs for any open CVEs regardless of
> the DSA state. This allows people to see that an issue is known
> (and some maintainers might also not have noticed in time).
Ok!
>> and that it is a request for an ASAP package
>> update and preparing a security update for stable, or, is this a new
>> thing where BTS bugs are opened for packages, just in case the
>> maintainer did not already track security issues themselves actively?
> 
> For the latest set of Xen issues my estimate is that we can postpone
> them until the next batch, they seem all of moderate/limited impact.
> But let me know if you think otherwise.
I agree. Let's do them together with the new stuff that's planned for
Nov 1st, https://xenbits.xen.org/xsa/

Hans

> > For the latest set of Xen issues my estimate is that we can postpone
> > them until the next batch, they seem all of moderate/limited impact.
> > But let me know if you think otherwise.
> 
> I agree. Let's do them together with the new stuff that's planned
for
> Nov 1st, https://xenbits.xen.org/xsa/
Ack, I've updated the Security Tracker.

Cheers,
        Moritz

Hi,

On 10/19/22 21:55, Moritz Muehlenhoff wrote:
>>> For the latest set of Xen issues my estimate is that we can
postpone
>>> them until the next batch, they seem all of moderate/limited
impact.
>>> But let me know if you think otherwise.
>>
>> I agree. Let's do them together with the new stuff that's
planned for
>> Nov 1st, https://xenbits.xen.org/xsa/
> 
> Ack, I've updated the Security Tracker.
I'm having a look at this now, and while writing the changelog entry, I
run into the following thing:

XSA-403 has 4 CVE numbers. AFAIUI the first two are about the fixes done
to Linux, and the other two are about changes to Xen. Shouldn't the
Debian security tracker reflect that?

CVE-2022-26365 CVE-2022-33740 -> src:linux only ?
CVE-2022-33741 CVE-2022-33742 -> src:xen only ?

And for XSA-403, at first upstream was unsure about what to do for older
Xen versions where the patches would be an ABI breaker. In the end, they
did apply the more coarse-grained patch to at least offer some kind of
mitigation in case a user wants to use it.

So, the changelog line I'm including now will just be:
  - Linux disk/nic frontends data leaks
    XSA-403 CVE-2022-33741 CVE-2022-33742

HTH,
Hans

Hi,

On Wed, Nov 02, 2022 at 08:02:26PM +0100, Hans van Kranenburg
wrote:
> Hi,
> 
> On 10/19/22 21:55, Moritz Muehlenhoff wrote:
> >>> For the latest set of Xen issues my estimate is that we can
postpone
> >>> them until the next batch, they seem all of moderate/limited
impact.
> >>> But let me know if you think otherwise.
> >>
> >> I agree. Let's do them together with the new stuff that's
planned for
> >> Nov 1st, https://xenbits.xen.org/xsa/
> > 
> > Ack, I've updated the Security Tracker.
> 
> I'm having a look at this now, and while writing the changelog entry, I
> run into the following thing:
> 
> XSA-403 has 4 CVE numbers. AFAIUI the first two are about the fixes done
> to Linux, and the other two are about changes to Xen. Shouldn't the
> Debian security tracker reflect that?
> 
> CVE-2022-26365 CVE-2022-33740 -> src:linux only ?
> CVE-2022-33741 CVE-2022-33742 -> src:xen only ?
Speaking for src:linux I do not think we need to change the tracking:

CVE-2022-26365: 2f446ffe9d73 ("xen/blkfront: fix leaking data in shared
pages")
CVE-2022-33740: 307c8de2b023 ("xen/netfront: fix leaking data in shared
pages")
CVE-2022-33741: 4491001c2e0f ("xen/netfront: force data bouncing when
backend is untrusted")
CVE-2022-33742: 2400617da7ee ("xen/blkfront: force data bouncing when
backend is untrusted")

Regards,
Salvatore

Aha!

On 02/11/2022 21:53, Salvatore Bonaccorso wrote:
> Hi,
> 
> On Wed, Nov 02, 2022 at 08:02:26PM +0100, Hans van Kranenburg wrote:
>> Hi,
>>
>> On 10/19/22 21:55, Moritz Muehlenhoff wrote:
>>>>> For the latest set of Xen issues my estimate is that we can
postpone
>>>>> them until the next batch, they seem all of
moderate/limited impact.
>>>>> But let me know if you think otherwise.
>>>>
>>>> I agree. Let's do them together with the new stuff
that's planned for
>>>> Nov 1st, https://xenbits.xen.org/xsa/
>>>
>>> Ack, I've updated the Security Tracker.
>>
>> I'm having a look at this now, and while writing the changelog
entry, I
>> run into the following thing:
>>
>> XSA-403 has 4 CVE numbers. AFAIUI the first two are about the fixes
done
>> to Linux, and the other two are about changes to Xen. Shouldn't the
>> Debian security tracker reflect that?
>>
>> CVE-2022-26365 CVE-2022-33740 -> src:linux only ?
>> CVE-2022-33741 CVE-2022-33742 -> src:xen only ?
> 
> Speaking for src:linux I do not think we need to change the tracking:
> 
> CVE-2022-26365: 2f446ffe9d73 ("xen/blkfront: fix leaking data in
shared pages")
> CVE-2022-33740: 307c8de2b023 ("xen/netfront: fix leaking data in
shared pages")
> CVE-2022-33741: 4491001c2e0f ("xen/netfront: force data bouncing when
backend is untrusted")
> CVE-2022-33742: 2400617da7ee ("xen/blkfront: force data bouncing when
backend is untrusted")
Riiight. Thanks, now I get why I cannot find any CVE number related to
XSA-403 listed in the Xen upstream changes (at least for 4.14 which I'm
working on now). They're all over there at the Linux side.

Hans

Hi Hans

On Fri, Nov 04, 2022 at 02:59:29PM +0100, Hans van Kranenburg
wrote:
> Aha!
> 
> On 02/11/2022 21:53, Salvatore Bonaccorso wrote:
> > Hi,
> > 
> > On Wed, Nov 02, 2022 at 08:02:26PM +0100, Hans van Kranenburg wrote:
> >> Hi,
> >>
> >> On 10/19/22 21:55, Moritz Muehlenhoff wrote:
> >>>>> For the latest set of Xen issues my estimate is that
we can postpone
> >>>>> them until the next batch, they seem all of
moderate/limited impact.
> >>>>> But let me know if you think otherwise.
> >>>>
> >>>> I agree. Let's do them together with the new stuff
that's planned for
> >>>> Nov 1st, https://xenbits.xen.org/xsa/
> >>>
> >>> Ack, I've updated the Security Tracker.
> >>
> >> I'm having a look at this now, and while writing the changelog
entry, I
> >> run into the following thing:
> >>
> >> XSA-403 has 4 CVE numbers. AFAIUI the first two are about the
fixes done
> >> to Linux, and the other two are about changes to Xen.
Shouldn't the
> >> Debian security tracker reflect that?
> >>
> >> CVE-2022-26365 CVE-2022-33740 -> src:linux only ?
> >> CVE-2022-33741 CVE-2022-33742 -> src:xen only ?
> > 
> > Speaking for src:linux I do not think we need to change the tracking:
> > 
> > CVE-2022-26365: 2f446ffe9d73 ("xen/blkfront: fix leaking data in
shared pages")
> > CVE-2022-33740: 307c8de2b023 ("xen/netfront: fix leaking data in
shared pages")
> > CVE-2022-33741: 4491001c2e0f ("xen/netfront: force data bouncing
when backend is untrusted")
> > CVE-2022-33742: 2400617da7ee ("xen/blkfront: force data bouncing
when backend is untrusted")
> 
> Riiight. Thanks, now I get why I cannot find any CVE number related to
> XSA-403 listed in the Xen upstream changes (at least for 4.14 which I'm
> working on now). They're all over there at the Linux side.
It looks that there are still changes needed on the xen side, at least
that is my understanding reading through
https://xenbits.xen.org/xsa/advisory-403.html
Quoting the advisory:

| For the stable branches (Xen 4.16.x - Xen 4.13.x) patch 1 introduces support
to
| libxl for libxl_{disk,nic}_backend_untrusted environment variable to be used
in
| order to set whether disk and network backends should be trusted.  Patch 2
| reverts patch 1 and instead provides the more fine grained per-device options
| that break the libxl ABI.
| 
| Note that applying patch 2 to any of the stable releases will require a
rebuild
| of any consumers of the libxl library, as it introduces an ABI breakage and
| hence won't be applied to the official repository stable branches.  Users
of
| stable releases wanting to use the functionality provided by patch 2 will need
| to apply it manually.

This is the reason that in fact for those four CVEs, weh ave marked
for bullseye:

        [bullseye] - xen <ignored> (Too intrusive too backport)

The "signaling of whether a frontend should consider a backend as
potentially malicious can be done **from either the Linux kernel
command line or the toolstack.**" (highlighting is added by me).

So IMHO it is similarly correct to track src:xen under those CVEs, and
they are marked as fixed with 4.16.2-1. *But* for bullseye, they can
be ignored due to above reasons.

Regards,
Salvatore

Hi :)

On 04/11/2022 22:51, Salvatore Bonaccorso wrote:
> Hi Hans
> 
> On Fri, Nov 04, 2022 at 02:59:29PM +0100, Hans van Kranenburg wrote:
>> Aha!
>>
>> On 02/11/2022 21:53, Salvatore Bonaccorso wrote:
>>> Hi,
>>>
>>> On Wed, Nov 02, 2022 at 08:02:26PM +0100, Hans van Kranenburg
wrote:
>>>> Hi,
>>>>
>>>> On 10/19/22 21:55, Moritz Muehlenhoff wrote:
>>>>>>> For the latest set of Xen issues my estimate is
that we can postpone
>>>>>>> them until the next batch, they seem all of
moderate/limited impact.
>>>>>>> But let me know if you think otherwise.
>>>>>>
>>>>>> I agree. Let's do them together with the new stuff
that's planned for
>>>>>> Nov 1st, https://xenbits.xen.org/xsa/
>>>>>
>>>>> Ack, I've updated the Security Tracker.
>>>>
>>>> I'm having a look at this now, and while writing the
changelog entry, I
>>>> run into the following thing:
>>>>
>>>> XSA-403 has 4 CVE numbers. AFAIUI the first two are about the
fixes done
>>>> to Linux, and the other two are about changes to Xen.
Shouldn't the
>>>> Debian security tracker reflect that?
>>>>
>>>> CVE-2022-26365 CVE-2022-33740 -> src:linux only ?
>>>> CVE-2022-33741 CVE-2022-33742 -> src:xen only ?
>>>
>>> Speaking for src:linux I do not think we need to change the
tracking:
>>>
>>> CVE-2022-26365: 2f446ffe9d73 ("xen/blkfront: fix leaking data
in shared pages")
>>> CVE-2022-33740: 307c8de2b023 ("xen/netfront: fix leaking data
in shared pages")
>>> CVE-2022-33741: 4491001c2e0f ("xen/netfront: force data
bouncing when backend is untrusted")
>>> CVE-2022-33742: 2400617da7ee ("xen/blkfront: force data
bouncing when backend is untrusted")
>>
>> Riiight. Thanks, now I get why I cannot find any CVE number related to
>> XSA-403 listed in the Xen upstream changes (at least for 4.14 which
I'm
>> working on now). They're all over there at the Linux side.
> 
> It looks that there are still changes needed on the xen side, at least
> that is my understanding reading through
https://xenbits.xen.org/xsa/advisory-403.html
> Quoting the advisory:
> 
> | For the stable branches (Xen 4.16.x - Xen 4.13.x) patch 1 introduces
support to
> | libxl for libxl_{disk,nic}_backend_untrusted environment variable to be
used in
> | order to set whether disk and network backends should be trusted.  Patch
2
> | reverts patch 1 and instead provides the more fine grained per-device
options
> | that break the libxl ABI.
> | 
> | Note that applying patch 2 to any of the stable releases will require a
rebuild
> | of any consumers of the libxl library, as it introduces an ABI breakage
and
> | hence won't be applied to the official repository stable branches. 
Users of
> | stable releases wanting to use the functionality provided by patch 2 will
need
> | to apply it manually.
> 
> This is the reason that in fact for those four CVEs, weh ave marked
> for bullseye:
> 
>         [bullseye] - xen <ignored> (Too intrusive too backport)
> 
> The "signaling of whether a frontend should consider a backend as
> potentially malicious can be done **from either the Linux kernel
> command line or the toolstack.**" (highlighting is added by me).
> 
> So IMHO it is similarly correct to track src:xen under those CVEs, and
> they are marked as fixed with 4.16.2-1. *But* for bullseye, they can
> be ignored due to above reasons.
Yes, so the Xen part is about the "reporting whether the backend is to
be trusted".

That 'patch 1', the all-or-nothing option to signal the guest kernel is
now included with this update. But neither that change, nor the more
fine-grained patch 2 is directly linked to a CVE number. That change on
itself will not fix anything for any of the 4 CVE numbers.

Also, for 4.16 the story is the same, by the way. It's only in 4.17
which is to be released in the upcoming week that the otherwise lilbxl
ABI breaking changes are fully included, but even that doesn't change
anything for the CVE administration.

After all, it is a bit of a moot point for us. The only scenario in
which all of this is relevant is when using a 'driver domain' to
delegate the blk/net backend part to another untrusted guest domain.
Using this functionality is not properly enabled/supported out of the
box in our package builds for Debian.

Sometimes these XSA are like a little scavenger hunt.

Hans

Your message dated Sat, 19 Nov 2022 18:17:51 +0000
with message-id <E1owSPX-005BkI-Nn at fasolo.debian.org>
and subject line Bug#1021668: fixed in xen 4.14.5+86-g1c354767d5-1
has caused the Debian Bug report #1021668,
regarding xen: CVE-2022-33749 CVE-2022-33748 CVE-2022-33747 CVE-2022-33746
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner at bugs.debian.org
immediately.)


-- 
1021668: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021668
Debian Bug Tracking System
Contact owner at bugs.debian.org with problems
-------------- next part --------------
An embedded message was scrubbed...
From: =?UTF-8?Q?Moritz_M=C3=BChlenhoff?= <jmm at inutil.org>
Subject: xen: CVE-2022-33749 CVE-2022-33748 CVE-2022-33747 CVE-2022-33746
Date: Wed, 12 Oct 2022 19:38:17 +0200
Size: 4705
URL:
<http://alioth-lists.debian.net/pipermail/pkg-xen-devel/attachments/20221119/c343739e/attachment-0002.eml>
-------------- next part --------------
An embedded message was scrubbed...
From: Debian FTP Masters <ftpmaster at ftp-master.debian.org>
Subject: Bug#1021668: fixed in xen 4.14.5+86-g1c354767d5-1
Date: Sat, 19 Nov 2022 18:17:51 +0000
Size: 20792
URL:
<http://alioth-lists.debian.net/pipermail/pkg-xen-devel/attachments/20221119/c343739e/attachment-0003.eml>