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

[Hans van Kranenburg]

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