[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Qemu-stable] [PULL 0/3] Cve 2015 5154 patches

From: Peter Lieven
Subject: Re: [Qemu-devel] [Qemu-stable] [PULL 0/3] Cve 2015 5154 patches
Date: Mon, 27 Jul 2015 16:05:00 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0

Am 27.07.2015 um 15:54 schrieb Kevin Wolf:
Am 27.07.2015 um 15:46 hat Peter Lieven geschrieben:
Am 27.07.2015 um 15:38 schrieb Kevin Wolf:

     Am 27.07.2015 um 15:25 hat Stefan Priebe - Profihost AG geschrieben:

         Am 27.07.2015 um 14:28 schrieb John Snow:

             On 07/27/2015 08:10 AM, Stefan Priebe - Profihost AG wrote:

                 Am 27.07.2015 um 14:01 schrieb John Snow:

                     The following changes since commit 

                       Merge remote-tracking branch 
'remotes/bonzini/tags/for-upstream' into staging (2015-07-24 13:07:10 +0100)

                     are available in the git repository at:


                 Any details on this CVE? Is RCE possible? Only if IDE is used?


             It's a heap overflow. The most likely outcome is a segfault, but 
             guest is allowed to continue writing past the end of the PIO 
buffer at
             its leisure. This makes it similar to CVE-2015-3456.

             This CVE can be mitigated unlike CVE-2015-3456 by just removing the
             CD-ROM drive until the patch can be applied.

         Thanks. The seclist article explicitly references xen. So it does not
         apply to qemu/kvm? Sorry for asking may be stupid questions.

     The IDE emulation is shared between Xen and KVM, so both are affected.
     The reason why the seclist mail only mentions Xen is probably because
     the Xen security team posted it.

     Meanwhile there is also a Red Hat CVE page available, which mentions
     qemu-kvm: https://access.redhat.com/security/cve/CVE-2015-5154

The redhat advisory says that some Redhat versions are not affected
"because they did not backport the upstream commit that introduced this issue

Can you point out which commit exactly introduced the issue?
That's the commit that introduced the code fixed in patch 2: Commit
ce560dcf ('ATAPI: STARTSTOPUNIT only eject/load media if powercondition
is 0').

Okay, so as far as I can see this is in any Qemu >= 1.3.0.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]