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

[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 
> f793d97e454a56d17e404004867985622ca1a63b:
> 
>                       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:
> 
>                       https://github.com/jnsnow/qemu.git 
> tags/cve-2015-5154-pull-request
> 
>                 Any details on this CVE? Is RCE possible? Only if IDE is used?
> 
>                 Stefan
> 
> 
>             It's a heap overflow. The most likely outcome is a segfault, but 
> the
>             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').

Kevin