Your message dated Fri, 03 Jul 2020 15:49:29 +0000
with message-id <[email protected]>
and subject line Bug#961887: fixed in qemu 1:5.0-6
has caused the Debian Bug report #961887,
regarding qemu: CVE-2020-13362
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 [email protected]
immediately.)


-- 
961887: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961887
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Source: qemu
Version: 1:5.0-5
Severity: important
Tags: security upstream
Forwarded: https://lists.gnu.org/archive/html/qemu-devel/2020-05/msg03463.html

Hi,

The following vulnerability was published for qemu.

CVE-2020-13362[0]:
| In QEMU 4.2.0, megasas_lookup_frame in hw/scsi/megasas.c has an out-
| of-bounds read via a crafted reply_queue_head field from a guest OS
| user.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-13362
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13362
[1] https://lists.gnu.org/archive/html/qemu-devel/2020-05/msg03463.html

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

--- End Message ---
--- Begin Message ---
Source: qemu
Source-Version: 1:5.0-6
Done: Michael Tokarev <[email protected]>

We believe that the bug you reported is fixed in the latest version of
qemu, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to [email protected],
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Michael Tokarev <[email protected]> (supplier of updated qemu package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing [email protected])


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Fri, 03 Jul 2020 18:24:48 +0300
Source: qemu
Architecture: source
Version: 1:5.0-6
Distribution: unstable
Urgency: medium
Maintainer: Debian QEMU Team <[email protected]>
Changed-By: Michael Tokarev <[email protected]>
Closes: 961887
Changes:
 qemu (1:5.0-6) unstable; urgency=medium
 .
   [ Christian Ehrhardt ]
   * d/control-in: disable pmem on ppc64 as it is currently considered
     experimental on that architecture
   * d/rules: makefile definitions can't be recursive - sys_systems for s390x
   * d/rules: report config log from the correct subdir - base build
   * d/rules: report config log from the correct subdir - microvm build
   * d/control-in: disable rbd support unavailable on riscv
   * fix assert in qemu guest agent that crashes on shutdown (LP: #1878973)
   * d/control-in: build-dep libcap is no more needed
   * d/rules: update -spice compat (Ubuntu only)
 .
   [ Michael Tokarev ]
   * save block modules on upgrades (LP: #1847361)
     After upgrade a still running qemu of a former version can't load the
     new modules e.g. for extended storage support. Qemu 5.0 has the code to
     allow defining a path that it will load these modules from.
   * ati-vga-check-mm_index-before-recursive-call-CVE-2020-13800.patch
     Closes: CVE-2020-13800, ati-vga allows guest OS users to trigger
     infinite recursion via a crafted mm_index value during
     ati_mm_read or ati_mm_write call.
   * 
revert-memory-accept-mismatching-sizes-in-memory_region_access_valid...patch
     Closes: CVE-2020-13754, possible OOB memory accesses in a bunch of qemu
     devices which uses min_access_size and max_access_size Memory API fields.
     Also closes: CVE-2020-13791
   * exec-set-map-length-to-zero-when-returning-NULL-CVE-2020-13659.patch
     CVE-2020-13659: address_space_map in exec.c can trigger
     a NULL pointer dereference related to BounceBuffer
   * megasas-use-unsigned-type-for-reply_queue_head-and-check-index...patch
     Closes: #961887, CVE-2020-13362, megasas_lookup_frame in hw/scsi/megasas.c
     has an OOB read via a crafted reply_queue_head field from a guest OS user
   * megasas-use-unsigned-type-for-positive-numeric-fields.patch
     fix other possible cases like in CVE-2020-13362 (#961887)
   * megasas-fix-possible-out-of-bounds-array-access.patch
     Some tracepoints use a guest-controlled value as an index into the
     mfi_frame_desc[] array. Thus a malicious guest could cause a very low
     impact OOB errors here
   * nbd-server-avoid-long-error-message-assertions-CVE-2020-10761.patch
     Closes: CVE-2020-10761, An assertion failure issue in the QEMU NBD Server.
     This flaw occurs when an nbd-client sends a spec-compliant request that is
     near the boundary of maximum permitted request length. A remote nbd-client
     could use this flaw to crash the qemu-nbd server resulting in a DoS.
   * es1370-check-total-frame-count-against-current-frame-CVE-2020-13361.patch
     Closes: CVE-2020-13361, es1370_transfer_audio in hw/audio/es1370.c does not
     properly validate the frame count, which allows guest OS users to trigger
     an out-of-bounds access during an es1370_write() operation
   * 
sdcard-dont-switch-to-ReceivingData-if-address-is-in...-CVE-2020-13253.patch
     CVE-2020-13253: sd_wp_addr in hw/sd/sd.c in QEMU 4.2.0 uses an unvalidated
     address, which leads to an out-of-bounds read during sdhci_write()
     operations.  A guest OS user can crash the QEMU process.
     And a preparational patch,
     sdcard-update-coding-style-to-make-checkpatch-happy.patch
   * a few patches from the stable series:
     - fix-tulip-breakage.patch
       The tulip network driver in a qemu-system-hppa emulation is broken in
       the sense that bigger network packages aren't received any longer and
       thus even running e.g. "apt update" inside the VM fails. Fix this.
     - 9p-lock-directory-streams-with-a-CoMutex.patch
       Prevent deadlocks in 9pfs readdir code
     - net-do-not-include-a-newline-in-the-id-of-nic-device.patch
       Fix newline accidentally sneaked into id string of a nic
     - qemu-nbd-close-inherited-stderr.patch
     - virtio-balloon-fix-free-page-hinting-check-on-unreal.patch
     - virtio-balloon-fix-free-page-hinting-without-an-iothread.patch
     - virtio-balloon-unref-the-iothread-when-unrealizing.patch
 .
   [ Aurelien Jarno ]
   * Remove myself from maintainers
Checksums-Sha1:
 3efc1ed326059f3e36b81453bd9d4e6fba513bf6 6720 qemu_5.0-6.dsc
 7e1c42acdb5cfe1230b51c30f217123744cf6f98 102620 qemu_5.0-6.debian.tar.xz
 c76add30bfde5efff98b24c8ddb1f0f8f928bbf5 9226 qemu_5.0-6_source.buildinfo
Checksums-Sha256:
 758a10ef8bee0bb1c568865de9be2549cb20968cc7ece36c87259a3523ae210c 6720 
qemu_5.0-6.dsc
 cf1b230efb9167f167e9f6fc2ce923570d8d219633a50b2dd97027607e100ab3 102620 
qemu_5.0-6.debian.tar.xz
 31020e20e837590c8d24249741c4d9ef9ca22803235e0f003bde9c07a1a56d52 9226 
qemu_5.0-6_source.buildinfo
Files:
 47a7bd3c2a0f3619a6cedd89f0192359 6720 otherosfs optional qemu_5.0-6.dsc
 6d6495224f90b82919d0fc4ce7e0884c 102620 otherosfs optional 
qemu_5.0-6.debian.tar.xz
 52ce44ba6abf9d0d7eb20bada52851dc 9226 otherosfs optional 
qemu_5.0-6_source.buildinfo

-----BEGIN PGP SIGNATURE-----

iQFDBAEBCAAtFiEEe3O61ovnosKJMUsicBtPaxppPlkFAl7/TfIPHG1qdEB0bHMu
bXNrLnJ1AAoJEHAbT2saaT5ZrOQH/0r6ZpkyyFUI+VWc74WMJ/zeU3dF+newaua6
j81za0wDhNErEX1zctzzHfN4OrIF13olM0RajnmYJ4Ai/HxLXcXUsc5b4vRyQ56Q
YrcJyA9300S8TrcV2CDyFUo4R6aOSD8xFOG8xbritqQOIFfyLykNoOBFUGDjEZ6q
n5yrAxVf+4LxnkbJV+TMuisS/k8/psyaInYSUimnkEBdSPtJroZRLZiH6h+ufroi
F+lWrFrjjVl83us+ZnxR2d3/1Lr0ik7qeF2GptUA5jvf3kgPKfp/8EcMcnZPW7eM
jXN4Yg8zdd0N8CfchrYRLqip712MBvEPjEyVEnwVYSj9DGqHJb8=
=KXfv
-----END PGP SIGNATURE-----

--- End Message ---

Reply via email to