diff -Nru libvirt-4.0.0/debian/changelog libvirt-4.0.0/debian/changelog --- libvirt-4.0.0/debian/changelog 2018-04-24 09:11:53.000000000 +0000 +++ libvirt-4.0.0/debian/changelog 2018-05-23 17:23:01.000000000 +0000 @@ -1,3 +1,27 @@ +libvirt (4.0.0-1ubuntu8.2) bionic-security; urgency=medium + + * SECURITY UPDATE: QEMU monitor DoS + - debian/patches/CVE-2018-1064.patch: add size limit to + src/qemu/qemu_agent.c. + - CVE-2018-1064 + * SECURITY UPDATE: Speculative Store Bypass + - debian/patches/CVE-2018-3639-1.patch: define the 'ssbd' CPUID feature + bit in src/cpu/cpu_map.xml. + - debian/patches/CVE-2018-3639-2.patch: define the 'virt-ssbd' CPUID + feature bit in src/cpu/cpu_map.xml. + - CVE-2018-3639 + + -- Marc Deslauriers Wed, 23 May 2018 13:23:01 -0400 + +libvirt (4.0.0-1ubuntu8.1) bionic; urgency=medium + + * Fix nwfilters that set CTRL_IP_LEARNING set to dhcp failing with "An error + occurred, but the cause is unknown" due to a buffer being too small + for pcap with TPACKET_V3 enabled (LP: #1758037) + - debian/patches/ubuntu/lp-1758037-nwfilter-increase-pcap-buffer-size.patch + + -- Christian Ehrhardt Fri, 11 May 2018 07:32:28 +0200 + libvirt (4.0.0-1ubuntu8) bionic; urgency=medium * Fix clean shut down of guests on system shutdown (LP: #1764668) diff -Nru libvirt-4.0.0/debian/patches/CVE-2018-1064.patch libvirt-4.0.0/debian/patches/CVE-2018-1064.patch --- libvirt-4.0.0/debian/patches/CVE-2018-1064.patch 1970-01-01 00:00:00.000000000 +0000 +++ libvirt-4.0.0/debian/patches/CVE-2018-1064.patch 2018-05-23 17:23:01.000000000 +0000 @@ -0,0 +1,59 @@ +From fbf31e1a4cd19d6f6e33e0937a009775cd7d9513 Mon Sep 17 00:00:00 2001 +From: =?utf8?q?Daniel=20P.=20Berrang=C3=A9?= +Date: Thu, 1 Mar 2018 14:55:26 +0000 +Subject: [PATCH] qemu: avoid denial of service reading from QEMU guest agent (CVE-2018-1064) +MIME-Version: 1.0 +Content-Type: text/plain; charset=utf8 +Content-Transfer-Encoding: 8bit + +We read from the agent until seeing a \r\n pair to indicate a completed +reply or event. To avoid memory denial-of-service though, we must have a +size limit on amount of data we buffer. 10 MB is large enough that it +ought to cope with normal agent replies, and small enough that we're not +consuming unreasonable mem. + +This is identical to the flaw we had reading from the QEMU monitor +as CVE-2018-5748, so rather embarrassing that we forgot to fix +the agent code at the same time. + +Signed-off-by: Daniel P. Berrangé +--- + src/qemu/qemu_agent.c | 15 +++++++++++++++ + 1 files changed, 15 insertions(+), 0 deletions(-) + +diff --git a/src/qemu/qemu_agent.c b/src/qemu/qemu_agent.c +index 0f36054..89183c3 100644 +--- a/src/qemu/qemu_agent.c ++++ b/src/qemu/qemu_agent.c +@@ -53,6 +53,15 @@ VIR_LOG_INIT("qemu.qemu_agent"); + #define DEBUG_IO 0 + #define DEBUG_RAW_IO 0 + ++/* We read from QEMU until seeing a \r\n pair to indicate a ++ * completed reply or event. To avoid memory denial-of-service ++ * though, we must have a size limit on amount of data we ++ * buffer. 10 MB is large enough that it ought to cope with ++ * normal QEMU replies, and small enough that we're not ++ * consuming unreasonable mem. ++ */ ++#define QEMU_AGENT_MAX_RESPONSE (10 * 1024 * 1024) ++ + /* When you are the first to uncomment this, + * don't forget to uncomment the corresponding + * part in qemuAgentIOProcessEvent as well. +@@ -535,6 +544,12 @@ qemuAgentIORead(qemuAgentPtr mon) + int ret = 0; + + if (avail < 1024) { ++ if (mon->bufferLength >= QEMU_AGENT_MAX_RESPONSE) { ++ virReportSystemError(ERANGE, ++ _("No complete agent response found in %d bytes"), ++ QEMU_AGENT_MAX_RESPONSE); ++ return -1; ++ } + if (VIR_REALLOC_N(mon->buffer, + mon->bufferLength + 1024) < 0) + return -1; +-- +1.7.1 + diff -Nru libvirt-4.0.0/debian/patches/CVE-2018-3639-1.patch libvirt-4.0.0/debian/patches/CVE-2018-3639-1.patch --- libvirt-4.0.0/debian/patches/CVE-2018-3639-1.patch 1970-01-01 00:00:00.000000000 +0000 +++ libvirt-4.0.0/debian/patches/CVE-2018-3639-1.patch 2018-05-23 17:22:54.000000000 +0000 @@ -0,0 +1,32 @@ +From 1dbca2eccad58d91a5fd33962854f1a653638182 Mon Sep 17 00:00:00 2001 +From: =?utf8?q?Daniel=20P.=20Berrang=C3=A9?= +Date: Mon, 21 May 2018 23:05:07 +0100 +Subject: [PATCH] cpu: define the 'ssbd' CPUID feature bit (CVE-2018-3639) +MIME-Version: 1.0 +Content-Type: text/plain; charset=utf8 +Content-Transfer-Encoding: 8bit + +New microcode introduces the "Speculative Store Bypass Disable" +CPUID feature bit. This needs to be exposed to guest OS to allow +them to protect against CVE-2018-3639. + +Signed-off-by: Daniel P. Berrangé +Reviewed-by: Jiri Denemark +--- + src/cpu/cpu_map.xml | 3 +++ + 1 files changed, 3 insertions(+), 0 deletions(-) + +Index: libvirt-4.0.0/src/cpu/cpu_map.xml +=================================================================== +--- libvirt-4.0.0.orig/src/cpu/cpu_map.xml 2018-05-22 10:55:47.275643722 -0400 ++++ libvirt-4.0.0/src/cpu/cpu_map.xml 2018-05-22 10:55:47.275643722 -0400 +@@ -295,6 +295,9 @@ + + + ++ ++ ++ + + + diff -Nru libvirt-4.0.0/debian/patches/CVE-2018-3639-2.patch libvirt-4.0.0/debian/patches/CVE-2018-3639-2.patch --- libvirt-4.0.0/debian/patches/CVE-2018-3639-2.patch 1970-01-01 00:00:00.000000000 +0000 +++ libvirt-4.0.0/debian/patches/CVE-2018-3639-2.patch 2018-05-23 17:22:58.000000000 +0000 @@ -0,0 +1,42 @@ +From 9267342206ce17f6933d57a3128cdc504d5945c9 Mon Sep 17 00:00:00 2001 +From: =?utf8?q?Daniel=20P.=20Berrang=C3=A9?= +Date: Mon, 21 May 2018 23:05:08 +0100 +Subject: [PATCH] cpu: define the 'virt-ssbd' CPUID feature bit (CVE-2018-3639) +MIME-Version: 1.0 +Content-Type: text/plain; charset=utf8 +Content-Transfer-Encoding: 8bit + +Some AMD processors only support a non-architectural means of +enabling Speculative Store Bypass Disable. To allow simplified +handling in virtual environments, hypervisors will expose an +architectural definition through CPUID bit 0x80000008_EBX[25]. +This needs to be exposed to guest OS running on AMD x86 hosts to +allow them to protect against CVE-2018-3639. + +Note that since this CPUID bit won't be present in the host CPUID +results on physical hosts, it will not be enabled automatically +in guests configured with "host-model" CPU unless using QEMU +version >= 2.9.0. Thus for older versions of QEMU, this feature +must be manually enabled using policy=force. Guests using the +"host-passthrough" CPU mode do not need special handling. + +Signed-off-by: Daniel P. Berrangé +Reviewed-by: Jiri Denemark +--- + src/cpu/cpu_map.xml | 3 +++ + 1 files changed, 3 insertions(+), 0 deletions(-) + +Index: libvirt-4.0.0/src/cpu/cpu_map.xml +=================================================================== +--- libvirt-4.0.0.orig/src/cpu/cpu_map.xml 2018-05-22 10:55:53.847652523 -0400 ++++ libvirt-4.0.0/src/cpu/cpu_map.xml 2018-05-22 10:55:53.843652518 -0400 +@@ -430,6 +430,9 @@ + + + ++ ++ ++ + + + diff -Nru libvirt-4.0.0/debian/patches/series libvirt-4.0.0/debian/patches/series --- libvirt-4.0.0/debian/patches/series 2018-04-24 09:12:35.000000000 +0000 +++ libvirt-4.0.0/debian/patches/series 2018-05-23 17:23:01.000000000 +0000 @@ -103,3 +103,7 @@ ubuntu/lp-1764668-fix-check_guests_shutdown-loop.patch ubuntu/lp-1764668-do-not-report-unknown-guests.patch +ubuntu/lp-1758037-nwfilter-increase-pcap-buffer-size.patch +CVE-2018-1064.patch +CVE-2018-3639-1.patch +CVE-2018-3639-2.patch diff -Nru libvirt-4.0.0/debian/patches/ubuntu/lp-1758037-nwfilter-increase-pcap-buffer-size.patch libvirt-4.0.0/debian/patches/ubuntu/lp-1758037-nwfilter-increase-pcap-buffer-size.patch --- libvirt-4.0.0/debian/patches/ubuntu/lp-1758037-nwfilter-increase-pcap-buffer-size.patch 1970-01-01 00:00:00.000000000 +0000 +++ libvirt-4.0.0/debian/patches/ubuntu/lp-1758037-nwfilter-increase-pcap-buffer-size.patch 2018-05-11 05:32:28.000000000 +0000 @@ -0,0 +1,113 @@ +From ce5aebeacd10a1c15cb3ee46a59c8b5ff235589e Mon Sep 17 00:00:00 2001 +From: Laine Stump +Date: Wed, 25 Apr 2018 17:12:03 -0400 +Subject: [PATCH] nwfilter: increase pcap buffer size to be compatible with + TPACKET_V3 + +When an nwfilter rule sets the parameter CTRL_IP_LEARNING to "dhcp", +this turns on the "dhcpsnoop" thread, which uses libpcap to monitor +traffic on the domain's tap device and extract the IP address from the +DHCP response. + +If libpcap on the host is built with HAVE_TPACKET3 defined (to enable +support for TPACKET_V3), the dhcpsnoop code's initialization of the +libpcap socket would fail with the following error: + + virNWFilterSnoopDHCPOpen:1134 : internal error: pcap_setfilter: can't remove kernel filter: Bad file descriptor + +It turns out that this was because TPACKET_V3 requires a larger buffer +size than libvirt was setting (we were setting it to 128k). Changing +the buffer size to 256k eliminates the error, and the dhcpsnoop thread +once again works properly. + +A fuller explanation of why TPACKET_V3 requires such a large buffer, +for future git spelunkers: + +libpcap calls setsockopt(... SOL_PACKET, PACKET_RX_RING...) to setup a +ring buffer for receiving packets; two of the attributes sent to this +API are called tp_frame_size, and tp_frame_nr. If libpcap was built +with HAVE_TPACKET3 defined, tp_trame_size is set to MAXIMUM_SNAPLEN +(defined in libpcap sources as 262144) and tp_frame_nr is set to: + + [the buffer size we set, i.e. PCAP_BUFFERSIZE i.e. 262144] / tp_frame_size. + +So if PCAP_BUFFERSIZE < MAXIMUM_SNAPLEN, then tp_frame_nr (the number +of frames in the ring buffer) is 0, which is nonsensical. This same +value is later used as a multiplier to determine the size for a call +to malloc() (which would also fail). + +(NB: if HAVE_TPACKET3 is *not* defined, then tp_frame_size is set to +the snaplen set by the user (in our case 576) plus a small amount to +account for ethernet headers, so 256k is far more than adequate) + +Since the TPACKET_V3 code in libpcap actually reads multiple packets +into each frame, it's not a problem to have only a single frame +(especially when we are monitoring such infrequent traffic), so it's +okay to set this relatively small buffer size (in comparison to the +default, which is 2MB), which is important since every guest using +dhcp snooping in a nwfilter rule will hold 2 of these buffers for the +entire life of the guest. + +Thanks to Christian Ehrhardt for discovering that buffer size was the +problem (this was not at all obvious from the error that was logged!) + +Resolves: https://bugzilla.redhat.com/1547237 +Fixes: https://bugs.launchpad.net/libvirt/+bug/1758037 + +Signed-off-by: Laine Stump +Reviewed-by: Christian Ehrhardt (V1) +Reviewed-by: John Ferlan +Tested-by: Christian Ehrhardt + +Forwarded: no (backport) +Origin: upstream, https://libvirt.org/git/?p=libvirt.git;a=commit;h=ce5aebeacd10a1c15cb3ee46a59c8b5ff235589e +Bug-Ubuntu: https://bugs.launchpad.net/bugs/1758037 +Last-Update: 2018-05-09 +--- + src/nwfilter/nwfilter_dhcpsnoop.c | 22 +++++++++++++++++++--- + 1 file changed, 19 insertions(+), 3 deletions(-) + +diff --git a/src/nwfilter/nwfilter_dhcpsnoop.c b/src/nwfilter/nwfilter_dhcpsnoop.c +index 6069e70460..50cfb944a2 100644 +--- a/src/nwfilter/nwfilter_dhcpsnoop.c ++++ b/src/nwfilter/nwfilter_dhcpsnoop.c +@@ -256,10 +256,21 @@ struct _virNWFilterDHCPDecodeJob { + # define DHCP_BURST_INTERVAL_S 10 /* sec */ + + /* +- * libpcap 1.5 requires a 128kb buffer +- * 128 kb is bigger than (DHCP_PKT_BURST * PCAP_PBUFSIZE / 2) ++ * NB: Any libpcap built with HAVE_TPACKET3 will require ++ * PCAP_BUFFERSIZE to be at least 262144 (although ++ * pcap_set_buffer_size() with a lower value will succeed, and the ++ * error will only show up later when pcap_setfilter() is called). ++ * ++ * It is possible that in the future libpcap could increase the ++ * minimum size even further, but due to the fact that each guest ++ * using dhcp snooping keeps 2 pcap sockets open (and thus 2 buffers ++ * allocated) for the life of the guest, we want to minimize the ++ * length of the buffer, so instead of leaving it at the default size ++ * (2MB), we are setting it to the minimum viable size and including ++ * this clue in the source to help quickly resolve the problem when/if ++ * it reoccurs. + */ +-# define PCAP_BUFFERSIZE (128 * 1024) ++# define PCAP_BUFFERSIZE (256 * 1024) + + # define MAX_QUEUED_JOBS (DHCP_PKT_BURST + 2 * DHCP_PKT_RATE) + +@@ -1114,6 +1125,11 @@ virNWFilterSnoopDHCPOpen(const char *ifname, virMacAddr *mac, + goto cleanup_nohandle; + } + ++ /* IMPORTANT: If there is any failure of *any* pcap_* function ++ * during setup of the socket, look to the comment where ++ * PCAP_BUFFERSIZE is defined. It may be too small, even if the ++ * generated error doesn't imply that. ++ */ + if (pcap_set_snaplen(handle, PCAP_PBUFSIZE) < 0 || + pcap_set_buffer_size(handle, PCAP_BUFFERSIZE) < 0 || + pcap_activate(handle) < 0) { +-- +2.17.0 +