Bug#1062044: qemu 7.2+dfsg-7+deb12u4 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1062044 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==============

Package: qemu
Version: 7.2+dfsg-7+deb12u4

Explanation: new upstream stable release; irtio-net: correctly copy vnet header when flushing TX [CVE-2023-6693]; fix null pointer dereference issue [CVE-2023-6683]

[Michael Tokarev]

01.02.2024 11:40, Adam D Barratt :
..

> Package: qemu
> Version: 7.2+dfsg-7+deb12u4
>
> Explanation: new upstream stable release; irtio-net: correctly copy vnet header when flushing TX [CVE-2023-6693]; fix null pointer dereference issue [CVE-2023-6683]

There's a typo here, should be virtio-net.

I'm aware of the autopkgtest failure with cryptsetup, working on it now.

It looks like we broke suspend/resume in this version of qemu.

Thanks,

/mjt

[Adam D. Barratt]

On Sat, 2024-02-03 at 11:40 +0300, Michael Tokarev wrote:
> 01.02.2024 11:40, Adam D Barratt :
> ..
> > Package: qemu
> > Version: 7.2+dfsg-7+deb12u4
> >
> > Explanation: new upstream stable release; irtio-net: correctly copy
> > vnet header when flushing TX [CVE-2023-6693]; fix null pointer
> > dereference issue [CVE-2023-6683]
>
> There's a typo here, should be virtio-net.

Oops, copy-n-paste fail; fixed.

>
> I'm aware of the autopkgtest failure with cryptsetup, working on it
> now.
>

OK, thanks.

> It looks like we broke suspend/resume in this version of qemu.

Oops. Is that related to the cryptsetup failure, or a separate issue?

Regards,

Adam

[Michael Tokarev]

03.02.2024 12:43, Adam D. Barratt :
..

>> I'm aware of the autopkgtest failure with cryptsetup, working on it
>> now.

>> It looks like we broke suspend/resume in this version of qemu.
>
> Oops. Is that related to the cryptsetup failure, or a separate issue?

Yes, it is related to cryptsetup autopkgtest failure. It looks
like this is the only place where suspend/resume code in qemu
is actually being used, - it's rather rare to suspend (hybernate)
a virtual machine, and cryptsetup performs testing of how the
encrypted filesystem is unlocked (or not) on resume.

I already found the upstream commit which broke this (in all
supported versions of upstream qemu, including master), dunno
yet what to do with it, - trying to reduce the cryptroot test
to some manageable minimum.

It'd be sad to avoid updating of qemu due to this. But let's
see..

Thanks,

/mjt

[Adam D. Barratt]

Thanks for the update, and for being proactive.

Regards,

Adam

[Michael Tokarev]

03.02.2024 12:47, Michael Tokarev wrote:

>>> It looks like we broke suspend/resume in this version of qemu.
>> Oops. Is that related to the cryptsetup failure, or a separate issue?
>
> Yes, it is related to cryptsetup autopkgtest failure.  It looks
> like this is the only place where suspend/resume code in qemu
> is actually being used, - it's rather rare to suspend (hybernate)
> a virtual machine, and cryptsetup performs testing of how the
> encrypted filesystem is unlocked (or not) on resume.

So, while the problematic upstream commit fixes quite a few real
potential qemu lockups, it introduces a new lockup in suspend-
resume-hibernate cycle. The problem isn't understood yet, and
we're getting close to the 12.5 release.

The problematic upstream commit (on master) is this one:
https://gitlab.com/qemu-project/qemu/-/commit/effd60c878176bcaf97fa7ce2b12d04bb8ead6f7
It has links to 2 bugs it is fixing, and there are quite a few
other bugs which are fixed too.

I can add a revert of this single commit (with all tests) for debian
stable (for deb12u5 release) on top of current deb12u4. I think
this would be best, despite the way it goes, - first the change is
added in v7.2.9.diff, and next removed in a followup revert, -
because this way we follow upstream releases, and this patch
will be easy to remove in subsequent update.

Alternatively we probably can ignore cryptsetup autopkgtest
failure, but this smells somewhat wrong, I think it's better
to restore the status quo for now, even in such a weird way
(applying and reverting a patch).

What do you think?

Sure thing, if the solution will be found in a couple of days,
I'll try to push that one instead, but it also depends on the
complexity and possible risks there, and timeline.

Thanks,

/mjt

[Adam D. Barratt]

On Tue, 2024-02-06 at 19:37 +0300, Michael Tokarev wrote:
> e problematic upstream commit (on master) is this one:
> https://gitlab.com/qemu-project/qemu/-/commit/effd60c878176bcaf97fa7ce2b12d04bb8ead6f7
> It has links to 2 bugs it is fixing, and there are quite a few
> other bugs which are fixed too.
>
> I can add a revert of this single commit (with all tests) for debian
> stable (for deb12u5 release) on top of current deb12u4.  I think
> this would be best, despite the way it goes, - first the change is
> added in v7.2.9.diff, and next removed in a followup revert, -
> because this way we follow upstream releases, and this patch
> will be easy to remove in subsequent update.

[...]

> re thing, if the solution will be found in a couple of days,
> I'll try to push that one instead, but it also depends on the
> complexity and possible risks there, and timeline.

Technically we already froze p-u for 12.5 on Sunday evening, as
previously announced. If you could get an upload just fixing that
single issue with a small change uploaded today then I'd be tempted to
accept it anyway.

Presumably the bugs being fixed by that commit already exist in
bookworm's qemu, so not including the commit isn't a regression?

Please also attach a debdiff against the previous upload.

Regards,

Adam

[Adam D. Barratt]

On Tue, 2024-02-06 at 20:49 +0300, Michael Tokarev wrote:
> 06.02.2024 20:33, Adam D. Barratt:

> > On Tue, 2024-02-06 at 19:37 +0300, Michael Tokarev wrote:
> > > problematic upstream commit (on master) is this one:
> > > https://gitlab.com/qemu-project/qemu/-/commit/effd60c878176bcaf97fa7ce2b12d04bb8ead6f7
>

> > Technically we already froze p-u for 12.5 on Sunday evening, as
> > previously announced. If you could get an upload just fixing that
> > single issue with a small change uploaded today then I'd be tempted
> > to
> > accept it anyway.
>

> Oh. I knew we're getting late, but not *that* late.
>

The point release(s) are on Saturday, and we always freeze a week
beforehand.

> The change isn't small per se, as the commit is rather large (mostly
> due to many changed tests, - it changes order of output in quite some
> places).  Here's the diffstat:
>
>   monitor/qmp.c                         |   17 +++++++++++++++++
>   qapi/qmp-dispatch.c                   |   24 +---------------------
> --

This is the relevant bit for size IMO. If you're happy with the result
then please upload as soon as you're ready.

Regards,

Adam

[Michael Tokarev]

06.02.2024 20:55, Adam D. Barratt :

> On Tue, 2024-02-06 at 20:49 +0300, Michael Tokarev wrote:

..

>> The change isn't small per se, as the commit is rather large (mostly
>> due to many changed tests, - it changes order of output in quite some
>> places).  Here's the diffstat:
>>
>>   monitor/qmp.c                         |   17 +++++++++++++++++
>>   qapi/qmp-dispatch.c                   |   24 +---------------------
>> --
>
> This is the relevant bit for size IMO. If you're happy with the result
> then please upload as soon as you're ready.

Yes, I'm happy with the result. Well, - as much as one can be happy here,
choosing between one bug or another, - but it is at least a status-quo and
we don't have known regressions in debian stable due to this.

I just re-ran upstream testsuite just to be extra sure, and am running my
bunch of guests as well, everything works as expected so far. I wont try
to reproduce the issues this patch (which I'm reverting) fixed, though ;)

Uploaded +deb12u5 now, waiting to be picked up.

Thank you for the patience and all the work!

/mjt