From 6f74d819650126a25566ae68b741e974a132d48b Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Mon, 1 Jun 2020 13:34:48 +0200 Subject: [PATCH] 4.9-stable patches added patches: mac80211-mesh-fix-discovery-timer-re-arming-issue-crash.patch parisc-fix-kernel-panic-in-mem_init.patch x86-dma-fix-max-pfn-arithmetic-overflow-on-32-bit-systems.patch --- ...ence-count-leak-in-iommu_group_alloc.patch | 9 +- ...iscovery-timer-re-arming-issue-crash.patch | 165 ++++++++++++++++++ .../parisc-fix-kernel-panic-in-mem_init.patch | 49 ++++++ queue-4.9/series | 3 + ...rithmetic-overflow-on-32-bit-systems.patch | 108 ++++++++++++ 5 files changed, 327 insertions(+), 7 deletions(-) create mode 100644 queue-4.9/mac80211-mesh-fix-discovery-timer-re-arming-issue-crash.patch create mode 100644 queue-4.9/parisc-fix-kernel-panic-in-mem_init.patch create mode 100644 queue-4.9/x86-dma-fix-max-pfn-arithmetic-overflow-on-32-bit-systems.patch diff --git a/queue-4.9/iommu-fix-reference-count-leak-in-iommu_group_alloc.patch b/queue-4.9/iommu-fix-reference-count-leak-in-iommu_group_alloc.patch index 8e9cffb181a..f4f5da993b7 100644 --- a/queue-4.9/iommu-fix-reference-count-leak-in-iommu_group_alloc.patch +++ b/queue-4.9/iommu-fix-reference-count-leak-in-iommu_group_alloc.patch @@ -17,14 +17,12 @@ Link: https://lore.kernel.org/r/20200527210020.6522-1-wu000273@umn.edu Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin --- - drivers/iommu/iommu.c | 2 +- + drivers/iommu/iommu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c -index dbcc13efaf3c..d609e14bb904 100644 --- a/drivers/iommu/iommu.c +++ b/drivers/iommu/iommu.c -@@ -195,7 +195,7 @@ struct iommu_group *iommu_group_alloc(void) +@@ -195,7 +195,7 @@ struct iommu_group *iommu_group_alloc(vo NULL, "%d", group->id); if (ret) { ida_simple_remove(&iommu_group_ida, group->id); @@ -33,6 +31,3 @@ index dbcc13efaf3c..d609e14bb904 100644 return ERR_PTR(ret); } --- -2.25.1 - diff --git a/queue-4.9/mac80211-mesh-fix-discovery-timer-re-arming-issue-crash.patch b/queue-4.9/mac80211-mesh-fix-discovery-timer-re-arming-issue-crash.patch new file mode 100644 index 00000000000..a66f7ed185a --- /dev/null +++ b/queue-4.9/mac80211-mesh-fix-discovery-timer-re-arming-issue-crash.patch @@ -0,0 +1,165 @@ +From e2d4a80f93fcfaf72e2e20daf6a28e39c3b90677 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Linus=20L=C3=BCssing?= +Date: Fri, 22 May 2020 19:04:13 +0200 +Subject: mac80211: mesh: fix discovery timer re-arming issue / crash +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Linus Lüssing + +commit e2d4a80f93fcfaf72e2e20daf6a28e39c3b90677 upstream. + +On a non-forwarding 802.11s link between two fairly busy +neighboring nodes (iperf with -P 16 at ~850MBit/s TCP; +1733.3 MBit/s VHT-MCS 9 80MHz short GI VHT-NSS 4), so with +frequent PREQ retries, usually after around 30-40 seconds the +following crash would occur: + +[ 1110.822428] Unable to handle kernel read from unreadable memory at virtual address 00000000 +[ 1110.830786] Mem abort info: +[ 1110.833573] Exception class = IABT (current EL), IL = 32 bits +[ 1110.839494] SET = 0, FnV = 0 +[ 1110.842546] EA = 0, S1PTW = 0 +[ 1110.845678] user pgtable: 4k pages, 48-bit VAs, pgd = ffff800076386000 +[ 1110.852204] [0000000000000000] *pgd=00000000f6322003, *pud=00000000f62de003, *pmd=0000000000000000 +[ 1110.861167] Internal error: Oops: 86000004 [#1] PREEMPT SMP +[ 1110.866730] Modules linked in: pppoe ppp_async batman_adv ath10k_pci ath10k_core ath pppox ppp_generic nf_conntrack_ipv6 mac80211 iptable_nat ipt_REJECT ipt_MASQUERADE cfg80211 xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_FLOWOFFLOAD slhc nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_conntrack_ipv4 nf_nat_ipv4 nf_nat nf_log_ipv4 nf_flow_table_hw nf_flow_table nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack iptable_mangle iptable_filter ip_tables crc_ccitt compat nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 usb_storage xhci_plat_hcd xhci_pci xhci_hcd dwc3 usbcore usb_common +[ 1110.932190] Process swapper/3 (pid: 0, stack limit = 0xffff0000090c8000) +[ 1110.938884] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.14.162 #0 +[ 1110.944965] Hardware name: LS1043A RGW Board (DT) +[ 1110.949658] task: ffff8000787a81c0 task.stack: ffff0000090c8000 +[ 1110.955568] PC is at 0x0 +[ 1110.958097] LR is at call_timer_fn.isra.27+0x24/0x78 +[ 1110.963055] pc : [<0000000000000000>] lr : [] pstate: 00400145 +[ 1110.970440] sp : ffff00000801be10 +[ 1110.973744] x29: ffff00000801be10 x28: ffff000008bf7018 +[ 1110.979047] x27: ffff000008bf87c8 x26: ffff000008c160c0 +[ 1110.984352] x25: 0000000000000000 x24: 0000000000000000 +[ 1110.989657] x23: dead000000000200 x22: 0000000000000000 +[ 1110.994959] x21: 0000000000000000 x20: 0000000000000101 +[ 1111.000262] x19: ffff8000787a81c0 x18: 0000000000000000 +[ 1111.005565] x17: ffff0000089167b0 x16: 0000000000000058 +[ 1111.010868] x15: ffff0000089167b0 x14: 0000000000000000 +[ 1111.016172] x13: ffff000008916788 x12: 0000000000000040 +[ 1111.021475] x11: ffff80007fda9af0 x10: 0000000000000001 +[ 1111.026777] x9 : ffff00000801bea0 x8 : 0000000000000004 +[ 1111.032080] x7 : 0000000000000000 x6 : ffff80007fda9aa8 +[ 1111.037383] x5 : ffff00000801bea0 x4 : 0000000000000010 +[ 1111.042685] x3 : ffff00000801be98 x2 : 0000000000000614 +[ 1111.047988] x1 : 0000000000000000 x0 : 0000000000000000 +[ 1111.053290] Call trace: +[ 1111.055728] Exception stack(0xffff00000801bcd0 to 0xffff00000801be10) +[ 1111.062158] bcc0: 0000000000000000 0000000000000000 +[ 1111.069978] bce0: 0000000000000614 ffff00000801be98 0000000000000010 ffff00000801bea0 +[ 1111.077798] bd00: ffff80007fda9aa8 0000000000000000 0000000000000004 ffff00000801bea0 +[ 1111.085618] bd20: 0000000000000001 ffff80007fda9af0 0000000000000040 ffff000008916788 +[ 1111.093437] bd40: 0000000000000000 ffff0000089167b0 0000000000000058 ffff0000089167b0 +[ 1111.101256] bd60: 0000000000000000 ffff8000787a81c0 0000000000000101 0000000000000000 +[ 1111.109075] bd80: 0000000000000000 dead000000000200 0000000000000000 0000000000000000 +[ 1111.116895] bda0: ffff000008c160c0 ffff000008bf87c8 ffff000008bf7018 ffff00000801be10 +[ 1111.124715] bdc0: ffff0000080ff29c ffff00000801be10 0000000000000000 0000000000400145 +[ 1111.132534] bde0: ffff8000787a81c0 ffff00000801bde8 0000ffffffffffff 000001029eb19be8 +[ 1111.140353] be00: ffff00000801be10 0000000000000000 +[ 1111.145220] [< (null)>] (null) +[ 1111.149917] [] run_timer_softirq+0x184/0x398 +[ 1111.155741] [] __do_softirq+0x100/0x1fc +[ 1111.161130] [] irq_exit+0x80/0xd8 +[ 1111.166002] [] __handle_domain_irq+0x88/0xb0 +[ 1111.171825] [] gic_handle_irq+0x68/0xb0 +[ 1111.177213] Exception stack(0xffff0000090cbe30 to 0xffff0000090cbf70) +[ 1111.183642] be20: 0000000000000020 0000000000000000 +[ 1111.191461] be40: 0000000000000001 0000000000000000 00008000771af000 0000000000000000 +[ 1111.199281] be60: ffff000008c95180 0000000000000000 ffff000008c19360 ffff0000090cbef0 +[ 1111.207101] be80: 0000000000000810 0000000000000400 0000000000000098 ffff000000000000 +[ 1111.214920] bea0: 0000000000000001 ffff0000089167b0 0000000000000000 ffff0000089167b0 +[ 1111.222740] bec0: 0000000000000000 ffff000008c198e8 ffff000008bf7018 ffff000008c19000 +[ 1111.230559] bee0: 0000000000000000 0000000000000000 ffff8000787a81c0 ffff000008018000 +[ 1111.238380] bf00: ffff00000801c000 ffff00000913ba34 ffff8000787a81c0 ffff0000090cbf70 +[ 1111.246199] bf20: ffff0000080857cc ffff0000090cbf70 ffff0000080857d0 0000000000400145 +[ 1111.254020] bf40: ffff000008018000 ffff00000801c000 ffffffffffffffff ffff0000080fa574 +[ 1111.261838] bf60: ffff0000090cbf70 ffff0000080857d0 +[ 1111.266706] [] el1_irq+0xe8/0x18c +[ 1111.271576] [] arch_cpu_idle+0x10/0x18 +[ 1111.276880] [] do_idle+0xec/0x1b8 +[ 1111.281748] [] cpu_startup_entry+0x20/0x28 +[ 1111.287399] [] secondary_start_kernel+0x104/0x110 +[ 1111.293662] Code: bad PC value +[ 1111.296710] ---[ end trace 555b6ca4363c3edd ]--- +[ 1111.301318] Kernel panic - not syncing: Fatal exception in interrupt +[ 1111.307661] SMP: stopping secondary CPUs +[ 1111.311574] Kernel Offset: disabled +[ 1111.315053] CPU features: 0x0002000 +[ 1111.318530] Memory Limit: none +[ 1111.321575] Rebooting in 3 seconds.. + +With some added debug output / delays we were able to push the crash from +the timer callback runner into the callback function and by that shedding +some light on which object holding the timer gets corrupted: + +[ 401.720899] Unable to handle kernel read from unreadable memory at virtual address 00000868 +[...] +[ 402.335836] [] _raw_spin_lock_bh+0x14/0x48 +[ 402.341548] [] mesh_path_timer+0x10c/0x248 [mac80211] +[ 402.348154] [] call_timer_fn.isra.27+0x24/0x78 +[ 402.354150] [] run_timer_softirq+0x184/0x398 +[ 402.359974] [] __do_softirq+0x100/0x1fc +[ 402.365362] [] irq_exit+0x80/0xd8 +[ 402.370231] [] __handle_domain_irq+0x88/0xb0 +[ 402.376053] [] gic_handle_irq+0x68/0xb0 + +The issue happens due to the following sequence of events: + +1) mesh_path_start_discovery(): +-> spin_unlock_bh(&mpath->state_lock) before mesh_path_sel_frame_tx() + +2) mesh_path_free_rcu() +-> del_timer_sync(&mpath->timer) + [...] +-> kfree_rcu(mpath) + +3) mesh_path_start_discovery(): +-> mod_timer(&mpath->timer, ...) + [...] +-> rcu_read_unlock() + +4) mesh_path_free_rcu()'s kfree_rcu(): +-> kfree(mpath) + +5) mesh_path_timer() starts after timeout, using freed mpath object + +So a use-after-free issue due to a timer re-arming bug caused by an +early spin-unlocking. + +This patch fixes this issue by re-checking if mpath is about to be +free'd and if so bails out of re-arming the timer. + +Cc: stable@vger.kernel.org +Fixes: 050ac52cbe1f ("mac80211: code for on-demand Hybrid Wireless Mesh Protocol") +Cc: Simon Wunderlich +Signed-off-by: Linus Lüssing +Link: https://lore.kernel.org/r/20200522170413.14973-1-linus.luessing@c0d3.blue +Signed-off-by: Johannes Berg +Signed-off-by: Greg Kroah-Hartman + +--- + net/mac80211/mesh_hwmp.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +--- a/net/mac80211/mesh_hwmp.c ++++ b/net/mac80211/mesh_hwmp.c +@@ -1082,7 +1082,14 @@ void mesh_path_start_discovery(struct ie + mesh_path_sel_frame_tx(MPATH_PREQ, 0, sdata->vif.addr, ifmsh->sn, + target_flags, mpath->dst, mpath->sn, da, 0, + ttl, lifetime, 0, ifmsh->preq_id++, sdata); ++ ++ spin_lock_bh(&mpath->state_lock); ++ if (mpath->flags & MESH_PATH_DELETED) { ++ spin_unlock_bh(&mpath->state_lock); ++ goto enddiscovery; ++ } + mod_timer(&mpath->timer, jiffies + mpath->discovery_timeout); ++ spin_unlock_bh(&mpath->state_lock); + + enddiscovery: + rcu_read_unlock(); diff --git a/queue-4.9/parisc-fix-kernel-panic-in-mem_init.patch b/queue-4.9/parisc-fix-kernel-panic-in-mem_init.patch new file mode 100644 index 00000000000..eec8421b91c --- /dev/null +++ b/queue-4.9/parisc-fix-kernel-panic-in-mem_init.patch @@ -0,0 +1,49 @@ +From bf71bc16e02162388808949b179d59d0b571b965 Mon Sep 17 00:00:00 2001 +From: Helge Deller +Date: Thu, 28 May 2020 22:29:25 +0200 +Subject: parisc: Fix kernel panic in mem_init() + +From: Helge Deller + +commit bf71bc16e02162388808949b179d59d0b571b965 upstream. + +The Debian kernel v5.6 triggers this kernel panic: + + Kernel panic - not syncing: Bad Address (null pointer deref?) + Bad Address (null pointer deref?): Code=26 (Data memory access rights trap) at addr 0000000000000000 + CPU: 0 PID: 0 Comm: swapper Not tainted 5.6.0-2-parisc64 #1 Debian 5.6.14-1 + IAOQ[0]: mem_init+0xb0/0x150 + IAOQ[1]: mem_init+0xb4/0x150 + RP(r2): start_kernel+0x6c8/0x1190 + Backtrace: + [<0000000040101ab4>] start_kernel+0x6c8/0x1190 + [<0000000040108574>] start_parisc+0x158/0x1b8 + +on a HP-PARISC rp3440 machine with this memory layout: + Memory Ranges: + 0) Start 0x0000000000000000 End 0x000000003fffffff Size 1024 MB + 1) Start 0x0000004040000000 End 0x00000040ffdfffff Size 3070 MB + +Fix the crash by avoiding virt_to_page() and similar functions in +mem_init() until the memory zones have been fully set up. + +Signed-off-by: Helge Deller +Cc: stable@vger.kernel.org # v5.0+ +Signed-off-by: Greg Kroah-Hartman + + +--- + arch/parisc/mm/init.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/parisc/mm/init.c ++++ b/arch/parisc/mm/init.c +@@ -604,7 +604,7 @@ void __init mem_init(void) + > BITS_PER_LONG); + + high_memory = __va((max_pfn << PAGE_SHIFT)); +- set_max_mapnr(page_to_pfn(virt_to_page(high_memory - 1)) + 1); ++ set_max_mapnr(max_low_pfn); + free_all_bootmem(); + + #ifdef CONFIG_PA11 diff --git a/queue-4.9/series b/queue-4.9/series index 39833c678c5..bf955dcc9c2 100644 --- a/queue-4.9/series +++ b/queue-4.9/series @@ -39,3 +39,6 @@ mm-remove-vm_bug_on-pageslab-from-page_mapcount.patch fs-binfmt_elf.c-allocate-initialized-memory-in-fill_.patch include-asm-generic-topology.h-guard-cpumask_of_node.patch iommu-fix-reference-count-leak-in-iommu_group_alloc.patch +parisc-fix-kernel-panic-in-mem_init.patch +mac80211-mesh-fix-discovery-timer-re-arming-issue-crash.patch +x86-dma-fix-max-pfn-arithmetic-overflow-on-32-bit-systems.patch diff --git a/queue-4.9/x86-dma-fix-max-pfn-arithmetic-overflow-on-32-bit-systems.patch b/queue-4.9/x86-dma-fix-max-pfn-arithmetic-overflow-on-32-bit-systems.patch new file mode 100644 index 00000000000..19161694f60 --- /dev/null +++ b/queue-4.9/x86-dma-fix-max-pfn-arithmetic-overflow-on-32-bit-systems.patch @@ -0,0 +1,108 @@ +From 88743470668ef5eb6b7ba9e0f99888e5999bf172 Mon Sep 17 00:00:00 2001 +From: Alexander Dahl +Date: Tue, 26 May 2020 19:57:49 +0200 +Subject: x86/dma: Fix max PFN arithmetic overflow on 32 bit systems +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Alexander Dahl + +commit 88743470668ef5eb6b7ba9e0f99888e5999bf172 upstream. + +The intermediate result of the old term (4UL * 1024 * 1024 * 1024) is +4 294 967 296 or 0x100000000 which is no problem on 64 bit systems. +The patch does not change the later overall result of 0x100000 for +MAX_DMA32_PFN (after it has been shifted by PAGE_SHIFT). The new +calculation yields the same result, but does not require 64 bit +arithmetic. + +On 32 bit systems the old calculation suffers from an arithmetic +overflow in that intermediate term in braces: 4UL aka unsigned long int +is 4 byte wide and an arithmetic overflow happens (the 0x100000000 does +not fit in 4 bytes), the in braces result is truncated to zero, the +following right shift does not alter that, so MAX_DMA32_PFN evaluates to +0 on 32 bit systems. + +That wrong value is a problem in a comparision against MAX_DMA32_PFN in +the init code for swiotlb in pci_swiotlb_detect_4gb() to decide if +swiotlb should be active. That comparison yields the opposite result, +when compiling on 32 bit systems. + +This was not possible before + + 1b7e03ef7570 ("x86, NUMA: Enable emulation on 32bit too") + +when that MAX_DMA32_PFN was first made visible to x86_32 (and which +landed in v3.0). + +In practice this wasn't a problem, unless CONFIG_SWIOTLB is active on +x86-32. + +However if one has set CONFIG_IOMMU_INTEL, since + + c5a5dc4cbbf4 ("iommu/vt-d: Don't switch off swiotlb if bounce page is used") + +there's a dependency on CONFIG_SWIOTLB, which was not necessarily +active before. That landed in v5.4, where we noticed it in the fli4l +Linux distribution. We have CONFIG_IOMMU_INTEL active on both 32 and 64 +bit kernel configs there (I could not find out why, so let's just say +historical reasons). + +The effect is at boot time 64 MiB (default size) were allocated for +bounce buffers now, which is a noticeable amount of memory on small +systems like pcengines ALIX 2D3 with 256 MiB memory, which are still +frequently used as home routers. + +We noticed this effect when migrating from kernel v4.19 (LTS) to v5.4 +(LTS) in fli4l and got that kernel messages for example: + + Linux version 5.4.22 (buildroot@buildroot) (gcc version 7.3.0 (Buildroot 2018.02.8)) #1 SMP Mon Nov 26 23:40:00 CET 2018 + … + Memory: 183484K/261756K available (4594K kernel code, 393K rwdata, 1660K rodata, 536K init, 456K bss , 78272K reserved, 0K cma-reserved, 0K highmem) + … + PCI-DMA: Using software bounce buffering for IO (SWIOTLB) + software IO TLB: mapped [mem 0x0bb78000-0x0fb78000] (64MB) + +The initial analysis and the suggested fix was done by user 'sourcejedi' +at stackoverflow and explicitly marked as GPLv2 for inclusion in the +Linux kernel: + + https://unix.stackexchange.com/a/520525/50007 + +The new calculation, which does not suffer from that overflow, is the +same as for arch/mips now as suggested by Robin Murphy. + +The fix was tested by fli4l users on round about two dozen different +systems, including both 32 and 64 bit archs, bare metal and virtualized +machines. + + [ bp: Massage commit message. ] + +Fixes: 1b7e03ef7570 ("x86, NUMA: Enable emulation on 32bit too") +Reported-by: Alan Jenkins +Suggested-by: Robin Murphy +Signed-off-by: Alexander Dahl +Signed-off-by: Borislav Petkov +Reviewed-by: Greg Kroah-Hartman +Cc: stable@vger.kernel.org +Link: https://unix.stackexchange.com/q/520065/50007 +Link: https://web.nettworks.org/bugs/browse/FFL-2560 +Link: https://lkml.kernel.org/r/20200526175749.20742-1-post@lespocky.de +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/include/asm/dma.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/x86/include/asm/dma.h ++++ b/arch/x86/include/asm/dma.h +@@ -73,7 +73,7 @@ + #define MAX_DMA_PFN ((16UL * 1024 * 1024) >> PAGE_SHIFT) + + /* 4GB broken PCI/AGP hardware bus master zone */ +-#define MAX_DMA32_PFN ((4UL * 1024 * 1024 * 1024) >> PAGE_SHIFT) ++#define MAX_DMA32_PFN (1UL << (32 - PAGE_SHIFT)) + + #ifdef CONFIG_X86_32 + /* The maximum address that we can perform a DMA transfer to on this platform */ -- 2.47.3