From: Greg Kroah-Hartman Date: Sun, 22 Jul 2018 17:26:44 +0000 (+0200) Subject: 4.9-stable patches X-Git-Tag: v4.4.144~19 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=3a1d61183f5921aac21de84472d9c4e216b0fb2f;p=thirdparty%2Fkernel%2Fstable-queue.git 4.9-stable patches added patches: drm-i915-fix-hotplug-irq-ack-on-i965-g4x.patch mm-huge_memory.c-fix-data-loss-when-splitting-a-file-pmd.patch mm-memcg-fix-use-after-free-in-mem_cgroup_iter.patch vfio-pci-fix-potential-spectre-v1.patch --- diff --git a/queue-4.9/drm-i915-fix-hotplug-irq-ack-on-i965-g4x.patch b/queue-4.9/drm-i915-fix-hotplug-irq-ack-on-i965-g4x.patch new file mode 100644 index 00000000000..fde9a3ab010 --- /dev/null +++ b/queue-4.9/drm-i915-fix-hotplug-irq-ack-on-i965-g4x.patch @@ -0,0 +1,78 @@ +From 96a85cc517a9ee4ae5e8d7f5a36cba05023784eb Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= +Date: Thu, 14 Jun 2018 20:56:25 +0300 +Subject: drm/i915: Fix hotplug irq ack on i965/g4x +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Ville Syrjälä + +commit 96a85cc517a9ee4ae5e8d7f5a36cba05023784eb upstream. + +Just like with PIPESTAT, the edge triggered IIR on i965/g4x +also causes problems for hotplug interrupts. To make sure +we don't get the IIR port interrupt bit stuck low with the +ISR bit high we must force an edge in ISR. Unfortunately +we can't borrow the PIPESTAT trick and toggle the enable +bits in PORT_HOTPLUG_EN as that act itself generates hotplug +interrupts. Instead we just have to loop until we've cleared +PORT_HOTPLUG_STAT, or we just give up and WARN. + +v2: Don't frob with PORT_HOTPLUG_EN + +Cc: stable@vger.kernel.org +Signed-off-by: Ville Syrjälä +Link: https://patchwork.freedesktop.org/patch/msgid/20180614175625.1615-1-ville.syrjala@linux.intel.com +Reviewed-by: Imre Deak +(cherry picked from commit 0ba7c51a6fd80a89236f6ceb52e63f8a7f62bfd3) +Signed-off-by: Rodrigo Vivi +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/i915_irq.c | 32 ++++++++++++++++++++++++++++++-- + 1 file changed, 30 insertions(+), 2 deletions(-) + +--- a/drivers/gpu/drm/i915/i915_irq.c ++++ b/drivers/gpu/drm/i915/i915_irq.c +@@ -1684,10 +1684,38 @@ static void valleyview_pipestat_irq_hand + + static u32 i9xx_hpd_irq_ack(struct drm_i915_private *dev_priv) + { +- u32 hotplug_status = I915_READ(PORT_HOTPLUG_STAT); ++ u32 hotplug_status = 0, hotplug_status_mask; ++ int i; + +- if (hotplug_status) ++ if (IS_G4X(dev_priv) || ++ IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) ++ hotplug_status_mask = HOTPLUG_INT_STATUS_G4X | ++ DP_AUX_CHANNEL_MASK_INT_STATUS_G4X; ++ else ++ hotplug_status_mask = HOTPLUG_INT_STATUS_I915; ++ ++ /* ++ * We absolutely have to clear all the pending interrupt ++ * bits in PORT_HOTPLUG_STAT. Otherwise the ISR port ++ * interrupt bit won't have an edge, and the i965/g4x ++ * edge triggered IIR will not notice that an interrupt ++ * is still pending. We can't use PORT_HOTPLUG_EN to ++ * guarantee the edge as the act of toggling the enable ++ * bits can itself generate a new hotplug interrupt :( ++ */ ++ for (i = 0; i < 10; i++) { ++ u32 tmp = I915_READ(PORT_HOTPLUG_STAT) & hotplug_status_mask; ++ ++ if (tmp == 0) ++ return hotplug_status; ++ ++ hotplug_status |= tmp; + I915_WRITE(PORT_HOTPLUG_STAT, hotplug_status); ++ } ++ ++ WARN_ONCE(1, ++ "PORT_HOTPLUG_STAT did not clear (0x%08x)\n", ++ I915_READ(PORT_HOTPLUG_STAT)); + + return hotplug_status; + } diff --git a/queue-4.9/mm-huge_memory.c-fix-data-loss-when-splitting-a-file-pmd.patch b/queue-4.9/mm-huge_memory.c-fix-data-loss-when-splitting-a-file-pmd.patch new file mode 100644 index 00000000000..f62a7546416 --- /dev/null +++ b/queue-4.9/mm-huge_memory.c-fix-data-loss-when-splitting-a-file-pmd.patch @@ -0,0 +1,46 @@ +From e1f1b1572e8db87a56609fd05bef76f98f0e456a Mon Sep 17 00:00:00 2001 +From: Hugh Dickins +Date: Fri, 20 Jul 2018 17:53:45 -0700 +Subject: mm/huge_memory.c: fix data loss when splitting a file pmd + +From: Hugh Dickins + +commit e1f1b1572e8db87a56609fd05bef76f98f0e456a upstream. + +__split_huge_pmd_locked() must check if the cleared huge pmd was dirty, +and propagate that to PageDirty: otherwise, data may be lost when a huge +tmpfs page is modified then split then reclaimed. + +How has this taken so long to be noticed? Because there was no problem +when the huge page is written by a write system call (shmem_write_end() +calls set_page_dirty()), nor when the page is allocated for a write fault +(fault_dirty_shared_page() calls set_page_dirty()); but when allocated for +a read fault (which MAP_POPULATE simulates), no set_page_dirty(). + +Link: http://lkml.kernel.org/r/alpine.LSU.2.11.1807111741430.1106@eggly.anvils +Fixes: d21b9e57c74c ("thp: handle file pages in split_huge_pmd()") +Signed-off-by: Hugh Dickins +Reported-by: Ashwin Chaugule +Reviewed-by: Yang Shi +Reviewed-by: Kirill A. Shutemov +Cc: "Huang, Ying" +Cc: [4.8+] +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + mm/huge_memory.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/mm/huge_memory.c ++++ b/mm/huge_memory.c +@@ -1642,6 +1642,8 @@ static void __split_huge_pmd_locked(stru + if (vma_is_dax(vma)) + return; + page = pmd_page(_pmd); ++ if (!PageDirty(page) && pmd_dirty(_pmd)) ++ set_page_dirty(page); + if (!PageReferenced(page) && pmd_young(_pmd)) + SetPageReferenced(page); + page_remove_rmap(page, true); diff --git a/queue-4.9/mm-memcg-fix-use-after-free-in-mem_cgroup_iter.patch b/queue-4.9/mm-memcg-fix-use-after-free-in-mem_cgroup_iter.patch new file mode 100644 index 00000000000..eaa049f31a0 --- /dev/null +++ b/queue-4.9/mm-memcg-fix-use-after-free-in-mem_cgroup_iter.patch @@ -0,0 +1,64 @@ +From 9f15bde671355c351cf20d9f879004b234353100 Mon Sep 17 00:00:00 2001 +From: Jing Xia +Date: Fri, 20 Jul 2018 17:53:48 -0700 +Subject: mm: memcg: fix use after free in mem_cgroup_iter() + +From: Jing Xia + +commit 9f15bde671355c351cf20d9f879004b234353100 upstream. + +It was reported that a kernel crash happened in mem_cgroup_iter(), which +can be triggered if the legacy cgroup-v1 non-hierarchical mode is used. + +Unable to handle kernel paging request at virtual address 6b6b6b6b6b6b8f +...... +Call trace: + mem_cgroup_iter+0x2e0/0x6d4 + shrink_zone+0x8c/0x324 + balance_pgdat+0x450/0x640 + kswapd+0x130/0x4b8 + kthread+0xe8/0xfc + ret_from_fork+0x10/0x20 + + mem_cgroup_iter(): + ...... + if (css_tryget(css)) <-- crash here + break; + ...... + +The crashing reason is that mem_cgroup_iter() uses the memcg object whose +pointer is stored in iter->position, which has been freed before and +filled with POISON_FREE(0x6b). + +And the root cause of the use-after-free issue is that +invalidate_reclaim_iterators() fails to reset the value of iter->position +to NULL when the css of the memcg is released in non- hierarchical mode. + +Link: http://lkml.kernel.org/r/1531994807-25639-1-git-send-email-jing.xia@unisoc.com +Fixes: 6df38689e0e9 ("mm: memcontrol: fix possible memcg leak due to interrupted reclaim") +Signed-off-by: Jing Xia +Acked-by: Michal Hocko +Cc: Johannes Weiner +Cc: Vladimir Davydov +Cc: +Cc: Shakeel Butt +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + mm/memcontrol.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/mm/memcontrol.c ++++ b/mm/memcontrol.c +@@ -895,7 +895,7 @@ static void invalidate_reclaim_iterators + int nid; + int i; + +- while ((memcg = parent_mem_cgroup(memcg))) { ++ for (; memcg; memcg = parent_mem_cgroup(memcg)) { + for_each_node(nid) { + mz = mem_cgroup_nodeinfo(memcg, nid); + for (i = 0; i <= DEF_PRIORITY; i++) { diff --git a/queue-4.9/series b/queue-4.9/series index 0cf9d1fa8ca..5bf381914c7 100644 --- a/queue-4.9/series +++ b/queue-4.9/series @@ -6,3 +6,7 @@ alsa-rawmidi-change-resized-buffers-atomically.patch arc-fix-config_swap.patch arc-mm-allow-mprotect-to-make-stack-mappings-executable.patch arc-configs-remove-config_initramfs_source-from-defconfigs.patch +mm-memcg-fix-use-after-free-in-mem_cgroup_iter.patch +mm-huge_memory.c-fix-data-loss-when-splitting-a-file-pmd.patch +vfio-pci-fix-potential-spectre-v1.patch +drm-i915-fix-hotplug-irq-ack-on-i965-g4x.patch diff --git a/queue-4.9/vfio-pci-fix-potential-spectre-v1.patch b/queue-4.9/vfio-pci-fix-potential-spectre-v1.patch new file mode 100644 index 00000000000..f2406448227 --- /dev/null +++ b/queue-4.9/vfio-pci-fix-potential-spectre-v1.patch @@ -0,0 +1,55 @@ +From 0e714d27786ce1fb3efa9aac58abc096e68b1c2a Mon Sep 17 00:00:00 2001 +From: "Gustavo A. R. Silva" +Date: Tue, 17 Jul 2018 12:39:00 -0500 +Subject: vfio/pci: Fix potential Spectre v1 + +From: Gustavo A. R. Silva + +commit 0e714d27786ce1fb3efa9aac58abc096e68b1c2a upstream. + +info.index can be indirectly controlled by user-space, hence leading +to a potential exploitation of the Spectre variant 1 vulnerability. + +This issue was detected with the help of Smatch: + +drivers/vfio/pci/vfio_pci.c:734 vfio_pci_ioctl() +warn: potential spectre issue 'vdev->region' + +Fix this by sanitizing info.index before indirectly using it to index +vdev->region + +Notice that given that speculation windows are large, the policy is +to kill the speculation on the first load and not worry if it can be +completed with a dependent load/store [1]. + +[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2 + +Cc: stable@vger.kernel.org +Signed-off-by: Gustavo A. R. Silva +Signed-off-by: Alex Williamson +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/vfio/pci/vfio_pci.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/drivers/vfio/pci/vfio_pci.c ++++ b/drivers/vfio/pci/vfio_pci.c +@@ -28,6 +28,7 @@ + #include + #include + #include ++#include + + #include "vfio_pci_private.h" + +@@ -755,6 +756,9 @@ static long vfio_pci_ioctl(void *device_ + if (info.index >= + VFIO_PCI_NUM_REGIONS + vdev->num_regions) + return -EINVAL; ++ info.index = array_index_nospec(info.index, ++ VFIO_PCI_NUM_REGIONS + ++ vdev->num_regions); + + i = info.index - VFIO_PCI_NUM_REGIONS; +