Linux v4.19.7

2018-12-05 16:42:59 -05:00 · 2018-12-05 16:42:59 -05:00 · cf820f7d92
commit cf820f7d92
parent e556318046
6 changed files with 5 additions and 312 deletions
--- a/CVE-2018-19407.patch
+++ b/CVE-2018-19407.patch
@ -1,104 +0,0 @@
-From: Wanpeng Li <kernellwp@gmail.com>
-Date: Tue, 27 Nov 2018 14:01:04 -0500
-Subject: [PATCH] KVM: X86: Fix scan ioapic use-before-initialization
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-Reported by syzkaller:
-
- BUG: unable to handle kernel NULL pointer dereference at 00000000000001c8
- PGD 80000003ec4da067 P4D 80000003ec4da067 PUD 3f7bfa067 PMD 0
- Oops: 0000 [#1] PREEMPT SMP PTI
- CPU: 7 PID: 5059 Comm: debug Tainted: G           OE     4.19.0-rc5 #16
- RIP: 0010:__lock_acquire+0x1a6/0x1990
- Call Trace:
-  lock_acquire+0xdb/0x210
-  _raw_spin_lock+0x38/0x70
-  kvm_ioapic_scan_entry+0x3e/0x110 [kvm]
-  vcpu_enter_guest+0x167e/0x1910 [kvm]
-  kvm_arch_vcpu_ioctl_run+0x35c/0x610 [kvm]
-  kvm_vcpu_ioctl+0x3e9/0x6d0 [kvm]
-  do_vfs_ioctl+0xa5/0x690
-  ksys_ioctl+0x6d/0x80
-  __x64_sys_ioctl+0x1a/0x20
-  do_syscall_64+0x83/0x6e0
-  entry_SYSCALL_64_after_hwframe+0x49/0xbe
-
-The reason is that the testcase writes hyperv synic HV_X64_MSR_SINT6 msr
-and triggers scan ioapic logic to load synic vectors into EOI exit bitmap.
-However, irqchip is not initialized by this simple testcase, ioapic/apic
-objects should not be accessed.
-This can be triggered by the following program:
-
-    #define _GNU_SOURCE
-
-    #include <endian.h>
-    #include <stdint.h>
-    #include <stdio.h>
-    #include <stdlib.h>
-    #include <string.h>
-    #include <sys/syscall.h>
-    #include <sys/types.h>
-    #include <unistd.h>
-
-    uint64_t r[3] = {0xffffffffffffffff, 0xffffffffffffffff, 0xffffffffffffffff};
-
-    int main(void)
-    {
-    	syscall(__NR_mmap, 0x20000000, 0x1000000, 3, 0x32, -1, 0);
-    	long res = 0;
-    	memcpy((void*)0x20000040, "/dev/kvm", 9);
-    	res = syscall(__NR_openat, 0xffffffffffffff9c, 0x20000040, 0, 0);
-    	if (res != -1)
-    		r[0] = res;
-    	res = syscall(__NR_ioctl, r[0], 0xae01, 0);
-    	if (res != -1)
-    		r[1] = res;
-    	res = syscall(__NR_ioctl, r[1], 0xae41, 0);
-    	if (res != -1)
-    		r[2] = res;
-    	memcpy(
-    			(void*)0x20000080,
-    			"\x01\x00\x00\x00\x00\x5b\x61\xbb\x96\x00\x00\x40\x00\x00\x00\x00\x01\x00"
-    			"\x08\x00\x00\x00\x00\x00\x0b\x77\xd1\x78\x4d\xd8\x3a\xed\xb1\x5c\x2e\x43"
-    			"\xaa\x43\x39\xd6\xff\xf5\xf0\xa8\x98\xf2\x3e\x37\x29\x89\xde\x88\xc6\x33"
-    			"\xfc\x2a\xdb\xb7\xe1\x4c\xac\x28\x61\x7b\x9c\xa9\xbc\x0d\xa0\x63\xfe\xfe"
-    			"\xe8\x75\xde\xdd\x19\x38\xdc\x34\xf5\xec\x05\xfd\xeb\x5d\xed\x2e\xaf\x22"
-    			"\xfa\xab\xb7\xe4\x42\x67\xd0\xaf\x06\x1c\x6a\x35\x67\x10\x55\xcb",
-    			106);
-    	syscall(__NR_ioctl, r[2], 0x4008ae89, 0x20000080);
-    	syscall(__NR_ioctl, r[2], 0xae80, 0);
-    	return 0;
-    }
-
-This patch fixes it by bailing out scan ioapic if ioapic is not initialized in
-kernel.
-
-Reported-by: Wei Wu <ww9210@gmail.com>
-Cc: Paolo Bonzini <pbonzini@redhat.com>
-Cc: Radim Krčmář <rkrcmar@redhat.com>
-Cc: Wei Wu <ww9210@gmail.com>
-Signed-off-by: Wanpeng Li <wanpengli@tencent.com>
-Signed-off-by: Jeremy Cline <jcline@redhat.com>
---
- arch/x86/kvm/x86.c | 3 ++-
- 1 file changed, 2 insertions(+), 1 deletion(-)
-
-diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
-index ca717737347e..89694cbf84cf 100644
--- a/arch/x86/kvm/x86.c
-+++ b/arch/x86/kvm/x86.c
-@@ -7313,7 +7313,8 @@ static void vcpu_scan_ioapic(struct kvm_vcpu *vcpu)
- 	else {
- 		if (vcpu->arch.apicv_active)
- 			kvm_x86_ops->sync_pir_to_irr(vcpu);
-		kvm_ioapic_scan_entry(vcpu, vcpu->arch.ioapic_handled_vectors);
-+		if (ioapic_in_kernel(vcpu->kvm))
-+			kvm_ioapic_scan_entry(vcpu, vcpu->arch.ioapic_handled_vectors);
- 	}
- 
- 	if (is_guest_mode(vcpu))
-- 
-2.19.1
-
--- a/PCI-Fix-incorrect-value-returned-from-pcie_get_speed.patch
+++ b/PCI-Fix-incorrect-value-returned-from-pcie_get_speed.patch
@ -1,81 +0,0 @@
-From b8f56153d6d66e01e52f9f703ab0c6f8c8637354 Mon Sep 17 00:00:00 2001
-From: Mikulas Patocka <mpatocka@redhat.com>
-Date: Thu, 29 Nov 2018 17:24:17 -0600
-Subject: [PATCH] PCI: Fix incorrect value returned from pcie_get_speed_cap()
-
-The macros PCI_EXP_LNKCAP_SLS_*GB are values, not bit masks.  We must mask
-the register and compare it against them.
-
-This fixes errors like this:
-
-  amdgpu: [powerplay] failed to send message 261 ret is 0
-
-when a PCIe-v3 card is plugged into a PCIe-v1 slot, because the slot is
-being incorrectly reported as PCIe-v3 capable.
-
-6cf57be0f78e, which appeared in v4.17, added pcie_get_speed_cap() with the
-incorrect test of PCI_EXP_LNKCAP_SLS as a bitmask.  5d9a63304032, which
-appeared in v4.19, changed amdgpu to use pcie_get_speed_cap(), so the
-amdgpu bug reports below are regressions in v4.19.
-
-Fixes: 6cf57be0f78e ("PCI: Add pcie_get_speed_cap() to find max supported link speed")
-Fixes: 5d9a63304032 ("drm/amdgpu: use pcie functions for link width and speed")
-Link: https://bugs.freedesktop.org/show_bug.cgi?id=108704
-Link: https://bugs.freedesktop.org/show_bug.cgi?id=108778
-Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
-[bhelgaas: update comment, remove use of PCI_EXP_LNKCAP_SLS_8_0GB and
-PCI_EXP_LNKCAP_SLS_16_0GB since those should be covered by PCI_EXP_LNKCAP2,
-remove test of PCI_EXP_LNKCAP for zero, since that register is required]
-Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
-Acked-by: Alex Deucher <alexander.deucher@amd.com>
-Cc: stable@vger.kernel.org	# v4.17+
-Signed-off-by: Jeremy Cline <jcline@redhat.com>
---
- drivers/pci/pci.c | 24 +++++++++++-------------
- 1 file changed, 11 insertions(+), 13 deletions(-)
-
-diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
-index d068f11d08a7..c9d8e3c837de 100644
--- a/drivers/pci/pci.c
-+++ b/drivers/pci/pci.c
-@@ -5556,9 +5556,13 @@ enum pci_bus_speed pcie_get_speed_cap(struct pci_dev *dev)
- 	u32 lnkcap2, lnkcap;
- 
- 	/*
-	 * PCIe r4.0 sec 7.5.3.18 recommends using the Supported Link
-	 * Speeds Vector in Link Capabilities 2 when supported, falling
-	 * back to Max Link Speed in Link Capabilities otherwise.
-+	 * Link Capabilities 2 was added in PCIe r3.0, sec 7.8.18.  The
-+	 * implementation note there recommends using the Supported Link
-+	 * Speeds Vector in Link Capabilities 2 when supported.
-+	 *
-+	 * Without Link Capabilities 2, i.e., prior to PCIe r3.0, software
-+	 * should use the Supported Link Speeds field in Link Capabilities,
-+	 * where only 2.5 GT/s and 5.0 GT/s speeds were defined.
- 	 */
- 	pcie_capability_read_dword(dev, PCI_EXP_LNKCAP2, &lnkcap2);
- 	if (lnkcap2) { /* PCIe r3.0-compliant */
-@@ -5574,16 +5578,10 @@ enum pci_bus_speed pcie_get_speed_cap(struct pci_dev *dev)
- 	}
- 
- 	pcie_capability_read_dword(dev, PCI_EXP_LNKCAP, &lnkcap);
-	if (lnkcap) {
-		if (lnkcap & PCI_EXP_LNKCAP_SLS_16_0GB)
-			return PCIE_SPEED_16_0GT;
-		else if (lnkcap & PCI_EXP_LNKCAP_SLS_8_0GB)
-			return PCIE_SPEED_8_0GT;
-		else if (lnkcap & PCI_EXP_LNKCAP_SLS_5_0GB)
-			return PCIE_SPEED_5_0GT;
-		else if (lnkcap & PCI_EXP_LNKCAP_SLS_2_5GB)
-			return PCIE_SPEED_2_5GT;
-	}
-+	if ((lnkcap & PCI_EXP_LNKCAP_SLS) == PCI_EXP_LNKCAP_SLS_5_0GB)
-+		return PCIE_SPEED_5_0GT;
-+	else if ((lnkcap & PCI_EXP_LNKCAP_SLS) == PCI_EXP_LNKCAP_SLS_2_5GB)
-+		return PCIE_SPEED_2_5GT;
- 
- 	return PCI_SPEED_UNKNOWN;
- }
-- 
-2.19.2
-
--- a/kernel.spec
+++ b/kernel.spec
@ -54,7 +54,7 @@ Summary: The Linux kernel
 %if 0%{?released_kernel}

 # Do we have a -stable update to apply?
-%define stable_update 6
+%define stable_update 7
 # Set rpm version accordingly
 %if 0%{?stable_update}
 %define stablerev %{stable_update}
@ -632,19 +632,6 @@ Patch510: iio-accel-kxcjk1013-Add-more-hardware-ids.patch
 # rhbz 1650224, patch in subsystem tree and Cc'd for stable
 Patch511: drm-set-is_master-to-0-upon-drm_new_set_master-failure.patch

-# CVE-2018-16862 (rhbz 1649017 1653122)
-Patch512: mm-cleancache-fix-corruption-on-missed-inode-invalidation.patch
-
-# CVE-2018-19407 (rhbz 1652656 1652658)
-Patch513: CVE-2018-19407.patch
-
-# rhbz 1650984, in linux-next and Cc'd for stable
-Patch514: net-phy-add-workaround-for-issue-where-PHY-driver-do.patch
-
-# In the PCI tree and Cc'd for stable, fixes an issue with amdgpu
-# https://patchwork.freedesktop.org/patch/259364/
-Patch515: PCI-Fix-incorrect-value-returned-from-pcie_get_speed.patch
-
 # rhbz 1645070 patch queued upstream for merging into 4.21
 Patch516: asus-fx503-keyb.patch

@ -1918,6 +1905,9 @@ fi
 #
 #
 %changelog
+* Wed Dec 05 2018 Jeremy Cline <jcline@redhat.com> - 4.19.7-300
+- Linux v4.19.7
+
 * Wed Dec 05 2018 Jeremy Cline <jeremy@jcline.org>
 - Fix corruption bug in direct dispatch for blk-mq

--- a/mm-cleancache-fix-corruption-on-missed-inode-invalidation.patch
+++ b/mm-cleancache-fix-corruption-on-missed-inode-invalidation.patch
@ -1,59 +0,0 @@
-From: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
-Subject: mm: cleancache: fix corruption on missed inode invalidation
-
-If all pages are deleted from the mapping by memory reclaim and also
-moved to the cleancache:
-
-__delete_from_page_cache
-  (no shadow case)
-  unaccount_page_cache_page
-    cleancache_put_page
-  page_cache_delete
-    mapping->nrpages -= nr
-    (nrpages becomes 0)
-
-We don't clean the cleancache for an inode after final file truncation
-(removal).
-
-truncate_inode_pages_final
-  check (nrpages || nrexceptional) is false
-    no truncate_inode_pages
-      no cleancache_invalidate_inode(mapping)
-
-These way when reading the new file created with same inode we may get
-these trash leftover pages from cleancache and see wrong data instead of
-the contents of the new file.
-
-Fix it by always doing truncate_inode_pages which is already ready for
-nrpages == 0 && nrexceptional == 0 case and just invalidates inode.
-
-Link: http://lkml.kernel.org/r/20181112095734.17979-1-ptikhomirov@virtuozzo.com
-Fixes: commit 91b0abe36a7b ("mm + fs: store shadow entries in page cache")
-Signed-off-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
-Reviewed-by: Vasily Averin <vvs@virtuozzo.com>
-Reviewed-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
-Reviewed-by: Jan Kara <jack@suse.cz>
-Cc: Johannes Weiner <hannes@cmpxchg.org>
-Cc: Mel Gorman <mgorman@techsingularity.net>
-Cc: Matthew Wilcox <willy@infradead.org>
-Cc: Andi Kleen <ak@linux.intel.com>
-Cc: <stable@vger.kernel.org>
-Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
-
-
--- a/mm/truncate.c~mm-cleancache-fix-corruption-on-missed-inode-invalidation
-+++ a/mm/truncate.c
-@@ -517,9 +517,9 @@ void truncate_inode_pages_final(struct a
- 		 */
- 		xa_lock_irq(&mapping->i_pages);
- 		xa_unlock_irq(&mapping->i_pages);
-
-		truncate_inode_pages(mapping, 0);
- 	}
-+
-+	truncate_inode_pages(mapping, 0);
- }
- EXPORT_SYMBOL(truncate_inode_pages_final);
- 
-_
--- a/net-phy-add-workaround-for-issue-where-PHY-driver-do.patch
+++ b/net-phy-add-workaround-for-issue-where-PHY-driver-do.patch
@ -1,53 +0,0 @@
-From c85ddecae6e5e82ca3ae6f20c63f1d865e2ff5ea Mon Sep 17 00:00:00 2001
-From: Heiner Kallweit <hkallweit1@gmail.com>
-Date: Fri, 23 Nov 2018 19:41:29 +0100
-Subject: [PATCH] net: phy: add workaround for issue where PHY driver doesn't
- bind to the device
-
-After switching the r8169 driver to use phylib some user reported that
-their network is broken. This was caused by the genphy PHY driver being
-used instead of the dedicated PHY driver for the RTL8211B. Users
-reported that loading the Realtek PHY driver module upfront fixes the
-issue. See also this mail thread:
-https://marc.info/?t=154279781800003&r=1&w=2
-The issue is quite weird and the root cause seems to be somewhere in
-the base driver core. The patch works around the issue and may be
-removed once the actual issue is fixed.
-
-The Fixes tag refers to the first reported occurrence of the issue.
-The issue itself may have been existing much longer and it may affect
-users of other network chips as well. Users typically will recognize
-this issue only if their PHY stops working when being used with the
-genphy driver.
-
-Fixes: f1e911d5d0df ("r8169: add basic phylib support")
-Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
-Reviewed-by: Andrew Lunn <andrew@lunn.ch>
-Signed-off-by: David S. Miller <davem@davemloft.net>
-Signed-off-by: Jeremy Cline <jcline@redhat.com>
---
- drivers/net/phy/phy_device.c | 8 ++++++++
- 1 file changed, 8 insertions(+)
-
-diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
-index ab33d1777132..23ee3967c166 100644
--- a/drivers/net/phy/phy_device.c
-+++ b/drivers/net/phy/phy_device.c
-@@ -2197,6 +2197,14 @@ int phy_driver_register(struct phy_driver *new_driver, struct module *owner)
- 	new_driver->mdiodrv.driver.remove = phy_remove;
- 	new_driver->mdiodrv.driver.owner = owner;
- 
-+	/* The following works around an issue where the PHY driver doesn't bind
-+	 * to the device, resulting in the genphy driver being used instead of
-+	 * the dedicated driver. The root cause of the issue isn't known yet
-+	 * and seems to be in the base driver core. Once this is fixed we may
-+	 * remove this workaround.
-+	 */
-+	new_driver->mdiodrv.driver.probe_type = PROBE_FORCE_SYNCHRONOUS;
-+
- 	retval = driver_register(&new_driver->mdiodrv.driver);
- 	if (retval) {
- 		pr_err("%s: Error %d in registering driver\n",
-- 
-2.19.2
-
--- a/2
+++ b/2
@ -1,2 +1,2 @@
 SHA512 (linux-4.19.tar.xz) = ab67cc746b375a8b135e8b23e35e1d6787930d19b3c26b2679787d62951cbdbc3bb66f8ededeb9b890e5008b2459397f9018f1a6772fdef67780b06a4cb9f6f4
-SHA512 (patch-4.19.6.xz) = dc1f723c9b2882fe368eac4b8c6e255450f05bb1742f9a0e078200a6f700ee47e8d9e254206d5f2f1386446690f2df943deb564bf922597e46be5c1a63bd1ba9
+SHA512 (patch-4.19.7.xz) = e27fdf83e5ae71f4eb2e49660877107d032e9bd51aafff99a1861a5cb18c3e6006164ffb11faf5cdaf0fa3a8afc0c1ab34abb0855d0858730ffb49261ad5b0ed