[ANNOUNCE] QEMU 7.0.0-rc4 is now available

[ANNOUNCE] QEMU 7.0.0-rc4 is now available

[Michael Roth]

Hello,

On behalf of the QEMU Team, I'd like to announce the availability of the
fifth release candidate for the QEMU 7.0 release. This release is meant
for testing purposes and should not be used in a production environment.

  http://download.qemu-project.org/qemu-7.0.0-rc4.tar.xz
  http://download.qemu-project.org/qemu-7.0.0-rc4.tar.xz.sig

A note from the maintainer:

  rc4 contains three fixes for late-breaking security bugs. The plan
  is to make the final 7.0 release in a week's time on the 19th April,
  with no further changes, unless we discover some last-minute
  catastrophic problem.

You can help improve the quality of the QEMU 7.0 release by testing this
release and reporting bugs using our GitLab issue tracker:

  https://gitlab.com/qemu-project/qemu/-/issues

The release plan, as well a documented known issues for release
candidates, are available at:

  http://wiki.qemu.org/Planning/7.0

Please add entries to the ChangeLog for the 7.0 release below:

  http://wiki.qemu.org/ChangeLog/7.0

Thank you to everyone involved!

Changes since rc3:

81c7ed41a1: Update version for v7.0.0-rc4 release (Peter Maydell)
4bf58c7213: virtio-iommu: use-after-free fix (Wentao Liang)
fa892e9abb: ui/cursor: fix integer overflow in cursor_alloc (CVE-2021-4206) (Mauro Matteo Cascella)
9569f5cb5b: display/qxl-render: fix race condition in qxl_cursor (CVE-2021-4207) (Mauro Matteo Cascella)

Re: [ANNOUNCE] QEMU 7.0.0-rc4 is now available

[Stefan Weil]

Am 13.04.22 um 02:44 schrieb Michael Roth:
> A note from the maintainer:
> 
>    rc4 contains three fixes for late-breaking security bugs. The plan
>    is to make the final 7.0 release in a week's time on the 19th April,
>    with no further changes, unless we discover some last-minute
>    catastrophic problem.
> 
> You can help improve the quality of the QEMU 7.0 release by testing this
> release and reporting bugs using our GitLab issue tracker:

QEMU 7.0 seems to trigger an issue with makensis which is used for 
building the QEMU installer for Windows: it terminates with different 
kinds to errors (SIGBUS, SIGSEGV and mmap related errors) depending on 
the details of the build environment.

I currently think that this is related to the total size of the 
installed components which exceeds 2 GiB. Maybe a 32 bit int value is 
used somewhere in makensis.

A simple workaround is removing /SOLID in qemu.nsi, but that increases 
the size of the installer significantly.

Stripping the executables might also help to stay below the critical size.

I'm sorry that I missed sending patches to add qemu-storage-daemon.exe 
to qemu.nsi and for some format strings in calls of vu_panic. I don't 
think those are critical for the release.

Kind regards,
Stefan

Re: [ANNOUNCE] QEMU 7.0.0-rc4 is now available

[Peter Maydell]

On Mon, 18 Apr 2022 at 19:14, Stefan Weil <sw@weilnetz.de> wrote:
>
> Am 13.04.22 um 02:44 schrieb Michael Roth:
> > A note from the maintainer:
> >
> >    rc4 contains three fixes for late-breaking security bugs. The plan
> >    is to make the final 7.0 release in a week's time on the 19th April,
> >    with no further changes, unless we discover some last-minute
> >    catastrophic problem.
> >
> > You can help improve the quality of the QEMU 7.0 release by testing this
> > release and reporting bugs using our GitLab issue tracker:
>
> QEMU 7.0 seems to trigger an issue with makensis which is used for
> building the QEMU installer for Windows: it terminates with different
> kinds to errors (SIGBUS, SIGSEGV and mmap related errors) depending on
> the details of the build environment.

Unfortunately our CI doesn't notice this because although it
builds the installer it doesn't do it for an "all targets at
once" config, only for a couple of "some targets, not all" builds.

> I currently think that this is related to the total size of the
> installed components which exceeds 2 GiB. Maybe a 32 bit int value is
> used somewhere in makensis.

Searching around it does seem like there's a 2GB limit to
the installer, that's been known about for some years.
(There's a fork 'nsisbi' which raises it to 4GB.)

> Stripping the executables might also help to stay below the critical size.

That seems like it would be a good idea anyway -- does it
have any downsides ?

I think we probably can't really fix this for 7.0, unfortunately:
we found it too late.

thanks
-- PMM