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

[Salvatore Bonaccorso]

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