From 2f7d8c1c996bb9a89ce02c83d11aa508f7ccc8ad Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Sat, 4 Jun 2016 12:50:33 -0700 Subject: [PATCH] 3.14-stable patches added patches: powerpc-book3s64-fix-branching-to-ool-handlers-in-relocatable-kernel.patch sunrpc-fix-stripping-of-padded-mic-tokens.patch xen-events-don-t-move-disabled-irqs.patch --- ...o-ool-handlers-in-relocatable-kernel.patch | 101 ++++++++++++++++++ queue-3.14/series | 3 + ...c-fix-stripping-of-padded-mic-tokens.patch | 52 +++++++++ .../xen-events-don-t-move-disabled-irqs.patch | 86 +++++++++++++++ 4 files changed, 242 insertions(+) create mode 100644 queue-3.14/powerpc-book3s64-fix-branching-to-ool-handlers-in-relocatable-kernel.patch create mode 100644 queue-3.14/sunrpc-fix-stripping-of-padded-mic-tokens.patch create mode 100644 queue-3.14/xen-events-don-t-move-disabled-irqs.patch diff --git a/queue-3.14/powerpc-book3s64-fix-branching-to-ool-handlers-in-relocatable-kernel.patch b/queue-3.14/powerpc-book3s64-fix-branching-to-ool-handlers-in-relocatable-kernel.patch new file mode 100644 index 00000000000..da6f65742d6 --- /dev/null +++ b/queue-3.14/powerpc-book3s64-fix-branching-to-ool-handlers-in-relocatable-kernel.patch @@ -0,0 +1,101 @@ +From 8ed8ab40047a570fdd8043a40c104a57248dd3fd Mon Sep 17 00:00:00 2001 +From: Hari Bathini +Date: Fri, 15 Apr 2016 22:48:02 +1000 +Subject: powerpc/book3s64: Fix branching to OOL handlers in relocatable kernel + +From: Hari Bathini + +commit 8ed8ab40047a570fdd8043a40c104a57248dd3fd upstream. + +Some of the interrupt vectors on 64-bit POWER server processors are only +32 bytes long (8 instructions), which is not enough for the full +first-level interrupt handler. For these we need to branch to an +out-of-line (OOL) handler. But when we are running a relocatable kernel, +interrupt vectors till __end_interrupts marker are copied down to real +address 0x100. So, branching to labels (ie. OOL handlers) outside this +section must be handled differently (see LOAD_HANDLER()), considering +relocatable kernel, which would need at least 4 instructions. + +However, branching from interrupt vector means that we corrupt the +CFAR (come-from address register) on POWER7 and later processors as +mentioned in commit 1707dd16. So, EXCEPTION_PROLOG_0 (6 instructions) +that contains the part up to the point where the CFAR is saved in the +PACA should be part of the short interrupt vectors before we branch out +to OOL handlers. + +But as mentioned already, there are interrupt vectors on 64-bit POWER +server processors that are only 32 bytes long (like vectors 0x4f00, +0x4f20, etc.), which cannot accomodate the above two cases at the same +time owing to space constraint. Currently, in these interrupt vectors, +we simply branch out to OOL handlers, without using LOAD_HANDLER(), +which leaves us vulnerable when running a relocatable kernel (eg. kdump +case). While this has been the case for sometime now and kdump is used +widely, we were fortunate not to see any problems so far, for three +reasons: + + 1. In almost all cases, production kernel (relocatable) is used for + kdump as well, which would mean that crashed kernel's OOL handler + would be at the same place where we end up branching to, from short + interrupt vector of kdump kernel. + 2. Also, OOL handler was unlikely the reason for crash in almost all + the kdump scenarios, which meant we had a sane OOL handler from + crashed kernel that we branched to. + 3. On most 64-bit POWER server processors, page size is large enough + that marking interrupt vector code as executable (see commit + 429d2e83) leads to marking OOL handler code from crashed kernel, + that sits right below interrupt vector code from kdump kernel, as + executable as well. + +Let us fix this by moving the __end_interrupts marker down past OOL +handlers to make sure that we also copy OOL handlers to real address +0x100 when running a relocatable kernel. + +This fix has been tested successfully in kdump scenario, on an LPAR with +4K page size by using different default/production kernel and kdump +kernel. + +Also tested by manually corrupting the OOL handlers in the first kernel +and then kdump'ing, and then causing the OOL handlers to fire - mpe. + +Fixes: c1fb6816fb1b ("powerpc: Add relocation on exception vector handlers") +Signed-off-by: Hari Bathini +Signed-off-by: Mahesh Salgaonkar +Signed-off-by: Michael Ellerman +Signed-off-by: Greg Kroah-Hartman + +--- + arch/powerpc/kernel/exceptions-64s.S | 16 +++++++++++----- + 1 file changed, 11 insertions(+), 5 deletions(-) + +--- a/arch/powerpc/kernel/exceptions-64s.S ++++ b/arch/powerpc/kernel/exceptions-64s.S +@@ -946,11 +946,6 @@ hv_facility_unavailable_relon_trampoline + #endif + STD_RELON_EXCEPTION_PSERIES(0x5700, 0x1700, altivec_assist) + +- /* Other future vectors */ +- .align 7 +- .globl __end_interrupts +-__end_interrupts: +- + .align 7 + system_call_entry_direct: + #if defined(CONFIG_RELOCATABLE) +@@ -1304,6 +1299,17 @@ __end_handlers: + STD_RELON_EXCEPTION_PSERIES_OOL(0xf60, facility_unavailable) + STD_RELON_EXCEPTION_HV_OOL(0xf80, hv_facility_unavailable) + ++ /* ++ * The __end_interrupts marker must be past the out-of-line (OOL) ++ * handlers, so that they are copied to real address 0x100 when running ++ * a relocatable kernel. This ensures they can be reached from the short ++ * trampoline handlers (like 0x4f00, 0x4f20, etc.) which branch ++ * directly, without using LOAD_HANDLER(). ++ */ ++ .align 7 ++ .globl __end_interrupts ++__end_interrupts: ++ + #if defined(CONFIG_PPC_PSERIES) || defined(CONFIG_PPC_POWERNV) + /* + * Data area reserved for FWNMI option. diff --git a/queue-3.14/series b/queue-3.14/series index 1c99e75dd51..4ed1d7b7b9e 100644 --- a/queue-3.14/series +++ b/queue-3.14/series @@ -9,3 +9,6 @@ cpuidle-indicate-when-a-device-has-been-unregistered.patch pci-disable-all-bar-sizing-for-devices-with-non-compliant-bars.patch rtlwifi-fix-logic-error-in-enter-exit-power-save-mode.patch pipe-fix-buffer-offset-after-partially-failed-read.patch +powerpc-book3s64-fix-branching-to-ool-handlers-in-relocatable-kernel.patch +xen-events-don-t-move-disabled-irqs.patch +sunrpc-fix-stripping-of-padded-mic-tokens.patch diff --git a/queue-3.14/sunrpc-fix-stripping-of-padded-mic-tokens.patch b/queue-3.14/sunrpc-fix-stripping-of-padded-mic-tokens.patch new file mode 100644 index 00000000000..187d6a43a11 --- /dev/null +++ b/queue-3.14/sunrpc-fix-stripping-of-padded-mic-tokens.patch @@ -0,0 +1,52 @@ +From c0cb8bf3a8e4bd82e640862cdd8891400405cb89 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Tom=C3=A1=C5=A1=20Trnka?= +Date: Fri, 20 May 2016 16:41:10 +0200 +Subject: sunrpc: fix stripping of padded MIC tokens +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Tomáš Trnka + +commit c0cb8bf3a8e4bd82e640862cdd8891400405cb89 upstream. + +The length of the GSS MIC token need not be a multiple of four bytes. +It is then padded by XDR to a multiple of 4 B, but unwrap_integ_data() +would previously only trim mic.len + 4 B. The remaining up to three +bytes would then trigger a check in nfs4svc_decode_compoundargs(), +leading to a "garbage args" error and mount failure: + +nfs4svc_decode_compoundargs: compound not properly padded! +nfsd: failed to decode arguments! + +This would prevent older clients using the pre-RFC 4121 MIC format +(37-byte MIC including a 9-byte OID) from mounting exports from v3.9+ +servers using krb5i. + +The trimming was introduced by commit 4c190e2f913f ("sunrpc: trim off +trailing checksum before returning decrypted or integrity authenticated +buffer"). + +Fixes: 4c190e2f913f "unrpc: trim off trailing checksum..." +Signed-off-by: Tomáš Trnka +Acked-by: Jeff Layton +Signed-off-by: J. Bruce Fields +Signed-off-by: Greg Kroah-Hartman + +--- + net/sunrpc/auth_gss/svcauth_gss.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/net/sunrpc/auth_gss/svcauth_gss.c ++++ b/net/sunrpc/auth_gss/svcauth_gss.c +@@ -855,8 +855,8 @@ unwrap_integ_data(struct svc_rqst *rqstp + goto out; + if (svc_getnl(&buf->head[0]) != seq) + goto out; +- /* trim off the mic at the end before returning */ +- xdr_buf_trim(buf, mic.len + 4); ++ /* trim off the mic and padding at the end before returning */ ++ xdr_buf_trim(buf, round_up_to_quad(mic.len) + 4); + stat = 0; + out: + kfree(mic.data); diff --git a/queue-3.14/xen-events-don-t-move-disabled-irqs.patch b/queue-3.14/xen-events-don-t-move-disabled-irqs.patch new file mode 100644 index 00000000000..fbda89b8180 --- /dev/null +++ b/queue-3.14/xen-events-don-t-move-disabled-irqs.patch @@ -0,0 +1,86 @@ +From f0f393877c71ad227d36705d61d1e4062bc29cf5 Mon Sep 17 00:00:00 2001 +From: Ross Lagerwall +Date: Tue, 10 May 2016 16:11:00 +0100 +Subject: xen/events: Don't move disabled irqs + +From: Ross Lagerwall + +commit f0f393877c71ad227d36705d61d1e4062bc29cf5 upstream. + +Commit ff1e22e7a638 ("xen/events: Mask a moving irq") open-coded +irq_move_irq() but left out checking if the IRQ is disabled. This broke +resuming from suspend since it tries to move a (disabled) irq without +holding the IRQ's desc->lock. Fix it by adding in a check for disabled +IRQs. + +The resulting stacktrace was: +kernel BUG at /build/linux-UbQGH5/linux-4.4.0/kernel/irq/migration.c:31! +invalid opcode: 0000 [#1] SMP +Modules linked in: xenfs xen_privcmd ... +CPU: 0 PID: 9 Comm: migration/0 Not tainted 4.4.0-22-generic #39-Ubuntu +Hardware name: Xen HVM domU, BIOS 4.6.1-xs125180 05/04/2016 +task: ffff88003d75ee00 ti: ffff88003d7bc000 task.ti: ffff88003d7bc000 +RIP: 0010:[] [] irq_move_masked_irq+0xd2/0xe0 +RSP: 0018:ffff88003d7bfc50 EFLAGS: 00010046 +RAX: 0000000000000000 RBX: ffff88003d40ba00 RCX: 0000000000000001 +RDX: 0000000000000001 RSI: 0000000000000100 RDI: ffff88003d40bad8 +RBP: ffff88003d7bfc68 R08: 0000000000000000 R09: ffff88003d000000 +R10: 0000000000000000 R11: 000000000000023c R12: ffff88003d40bad0 +R13: ffffffff81f3a4a0 R14: 0000000000000010 R15: 00000000ffffffff +FS: 0000000000000000(0000) GS:ffff88003da00000(0000) knlGS:0000000000000000 +CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +CR2: 00007fd4264de624 CR3: 0000000037922000 CR4: 00000000003406f0 +DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 +Stack: + ffff88003d40ba38 0000000000000024 0000000000000000 ffff88003d7bfca0 + ffffffff814c8d92 00000010813ef89d 00000000805ea732 0000000000000009 + 0000000000000024 ffff88003cc39b80 ffff88003d7bfce0 ffffffff814c8f66 +Call Trace: + [] eoi_pirq+0xb2/0xf0 + [] __startup_pirq+0xe6/0x150 + [] xen_irq_resume+0x319/0x360 + [] xen_suspend+0xb5/0x180 + [] multi_cpu_stop+0xb5/0xe0 + [] ? cpu_stop_queue_work+0x80/0x80 + [] cpu_stopper_thread+0xb0/0x140 + [] ? finish_task_switch+0x76/0x220 + [] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x20 + [] smpboot_thread_fn+0x105/0x160 + [] ? sort_range+0x30/0x30 + [] kthread+0xd8/0xf0 + [] ? kthread_create_on_node+0x1e0/0x1e0 + [] ret_from_fork+0x3f/0x70 + [] ? kthread_create_on_node+0x1e0/0x1e0 + +Signed-off-by: Ross Lagerwall +Reviewed-by: Boris Ostrovsky +Signed-off-by: David Vrabel +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/xen/events/events_base.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +--- a/drivers/xen/events/events_base.c ++++ b/drivers/xen/events/events_base.c +@@ -506,7 +506,8 @@ static void eoi_pirq(struct irq_data *da + if (!VALID_EVTCHN(evtchn)) + return; + +- if (unlikely(irqd_is_setaffinity_pending(data))) { ++ if (unlikely(irqd_is_setaffinity_pending(data)) && ++ likely(!irqd_irq_disabled(data))) { + int masked = test_and_set_mask(evtchn); + + clear_evtchn(evtchn); +@@ -1408,7 +1409,8 @@ static void ack_dynirq(struct irq_data * + if (!VALID_EVTCHN(evtchn)) + return; + +- if (unlikely(irqd_is_setaffinity_pending(data))) { ++ if (unlikely(irqd_is_setaffinity_pending(data)) && ++ likely(!irqd_irq_disabled(data))) { + int masked = test_and_set_mask(evtchn); + + clear_evtchn(evtchn); -- 2.47.3