qemu/qemu.git, branch stable-3.0

Update version for 3.0.1 release

2019-04-12T03:27:39+00:00

Signed-off-by: Michael Roth

vhost-user: Fix userfaultfd leak

2019-04-08T21:50:20+00:00

'fd' received from the vhost side is never freed. Also, everything (including 'postcopy_listen' state) should be cleaned up on vhost cleanup. Fixes: 46343570c06e ("vhost+postcopy: Wire up POSTCOPY_END notify") Fixes: f82c11165ffa ("vhost+postcopy: Register shared ufd with postcopy") Cc: qemu-stable@nongnu.org Signed-off-by: Ilya Maximets Message-Id: <20181008160536.6332-3-i.maximets@samsung.com> Reviewed-by: Dr. David Alan Gilbert Reviewed-by: Maxime Coquelin Signed-off-by: Dr. David Alan Gilbert (cherry picked from commit c4f753859ae6da1aeb93cad19c586fea1925e269) Signed-off-by: Michael Roth

vhost-user: Don't ask for reply on postcopy mem table set

2019-04-08T21:47:37+00:00

According to documentation, NEED_REPLY_MASK should not be set for VHOST_USER_SET_MEM_TABLE request in postcopy mode. This restriction was mistakenly applied to 'reply_supported' variable, which is local and used only for non-postcopy case. CC: Dr. David Alan Gilbert Fixes: 9bb38019942c ("vhost+postcopy: Send address back to qemu") Signed-off-by: Ilya Maximets Message-Id: <20181002140947.4107-1-i.maximets@samsung.com> Reviewed-by: Maxime Coquelin Signed-off-by: Dr. David Alan Gilbert (cherry picked from commit 5ce43896e1679e706db1562d0e2d86ad428ed1e6) Signed-off-by: Michael Roth

ppc/pnv: check size before data buffer access

2019-04-02T18:17:03+00:00

While performing PowerNV memory r/w operations, the access length 'sz' could exceed the data[4] buffer size. Add check to avoid OOB access. Reported-by: Moguofang Signed-off-by: Prasad J Pandit Reviewed-by: Cédric Le Goater Signed-off-by: David Gibson (cherry picked from commit d07945e78eb6b593cd17a4640c1fc9eb35e3245d) *CVE-2018-18954 Signed-off-by: Michael Roth

slirp: check data length while emulating ident function

2019-04-02T18:16:34+00:00

While emulating identification protocol, tcp_emu() does not check available space in the 'sc_rcv->sb_data' buffer. It could lead to heap buffer overflow issue. Add check to avoid it. Reported-by: Kira <864786842@qq.com> Signed-off-by: Prasad J Pandit Signed-off-by: Samuel Thibault (cherry picked from commit a7104eda7dab99d0cdbd3595c211864cba415905) *CVE-2019-6778 Signed-off-by: Michael Roth

lsi53c895a: check message length value is valid

2019-04-02T18:15:18+00:00

While writing a message in 'lsi_do_msgin', message length value in 'msg_len' could be invalid due to an invalid migration stream. Add an assertion to avoid an out of bounds access, and reject the incoming migration data if it contains an invalid message length. Discovered by Deja vu Security. Reported by Oracle. Signed-off-by: Prasad J Pandit Message-Id: <20181026194314.18663-1-ppandit@redhat.com> Signed-off-by: Paolo Bonzini (cherry picked from commit e58ccf039650065a9442de43c9816f81e88f27f6) *CVE-2018-18849 *avoid context dep. on c921370b22c Signed-off-by: Michael Roth

seccomp: set the seccomp filter to all threads

2019-04-02T18:11:49+00:00

When using "-seccomp on", the seccomp policy is only applied to the main thread, the vcpu worker thread and other worker threads created after seccomp policy is applied; the seccomp policy is not applied to e.g. the RCU thread because it is created before the seccomp policy is applied and SECCOMP_FILTER_FLAG_TSYNC isn't used. This can be verified with for task in /proc/`pidof qemu`/task/*; do cat $task/status | grep Secc ; done Seccomp: 2 Seccomp: 0 Seccomp: 0 Seccomp: 2 Seccomp: 2 Seccomp: 2 Starting with libseccomp 2.2.0 and kernel >= 3.17, we can use seccomp_attr_set(ctx, > SCMP_FLTATR_CTL_TSYNC, 1) to update the policy on all threads. libseccomp requirement was bumped to 2.2.0 in previous patch. libseccomp should fail to set the filter if it can't honour SCMP_FLTATR_CTL_TSYNC (untested), and thus -sandbox will now fail on kernel < 3.17. Signed-off-by: Marc-André Lureau Acked-by: Eduardo Otubo (cherry picked from commit 70dfabeaa79ba4d7a3b699abe1a047c8012db114) *CVE-2018-15746 Signed-off-by: Michael Roth

configure: require libseccomp 2.2.0

2019-04-02T18:11:31+00:00

The following patch is going to require TSYNC, which is only available since libseccomp 2.2.0. libseccomp 2.2.0 was released February 12, 2015. According to repology, libseccomp version in different distros: RHEL-7: 2.3.1 Debian (Stretch): 2.3.1 OpenSUSE Leap 15: 2.3.2 Ubuntu (Xenial): 2.3.1 This will drop support for -sandbox on: Debian (Jessie): 2.1.1 (but 2.2.3 in backports) Signed-off-by: Marc-André Lureau Acked-by: Eduardo Otubo (cherry picked from commit d0699bd37c48067cffbd80383172efc29da6d2f9) *CVE-2018-15746 Signed-off-by: Michael Roth

seccomp: prefer SCMP_ACT_KILL_PROCESS if available

2019-04-02T18:11:03+00:00

The upcoming libseccomp release should have SCMP_ACT_KILL_PROCESS action (https://github.com/seccomp/libseccomp/issues/96). SCMP_ACT_KILL_PROCESS is preferable to immediately terminate the offending process, rather than having the SIGSYS handler running. Use SECCOMP_GET_ACTION_AVAIL to check availability of kernel support, as libseccomp will fallback on SCMP_ACT_KILL otherwise, and we still prefer SCMP_ACT_TRAP. Signed-off-by: Marc-André Lureau Reviewed-by: Daniel P. Berrangé Acked-by: Eduardo Otubo (cherry picked from commit bda08a5764d470f101fa38635d30b41179a313e1) *CVE-2018-15746 Signed-off-by: Michael Roth

seccomp: use SIGSYS signal instead of killing the thread

2019-04-02T18:10:37+00:00

The seccomp action SCMP_ACT_KILL results in immediate termination of the thread that made the bad system call. However, qemu being multi-threaded, it keeps running. There is no easy way for parent process / management layer (libvirt) to know about that situation. Instead, the default SIGSYS handler when invoked with SCMP_ACT_TRAP will terminate the program and core dump. This may not be the most secure solution, but probably better than just killing the offending thread. SCMP_ACT_KILL_PROCESS has been added in Linux 4.14 to improve the situation, which I propose to use by default if available in the next patch. Related to: https://bugzilla.redhat.com/show_bug.cgi?id=1594456 Signed-off-by: Marc-André Lureau Reviewed-by: Daniel P. Berrangé Acked-by: Eduardo Otubo (cherry picked from commit 6f2231e9b0931e1998d9ed0c509adf7aedc02db2) *CVE-2018-15746 Signed-off-by: Michael Roth