From: Greg Kroah-Hartman Date: Mon, 7 Nov 2016 16:24:07 +0000 (+0100) Subject: 4.8-stable patches X-Git-Tag: v4.4.31~26 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=77585f756132b0736c63d8d9ec1530449acab866;p=thirdparty%2Fkernel%2Fstable-queue.git 4.8-stable patches added patches: alsa-hda-adding-a-new-group-of-pin-cfg-into-alc295-pin-quirk-table.patch alsa-hda-allow-40-bit-dma-mask-for-nvidia-devices.patch alsa-hda-fix-headset-mic-detection-problem-for-two-dell-laptops.patch alsa-hda-fix-surround-output-pins-for-asrock-b150m-mobo.patch alsa-seq-fix-time-account-regression.patch alsa-usb-audio-add-quirk-for-syntek-stk1160.patch android-binder-add-strong-ref-checks.patch android-binder-clear-binder-and-cookie-when-setting-handle-in-flat-binder-struct.patch btrfs-fix-races-on-root_log_ctx-lists.patch cxl-fix-leaking-pid-refs-in-some-error-paths.patch device-dax-fix-percpu_ref_exit-ordering.patch gpio-acpi-fix-returned-error-from-acpi_dev_gpio_irq_get.patch gpio-gpio_get_chipinfo_ioctl-fix-information-leak.patch gpio-gpio_get_chipinfo_ioctl-fix-line-offset-validation.patch gpio-gpio_get_line-handle-event-_ioctl-fix-file-descriptor-leak.patch gpio-gpio_get_lineevent_ioctl-reject-invalid-line-and-event-flags.patch gpio-gpio_get_lineevent_ioctl-validate-line-offset.patch gpio-gpio_get_linehandle_ioctl-reject-invalid-line-flags.patch gpio-gpio_get_linehandle_ioctl-validate-line-offset.patch gpio-gpiohandle_get_line_values_ioctl-fix-another-information-leak.patch gpio-gpiohandle_get_line_values_ioctl-fix-information-leak.patch keys-fix-short-sprintf-buffer-in-proc-keys-show-function.patch keys-sort-out-big_key-initialisation.patch libxfs-clean-up-_calc_dquots_per_chunk.patch mm-list_lru.c-avoid-error-path-null-pointer-deref.patch mm-memcontrol-do-not-recurse-in-direct-reclaim.patch mm-slab-fix-kmemcg-cache-creation-delayed-issue.patch powerpc-64-fix-race-condition-in-setting-lock-bit-in-idle-wakeup-code.patch powerpc-64-re-fix-race-condition-between-going-idle-and-entering-guest.patch powerpc-convert-cmp-to-cmpd-in-idle-enter-sequence.patch powerpc-mm-radix-use-tlbiel-only-if-we-ever-ran-on-the-current-cpu.patch security-keys-make-big_keys-dependent-on-stdrng.patch thermal-powerclamp-correct-cpu-support-check.patch x86-microcode-amd-fix-more-fallout-from-config_randomize_memory-y.patch --- diff --git a/queue-4.8/alsa-hda-adding-a-new-group-of-pin-cfg-into-alc295-pin-quirk-table.patch b/queue-4.8/alsa-hda-adding-a-new-group-of-pin-cfg-into-alc295-pin-quirk-table.patch new file mode 100644 index 00000000000..e48ee75ee2b --- /dev/null +++ b/queue-4.8/alsa-hda-adding-a-new-group-of-pin-cfg-into-alc295-pin-quirk-table.patch @@ -0,0 +1,48 @@ +From f771d5bb71d4df9573d12386400540516672208b Mon Sep 17 00:00:00 2001 +From: Hui Wang +Date: Tue, 18 Oct 2016 10:59:09 +0800 +Subject: ALSA: hda - Adding a new group of pin cfg into ALC295 pin quirk table + +From: Hui Wang + +commit f771d5bb71d4df9573d12386400540516672208b upstream. + +We have a new Dell laptop model which uses ALC295, the pin definition +is different from the existing ones in the pin quirk table, to fix the +headset mic detection and mic mute led's problem, we need to add the +new pin defintion into the pin quirk table. + +Signed-off-by: Hui Wang +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman + +--- + sound/pci/hda/patch_realtek.c | 10 +++++++--- + 1 file changed, 7 insertions(+), 3 deletions(-) + +--- a/sound/pci/hda/patch_realtek.c ++++ b/sound/pci/hda/patch_realtek.c +@@ -5809,8 +5809,6 @@ static const struct hda_model_fixup alc2 + #define ALC295_STANDARD_PINS \ + {0x12, 0xb7a60130}, \ + {0x14, 0x90170110}, \ +- {0x17, 0x21014020}, \ +- {0x18, 0x21a19030}, \ + {0x21, 0x04211020} + + #define ALC298_STANDARD_PINS \ +@@ -6037,7 +6035,13 @@ static const struct snd_hda_pin_quirk al + ALC292_STANDARD_PINS, + {0x13, 0x90a60140}), + SND_HDA_PIN_QUIRK(0x10ec0295, 0x1028, "Dell", ALC269_FIXUP_DELL1_MIC_NO_PRESENCE, +- ALC295_STANDARD_PINS), ++ ALC295_STANDARD_PINS, ++ {0x17, 0x21014020}, ++ {0x18, 0x21a19030}), ++ SND_HDA_PIN_QUIRK(0x10ec0295, 0x1028, "Dell", ALC269_FIXUP_DELL1_MIC_NO_PRESENCE, ++ ALC295_STANDARD_PINS, ++ {0x17, 0x21014040}, ++ {0x18, 0x21a19050}), + SND_HDA_PIN_QUIRK(0x10ec0298, 0x1028, "Dell", ALC298_FIXUP_DELL1_MIC_NO_PRESENCE, + ALC298_STANDARD_PINS, + {0x17, 0x90170110}), diff --git a/queue-4.8/alsa-hda-allow-40-bit-dma-mask-for-nvidia-devices.patch b/queue-4.8/alsa-hda-allow-40-bit-dma-mask-for-nvidia-devices.patch new file mode 100644 index 00000000000..3c594544cec --- /dev/null +++ b/queue-4.8/alsa-hda-allow-40-bit-dma-mask-for-nvidia-devices.patch @@ -0,0 +1,54 @@ +From 3ab7511eafdd5c4f40d2832f09554478dfbea170 Mon Sep 17 00:00:00 2001 +From: Ard Biesheuvel +Date: Mon, 17 Oct 2016 17:23:59 +0100 +Subject: ALSA: hda - allow 40 bit DMA mask for NVidia devices + +From: Ard Biesheuvel + +commit 3ab7511eafdd5c4f40d2832f09554478dfbea170 upstream. + +Commit 49d9e77e72cf ("ALSA: hda - Fix system panic when DMA > 40 bits +for Nvidia audio controllers") simply disabled any DMA exceeding 32 +bits for NVidia devices, even though they are capable of performing +DMA up to 40 bits. On some architectures (such as arm64), system memory +is not guaranteed to be 32-bit addressable by PCI devices, and so this +change prevents NVidia devices from working on platforms such as AMD +Seattle. + +Since the original commit already mentioned that up to 40 bits of DMA +is supported, and given that the code has been updated in the meantime +to support a 40 bit DMA mask on other devices, revert commit 49d9e77e72cf +and explicitly set the DMA mask to 40 bits for NVidia devices. + +Fixes: 49d9e77e72cf ('ALSA: hda - Fix system panic when DMA > 40 bits...') +Signed-off-by: Ard Biesheuvel +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman + +--- + sound/pci/hda/hda_intel.c | 7 +++++-- + 1 file changed, 5 insertions(+), 2 deletions(-) + +--- a/sound/pci/hda/hda_intel.c ++++ b/sound/pci/hda/hda_intel.c +@@ -340,8 +340,7 @@ enum { + + /* quirks for Nvidia */ + #define AZX_DCAPS_PRESET_NVIDIA \ +- (AZX_DCAPS_NO_MSI | /*AZX_DCAPS_ALIGN_BUFSIZE |*/ \ +- AZX_DCAPS_NO_64BIT | AZX_DCAPS_CORBRP_SELF_CLEAR |\ ++ (AZX_DCAPS_NO_MSI | AZX_DCAPS_CORBRP_SELF_CLEAR |\ + AZX_DCAPS_SNOOP_TYPE(NVIDIA)) + + #define AZX_DCAPS_PRESET_CTHDA \ +@@ -1699,6 +1698,10 @@ static int azx_first_init(struct azx *ch + } + } + ++ /* NVidia hardware normally only supports up to 40 bits of DMA */ ++ if (chip->pci->vendor == PCI_VENDOR_ID_NVIDIA) ++ dma_bits = 40; ++ + /* disable 64bit DMA address on some devices */ + if (chip->driver_caps & AZX_DCAPS_NO_64BIT) { + dev_dbg(card->dev, "Disabling 64bit DMA\n"); diff --git a/queue-4.8/alsa-hda-fix-headset-mic-detection-problem-for-two-dell-laptops.patch b/queue-4.8/alsa-hda-fix-headset-mic-detection-problem-for-two-dell-laptops.patch new file mode 100644 index 00000000000..9c2820bd855 --- /dev/null +++ b/queue-4.8/alsa-hda-fix-headset-mic-detection-problem-for-two-dell-laptops.patch @@ -0,0 +1,43 @@ +From 6aecd8715802d23dc6a0859b50c62d2b0a99de3a Mon Sep 17 00:00:00 2001 +From: Hui Wang +Date: Thu, 20 Oct 2016 14:03:33 +0800 +Subject: ALSA: hda - Fix headset mic detection problem for two Dell laptops + +From: Hui Wang + +commit 6aecd8715802d23dc6a0859b50c62d2b0a99de3a upstream. + +They uses the codec ALC255, and have the different pin cfg definition +from the ones in the existing pin quirk table. Now adding them into +the table to fix the problem. + +Signed-off-by: Hui Wang +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman + +--- + sound/pci/hda/patch_realtek.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +--- a/sound/pci/hda/patch_realtek.c ++++ b/sound/pci/hda/patch_realtek.c +@@ -5855,11 +5855,19 @@ static const struct snd_hda_pin_quirk al + {0x1b, 0x02011020}, + {0x21, 0x0221101f}), + SND_HDA_PIN_QUIRK(0x10ec0255, 0x1028, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE, ++ {0x14, 0x90170110}, ++ {0x1b, 0x01011020}, ++ {0x21, 0x0221101f}), ++ SND_HDA_PIN_QUIRK(0x10ec0255, 0x1028, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE, + {0x14, 0x90170130}, + {0x1b, 0x01014020}, + {0x21, 0x0221103f}), + SND_HDA_PIN_QUIRK(0x10ec0255, 0x1028, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE, + {0x14, 0x90170130}, ++ {0x1b, 0x01011020}, ++ {0x21, 0x0221103f}), ++ SND_HDA_PIN_QUIRK(0x10ec0255, 0x1028, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE, ++ {0x14, 0x90170130}, + {0x1b, 0x02011020}, + {0x21, 0x0221103f}), + SND_HDA_PIN_QUIRK(0x10ec0255, 0x1028, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE, diff --git a/queue-4.8/alsa-hda-fix-surround-output-pins-for-asrock-b150m-mobo.patch b/queue-4.8/alsa-hda-fix-surround-output-pins-for-asrock-b150m-mobo.patch new file mode 100644 index 00000000000..15ae69b9b76 --- /dev/null +++ b/queue-4.8/alsa-hda-fix-surround-output-pins-for-asrock-b150m-mobo.patch @@ -0,0 +1,56 @@ +From 1a3f099101b85cc93d864eb030d97e7725c72ea7 Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Thu, 20 Oct 2016 12:14:51 +0200 +Subject: ALSA: hda - Fix surround output pins for ASRock B150M mobo + +From: Takashi Iwai + +commit 1a3f099101b85cc93d864eb030d97e7725c72ea7 upstream. + +ASRock B150M Pro4/D3 mobo with ALC892 codec doesn't seem to provide +proper pins for the surround outputs, hence we need to specify the +pincfgs manually with a couple of other corrections. + +Reported-and-tested-by: Benjamin Valentin +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman + +--- + sound/pci/hda/patch_realtek.c | 12 ++++++++++++ + 1 file changed, 12 insertions(+) + +--- a/sound/pci/hda/patch_realtek.c ++++ b/sound/pci/hda/patch_realtek.c +@@ -6615,6 +6615,7 @@ enum { + ALC891_FIXUP_HEADSET_MODE, + ALC891_FIXUP_DELL_MIC_NO_PRESENCE, + ALC662_FIXUP_ACER_VERITON, ++ ALC892_FIXUP_ASROCK_MOBO, + }; + + static const struct hda_fixup alc662_fixups[] = { +@@ -6891,6 +6892,16 @@ static const struct hda_fixup alc662_fix + { } + } + }, ++ [ALC892_FIXUP_ASROCK_MOBO] = { ++ .type = HDA_FIXUP_PINS, ++ .v.pins = (const struct hda_pintbl[]) { ++ { 0x15, 0x40f000f0 }, /* disabled */ ++ { 0x16, 0x40f000f0 }, /* disabled */ ++ { 0x18, 0x01014011 }, /* LO */ ++ { 0x1a, 0x01014012 }, /* LO */ ++ { } ++ } ++ }, + }; + + static const struct snd_pci_quirk alc662_fixup_tbl[] = { +@@ -6928,6 +6939,7 @@ static const struct snd_pci_quirk alc662 + SND_PCI_QUIRK(0x144d, 0xc051, "Samsung R720", ALC662_FIXUP_IDEAPAD), + SND_PCI_QUIRK(0x17aa, 0x38af, "Lenovo Ideapad Y550P", ALC662_FIXUP_IDEAPAD), + SND_PCI_QUIRK(0x17aa, 0x3a0d, "Lenovo Ideapad Y550", ALC662_FIXUP_IDEAPAD), ++ SND_PCI_QUIRK(0x1849, 0x5892, "ASRock B150M", ALC892_FIXUP_ASROCK_MOBO), + SND_PCI_QUIRK(0x19da, 0xa130, "Zotac Z68", ALC662_FIXUP_ZOTAC_Z68), + SND_PCI_QUIRK(0x1b0a, 0x01b8, "ACER Veriton", ALC662_FIXUP_ACER_VERITON), + SND_PCI_QUIRK(0x1b35, 0x2206, "CZC P10T", ALC662_FIXUP_CZC_P10T), diff --git a/queue-4.8/alsa-seq-fix-time-account-regression.patch b/queue-4.8/alsa-seq-fix-time-account-regression.patch new file mode 100644 index 00000000000..c1dde1c40db --- /dev/null +++ b/queue-4.8/alsa-seq-fix-time-account-regression.patch @@ -0,0 +1,42 @@ +From 9b50898ad96c793a8f7cde9d8f281596d752a7dd Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Tue, 25 Oct 2016 15:56:35 +0200 +Subject: ALSA: seq: Fix time account regression + +From: Takashi Iwai + +commit 9b50898ad96c793a8f7cde9d8f281596d752a7dd upstream. + +The recent rewrite of the sequencer time accounting using timespec64 +in the commit [3915bf294652: ALSA: seq_timer: use monotonic times +internally] introduced a bad regression. Namely, the time reported +back doesn't increase but goes back and forth. + +The culprit was obvious: the delta is stored to the result (cur_time = +delta), instead of adding the delta (cur_time += delta)! + +Let's fix it. + +Fixes: 3915bf294652 ('ALSA: seq_timer: use monotonic times internally') +Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=177571 +Reported-by: Yves Guillemot +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman + +--- + sound/core/seq/seq_timer.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/sound/core/seq/seq_timer.c ++++ b/sound/core/seq/seq_timer.c +@@ -448,8 +448,8 @@ snd_seq_real_time_t snd_seq_timer_get_cu + + ktime_get_ts64(&tm); + tm = timespec64_sub(tm, tmr->last_update); +- cur_time.tv_nsec = tm.tv_nsec; +- cur_time.tv_sec = tm.tv_sec; ++ cur_time.tv_nsec += tm.tv_nsec; ++ cur_time.tv_sec += tm.tv_sec; + snd_seq_sanity_real_time(&cur_time); + } + spin_unlock_irqrestore(&tmr->lock, flags); diff --git a/queue-4.8/alsa-usb-audio-add-quirk-for-syntek-stk1160.patch b/queue-4.8/alsa-usb-audio-add-quirk-for-syntek-stk1160.patch new file mode 100644 index 00000000000..8839540b41a --- /dev/null +++ b/queue-4.8/alsa-usb-audio-add-quirk-for-syntek-stk1160.patch @@ -0,0 +1,48 @@ +From bdc3478f90cd4d2928197f36629d5cf93b64dbe9 Mon Sep 17 00:00:00 2001 +From: Marcel Hasler +Date: Thu, 27 Oct 2016 00:42:27 +0200 +Subject: ALSA: usb-audio: Add quirk for Syntek STK1160 + +From: Marcel Hasler + +commit bdc3478f90cd4d2928197f36629d5cf93b64dbe9 upstream. + +The stk1160 chip needs QUIRK_AUDIO_ALIGN_TRANSFER. This patch resolves +the issue reported on the mailing list +(http://marc.info/?l=linux-sound&m=139223599126215&w=2) and also fixes +bug 180071 (https://bugzilla.kernel.org/show_bug.cgi?id=180071). + +Signed-off-by: Marcel Hasler +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman + +--- + sound/usb/quirks-table.h | 17 +++++++++++++++++ + 1 file changed, 17 insertions(+) + +--- a/sound/usb/quirks-table.h ++++ b/sound/usb/quirks-table.h +@@ -2907,6 +2907,23 @@ AU0828_DEVICE(0x2040, 0x7260, "Hauppauge + AU0828_DEVICE(0x2040, 0x7213, "Hauppauge", "HVR-950Q"), + AU0828_DEVICE(0x2040, 0x7270, "Hauppauge", "HVR-950Q"), + ++/* Syntek STK1160 */ ++{ ++ .match_flags = USB_DEVICE_ID_MATCH_DEVICE | ++ USB_DEVICE_ID_MATCH_INT_CLASS | ++ USB_DEVICE_ID_MATCH_INT_SUBCLASS, ++ .idVendor = 0x05e1, ++ .idProduct = 0x0408, ++ .bInterfaceClass = USB_CLASS_AUDIO, ++ .bInterfaceSubClass = USB_SUBCLASS_AUDIOCONTROL, ++ .driver_info = (unsigned long) &(const struct snd_usb_audio_quirk) { ++ .vendor_name = "Syntek", ++ .product_name = "STK1160", ++ .ifnum = QUIRK_ANY_INTERFACE, ++ .type = QUIRK_AUDIO_ALIGN_TRANSFER ++ } ++}, ++ + /* Digidesign Mbox */ + { + /* Thanks to Clemens Ladisch */ diff --git a/queue-4.8/android-binder-add-strong-ref-checks.patch b/queue-4.8/android-binder-add-strong-ref-checks.patch new file mode 100644 index 00000000000..3d580614d91 --- /dev/null +++ b/queue-4.8/android-binder-add-strong-ref-checks.patch @@ -0,0 +1,107 @@ +From 0a3ffab93fe52530602fe47cd74802cffdb19c05 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Arve=20Hj=C3=B8nnev=C3=A5g?= +Date: Mon, 24 Oct 2016 15:20:29 +0200 +Subject: ANDROID: binder: Add strong ref checks +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Arve Hjønnevåg + +commit 0a3ffab93fe52530602fe47cd74802cffdb19c05 upstream. + +Prevent using a binder_ref with only weak references where a strong +reference is required. + +Signed-off-by: Arve Hjønnevåg +Signed-off-by: Martijn Coenen +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/android/binder.c | 30 +++++++++++++++++++++--------- + 1 file changed, 21 insertions(+), 9 deletions(-) + +--- a/drivers/android/binder.c ++++ b/drivers/android/binder.c +@@ -1003,7 +1003,7 @@ static int binder_dec_node(struct binder + + + static struct binder_ref *binder_get_ref(struct binder_proc *proc, +- uint32_t desc) ++ u32 desc, bool need_strong_ref) + { + struct rb_node *n = proc->refs_by_desc.rb_node; + struct binder_ref *ref; +@@ -1011,12 +1011,16 @@ static struct binder_ref *binder_get_ref + while (n) { + ref = rb_entry(n, struct binder_ref, rb_node_desc); + +- if (desc < ref->desc) ++ if (desc < ref->desc) { + n = n->rb_left; +- else if (desc > ref->desc) ++ } else if (desc > ref->desc) { + n = n->rb_right; +- else ++ } else if (need_strong_ref && !ref->strong) { ++ binder_user_error("tried to use weak ref as strong ref\n"); ++ return NULL; ++ } else { + return ref; ++ } + } + return NULL; + } +@@ -1286,7 +1290,10 @@ static void binder_transaction_buffer_re + } break; + case BINDER_TYPE_HANDLE: + case BINDER_TYPE_WEAK_HANDLE: { +- struct binder_ref *ref = binder_get_ref(proc, fp->handle); ++ struct binder_ref *ref; ++ ++ ref = binder_get_ref(proc, fp->handle, ++ fp->type == BINDER_TYPE_HANDLE); + + if (ref == NULL) { + pr_err("transaction release %d bad handle %d\n", +@@ -1381,7 +1388,7 @@ static void binder_transaction(struct bi + if (tr->target.handle) { + struct binder_ref *ref; + +- ref = binder_get_ref(proc, tr->target.handle); ++ ref = binder_get_ref(proc, tr->target.handle, true); + if (ref == NULL) { + binder_user_error("%d:%d got transaction to invalid handle\n", + proc->pid, thread->pid); +@@ -1590,7 +1597,10 @@ static void binder_transaction(struct bi + } break; + case BINDER_TYPE_HANDLE: + case BINDER_TYPE_WEAK_HANDLE: { +- struct binder_ref *ref = binder_get_ref(proc, fp->handle); ++ struct binder_ref *ref; ++ ++ ref = binder_get_ref(proc, fp->handle, ++ fp->type == BINDER_TYPE_HANDLE); + + if (ref == NULL) { + binder_user_error("%d:%d got transaction with invalid handle, %d\n", +@@ -1801,7 +1811,9 @@ static int binder_thread_write(struct bi + ref->desc); + } + } else +- ref = binder_get_ref(proc, target); ++ ref = binder_get_ref(proc, target, ++ cmd == BC_ACQUIRE || ++ cmd == BC_RELEASE); + if (ref == NULL) { + binder_user_error("%d:%d refcount change on invalid ref %d\n", + proc->pid, thread->pid, target); +@@ -1997,7 +2009,7 @@ static int binder_thread_write(struct bi + if (get_user(cookie, (binder_uintptr_t __user *)ptr)) + return -EFAULT; + ptr += sizeof(binder_uintptr_t); +- ref = binder_get_ref(proc, target); ++ ref = binder_get_ref(proc, target, false); + if (ref == NULL) { + binder_user_error("%d:%d %s invalid ref %d\n", + proc->pid, thread->pid, diff --git a/queue-4.8/android-binder-clear-binder-and-cookie-when-setting-handle-in-flat-binder-struct.patch b/queue-4.8/android-binder-clear-binder-and-cookie-when-setting-handle-in-flat-binder-struct.patch new file mode 100644 index 00000000000..f6a51d780aa --- /dev/null +++ b/queue-4.8/android-binder-clear-binder-and-cookie-when-setting-handle-in-flat-binder-struct.patch @@ -0,0 +1,52 @@ +From 4afb604e2d14d429ac9e1fd84b952602853b2df5 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Arve=20Hj=C3=B8nnev=C3=A5g?= +Date: Mon, 24 Oct 2016 15:20:30 +0200 +Subject: ANDROID: binder: Clear binder and cookie when setting handle in flat binder struct +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Arve Hjønnevåg + +commit 4afb604e2d14d429ac9e1fd84b952602853b2df5 upstream. + +Prevents leaking pointers between processes + +Signed-off-by: Arve Hjønnevåg +Signed-off-by: Martijn Coenen +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/android/binder.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/drivers/android/binder.c ++++ b/drivers/android/binder.c +@@ -1585,7 +1585,9 @@ static void binder_transaction(struct bi + fp->type = BINDER_TYPE_HANDLE; + else + fp->type = BINDER_TYPE_WEAK_HANDLE; ++ fp->binder = 0; + fp->handle = ref->desc; ++ fp->cookie = 0; + binder_inc_ref(ref, fp->type == BINDER_TYPE_HANDLE, + &thread->todo); + +@@ -1635,7 +1637,9 @@ static void binder_transaction(struct bi + return_error = BR_FAILED_REPLY; + goto err_binder_get_ref_for_node_failed; + } ++ fp->binder = 0; + fp->handle = new_ref->desc; ++ fp->cookie = 0; + binder_inc_ref(new_ref, fp->type == BINDER_TYPE_HANDLE, NULL); + trace_binder_transaction_ref_to_ref(t, ref, + new_ref); +@@ -1689,6 +1693,7 @@ static void binder_transaction(struct bi + binder_debug(BINDER_DEBUG_TRANSACTION, + " fd %d -> %d\n", fp->handle, target_fd); + /* TODO: fput? */ ++ fp->binder = 0; + fp->handle = target_fd; + } break; + diff --git a/queue-4.8/btrfs-fix-races-on-root_log_ctx-lists.patch b/queue-4.8/btrfs-fix-races-on-root_log_ctx-lists.patch new file mode 100644 index 00000000000..83473a5a5c4 --- /dev/null +++ b/queue-4.8/btrfs-fix-races-on-root_log_ctx-lists.patch @@ -0,0 +1,84 @@ +From 570dd45042a7c8a7aba1ee029c5dd0f5ccf41b9b Mon Sep 17 00:00:00 2001 +From: Chris Mason +Date: Thu, 27 Oct 2016 10:42:20 -0700 +Subject: btrfs: fix races on root_log_ctx lists + +From: Chris Mason + +commit 570dd45042a7c8a7aba1ee029c5dd0f5ccf41b9b upstream. + +btrfs_remove_all_log_ctxs takes a shortcut where it avoids walking the +list because it knows all of the waiters are patiently waiting for the +commit to finish. + +But, there's a small race where btrfs_sync_log can remove itself from +the list if it finds a log commit is already done. Also, it uses +list_del_init() to remove itself from the list, but there's no way to +know if btrfs_remove_all_log_ctxs has already run, so we don't know for +sure if it is safe to call list_del_init(). + +This gets rid of all the shortcuts for btrfs_remove_all_log_ctxs(), and +just calls it with the proper locking. + +This is part two of the corruption fixed by cbd60aa7cd1. I should have +done this in the first place, but convinced myself the optimizations were +safe. A 12 hour run of dbench 2048 will eventually trigger a list debug +WARN_ON for the list_del_init() in btrfs_sync_log(). + +Fixes: d1433debe7f4346cf9fc0dafc71c3137d2a97bc4 +Reported-by: Dave Jones +Signed-off-by: Chris Mason +Signed-off-by: Greg Kroah-Hartman + +--- + fs/btrfs/tree-log.c | 20 ++++++-------------- + 1 file changed, 6 insertions(+), 14 deletions(-) + +--- a/fs/btrfs/tree-log.c ++++ b/fs/btrfs/tree-log.c +@@ -2713,14 +2713,12 @@ static inline void btrfs_remove_all_log_ + int index, int error) + { + struct btrfs_log_ctx *ctx; ++ struct btrfs_log_ctx *safe; + +- if (!error) { +- INIT_LIST_HEAD(&root->log_ctxs[index]); +- return; +- } +- +- list_for_each_entry(ctx, &root->log_ctxs[index], list) ++ list_for_each_entry_safe(ctx, safe, &root->log_ctxs[index], list) { ++ list_del_init(&ctx->list); + ctx->log_ret = error; ++ } + + INIT_LIST_HEAD(&root->log_ctxs[index]); + } +@@ -2961,13 +2959,9 @@ int btrfs_sync_log(struct btrfs_trans_ha + mutex_unlock(&root->log_mutex); + + out_wake_log_root: +- /* +- * We needn't get log_mutex here because we are sure all +- * the other tasks are blocked. +- */ ++ mutex_lock(&log_root_tree->log_mutex); + btrfs_remove_all_log_ctxs(log_root_tree, index2, ret); + +- mutex_lock(&log_root_tree->log_mutex); + log_root_tree->log_transid_committed++; + atomic_set(&log_root_tree->log_commit[index2], 0); + mutex_unlock(&log_root_tree->log_mutex); +@@ -2978,10 +2972,8 @@ out_wake_log_root: + if (waitqueue_active(&log_root_tree->log_commit_wait[index2])) + wake_up(&log_root_tree->log_commit_wait[index2]); + out: +- /* See above. */ +- btrfs_remove_all_log_ctxs(root, index1, ret); +- + mutex_lock(&root->log_mutex); ++ btrfs_remove_all_log_ctxs(root, index1, ret); + root->log_transid_committed++; + atomic_set(&root->log_commit[index1], 0); + mutex_unlock(&root->log_mutex); diff --git a/queue-4.8/cxl-fix-leaking-pid-refs-in-some-error-paths.patch b/queue-4.8/cxl-fix-leaking-pid-refs-in-some-error-paths.patch new file mode 100644 index 00000000000..8927bdc3c39 --- /dev/null +++ b/queue-4.8/cxl-fix-leaking-pid-refs-in-some-error-paths.patch @@ -0,0 +1,84 @@ +From a05b82d5149dfeef05254a11c3636a89a854520a Mon Sep 17 00:00:00 2001 +From: Vaibhav Jain +Date: Fri, 21 Oct 2016 14:53:53 +0530 +Subject: cxl: Fix leaking pid refs in some error paths + +From: Vaibhav Jain + +commit a05b82d5149dfeef05254a11c3636a89a854520a upstream. + +In some error paths in functions cxl_start_context and +afu_ioctl_start_work pid references to the current & group-leader tasks +can leak after they are taken. This patch fixes these error paths to +release these pid references before exiting the error path. + +Fixes: 7b8ad495d592 ("cxl: Fix DSI misses when the context owning task exits") +Reviewed-by: Andrew Donnellan +Reported-by: Frederic Barrat +Signed-off-by: Vaibhav Jain +Acked-by: Frederic Barrat +Signed-off-by: Michael Ellerman +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/misc/cxl/api.c | 2 ++ + drivers/misc/cxl/file.c | 22 +++++++++++++--------- + 2 files changed, 15 insertions(+), 9 deletions(-) + +--- a/drivers/misc/cxl/api.c ++++ b/drivers/misc/cxl/api.c +@@ -247,7 +247,9 @@ int cxl_start_context(struct cxl_context + cxl_ctx_get(); + + if ((rc = cxl_ops->attach_process(ctx, kernel, wed, 0))) { ++ put_pid(ctx->glpid); + put_pid(ctx->pid); ++ ctx->glpid = ctx->pid = NULL; + cxl_adapter_context_put(ctx->afu->adapter); + cxl_ctx_put(); + goto out; +--- a/drivers/misc/cxl/file.c ++++ b/drivers/misc/cxl/file.c +@@ -194,6 +194,16 @@ static long afu_ioctl_start_work(struct + ctx->mmio_err_ff = !!(work.flags & CXL_START_WORK_ERR_FF); + + /* ++ * Increment the mapped context count for adapter. This also checks ++ * if adapter_context_lock is taken. ++ */ ++ rc = cxl_adapter_context_get(ctx->afu->adapter); ++ if (rc) { ++ afu_release_irqs(ctx, ctx); ++ goto out; ++ } ++ ++ /* + * We grab the PID here and not in the file open to allow for the case + * where a process (master, some daemon, etc) has opened the chardev on + * behalf of another process, so the AFU's mm gets bound to the process +@@ -205,15 +215,6 @@ static long afu_ioctl_start_work(struct + ctx->pid = get_task_pid(current, PIDTYPE_PID); + ctx->glpid = get_task_pid(current->group_leader, PIDTYPE_PID); + +- /* +- * Increment the mapped context count for adapter. This also checks +- * if adapter_context_lock is taken. +- */ +- rc = cxl_adapter_context_get(ctx->afu->adapter); +- if (rc) { +- afu_release_irqs(ctx, ctx); +- goto out; +- } + + trace_cxl_attach(ctx, work.work_element_descriptor, work.num_interrupts, amr); + +@@ -221,6 +222,9 @@ static long afu_ioctl_start_work(struct + amr))) { + afu_release_irqs(ctx, ctx); + cxl_adapter_context_put(ctx->afu->adapter); ++ put_pid(ctx->glpid); ++ put_pid(ctx->pid); ++ ctx->glpid = ctx->pid = NULL; + goto out; + } + diff --git a/queue-4.8/device-dax-fix-percpu_ref_exit-ordering.patch b/queue-4.8/device-dax-fix-percpu_ref_exit-ordering.patch new file mode 100644 index 00000000000..c978c12207a --- /dev/null +++ b/queue-4.8/device-dax-fix-percpu_ref_exit-ordering.patch @@ -0,0 +1,50 @@ +From 52e73eb2872c9af6f382b2b22954ca8214397a4e Mon Sep 17 00:00:00 2001 +From: Dan Williams +Date: Thu, 27 Oct 2016 17:04:05 -0700 +Subject: device-dax: fix percpu_ref_exit ordering + +From: Dan Williams + +commit 52e73eb2872c9af6f382b2b22954ca8214397a4e upstream. + +We need to wait until the percpu_ref is released before exit. Otherwise, +we sometimes lose the race and trigger this new warning that was added +in v4.9 (commit a67823c1ed10 "percpu-refcount: init ->confirm_switch +member properly"): + + WARNING: CPU: 0 PID: 3629 at lib/percpu-refcount.c:107 percpu_ref_exit+0x51/0x60 + [..] + Call Trace: + [] dump_stack+0x85/0xc2 + [] __warn+0xcb/0xf0 + [] warn_slowpath_null+0x1d/0x20 + [] percpu_ref_exit+0x51/0x60 + [] dax_pmem_percpu_exit+0x1a/0x50 [dax_pmem] + [] devm_action_release+0xf/0x20 + +Fixes: ab68f2622136 ("/dev/dax, pmem: direct access to persistent memory") +Signed-off-by: Dan Williams +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/dax/pmem.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/dax/pmem.c ++++ b/drivers/dax/pmem.c +@@ -44,7 +44,6 @@ static void dax_pmem_percpu_exit(void *d + + dev_dbg(dax_pmem->dev, "%s\n", __func__); + percpu_ref_exit(ref); +- wait_for_completion(&dax_pmem->cmp); + } + + static void dax_pmem_percpu_kill(void *data) +@@ -54,6 +53,7 @@ static void dax_pmem_percpu_kill(void *d + + dev_dbg(dax_pmem->dev, "%s\n", __func__); + percpu_ref_kill(ref); ++ wait_for_completion(&dax_pmem->cmp); + } + + static int dax_pmem_probe(struct device *dev) diff --git a/queue-4.8/gpio-acpi-fix-returned-error-from-acpi_dev_gpio_irq_get.patch b/queue-4.8/gpio-acpi-fix-returned-error-from-acpi_dev_gpio_irq_get.patch new file mode 100644 index 00000000000..ef20213a199 --- /dev/null +++ b/queue-4.8/gpio-acpi-fix-returned-error-from-acpi_dev_gpio_irq_get.patch @@ -0,0 +1,55 @@ +From 67bf5156edc4f58241fd7c119ae145c552adddd6 Mon Sep 17 00:00:00 2001 +From: David Arcari +Date: Wed, 12 Oct 2016 18:40:30 +0200 +Subject: gpio / ACPI: fix returned error from acpi_dev_gpio_irq_get() + +From: David Arcari + +commit 67bf5156edc4f58241fd7c119ae145c552adddd6 upstream. + +acpi_dev_gpio_irq_get() currently ignores the error returned +by acpi_get_gpiod_by_index() and overwrites it with -ENOENT. + +Problem is this error can be -EPROBE_DEFER, which just blows +up some drivers when the module ordering is not correct. + +Signed-off-by: David Arcari +Signed-off-by: Benjamin Tissoires +Acked-by: Mika Westerberg +Signed-off-by: Linus Walleij +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpio/gpiolib-acpi.c | 7 +++++-- + 1 file changed, 5 insertions(+), 2 deletions(-) + +--- a/drivers/gpio/gpiolib-acpi.c ++++ b/drivers/gpio/gpiolib-acpi.c +@@ -602,14 +602,17 @@ int acpi_dev_gpio_irq_get(struct acpi_de + { + int idx, i; + unsigned int irq_flags; ++ int ret = -ENOENT; + + for (i = 0, idx = 0; idx <= index; i++) { + struct acpi_gpio_info info; + struct gpio_desc *desc; + + desc = acpi_get_gpiod_by_index(adev, NULL, i, &info); +- if (IS_ERR(desc)) ++ if (IS_ERR(desc)) { ++ ret = PTR_ERR(desc); + break; ++ } + if (info.gpioint && idx++ == index) { + int irq = gpiod_to_irq(desc); + +@@ -628,7 +631,7 @@ int acpi_dev_gpio_irq_get(struct acpi_de + } + + } +- return -ENOENT; ++ return ret; + } + EXPORT_SYMBOL_GPL(acpi_dev_gpio_irq_get); + diff --git a/queue-4.8/gpio-gpio_get_chipinfo_ioctl-fix-information-leak.patch b/queue-4.8/gpio-gpio_get_chipinfo_ioctl-fix-information-leak.patch new file mode 100644 index 00000000000..786fdfea033 --- /dev/null +++ b/queue-4.8/gpio-gpio_get_chipinfo_ioctl-fix-information-leak.patch @@ -0,0 +1,37 @@ +From 0f4bbb233743bdfd51d47688b0bc2561f310488b Mon Sep 17 00:00:00 2001 +From: Lars-Peter Clausen +Date: Tue, 18 Oct 2016 16:54:00 +0200 +Subject: gpio: GPIO_GET_CHIPINFO_IOCTL: Fix information leak + +From: Lars-Peter Clausen + +commit 0f4bbb233743bdfd51d47688b0bc2561f310488b upstream. + +The GPIO_GET_CHIPINFO_IOCTL handler allocates a gpiochip_info struct on the +stack and then passes it to copy_to_user(). But depending on the length of +the GPIO chip name and label the struct is only partially initialized. + +This exposes the previous, potentially sensitive, stack content to the +issuing userspace application. To avoid this make sure that the struct is +fully initialized. + +Fixes: 521a2ad6f862 ("gpio: add userspace ABI for GPIO line information") +Signed-off-by: Lars-Peter Clausen +Signed-off-by: Linus Walleij +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpio/gpiolib.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/gpio/gpiolib.c ++++ b/drivers/gpio/gpiolib.c +@@ -821,6 +821,8 @@ static long gpio_ioctl(struct file *filp + if (cmd == GPIO_GET_CHIPINFO_IOCTL) { + struct gpiochip_info chipinfo; + ++ memset(&chipinfo, 0, sizeof(chipinfo)); ++ + strncpy(chipinfo.name, dev_name(&gdev->dev), + sizeof(chipinfo.name)); + chipinfo.name[sizeof(chipinfo.name)-1] = '\0'; diff --git a/queue-4.8/gpio-gpio_get_chipinfo_ioctl-fix-line-offset-validation.patch b/queue-4.8/gpio-gpio_get_chipinfo_ioctl-fix-line-offset-validation.patch new file mode 100644 index 00000000000..993c87be614 --- /dev/null +++ b/queue-4.8/gpio-gpio_get_chipinfo_ioctl-fix-line-offset-validation.patch @@ -0,0 +1,36 @@ +From 1f1cc4566bd9dd8d3cf19965a4b6392143618536 Mon Sep 17 00:00:00 2001 +From: Lars-Peter Clausen +Date: Tue, 18 Oct 2016 16:53:59 +0200 +Subject: gpio: GPIO_GET_CHIPINFO_IOCTL: Fix line offset validation + +From: Lars-Peter Clausen + +commit 1f1cc4566bd9dd8d3cf19965a4b6392143618536 upstream. + +The current line offset validation is off by one. Depending on the data +stored behind the descs array this can either cause undefined behavior or +disclose arbitrary, potentially sensitive, memory to the issuing userspace +application. + +Make sure that offset is within the bounds of the desc array. + +Fixes: 521a2ad6f862 ("gpio: add userspace ABI for GPIO line information") +Signed-off-by: Lars-Peter Clausen +Signed-off-by: Linus Walleij +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpio/gpiolib.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/gpio/gpiolib.c ++++ b/drivers/gpio/gpiolib.c +@@ -837,7 +837,7 @@ static long gpio_ioctl(struct file *filp + + if (copy_from_user(&lineinfo, ip, sizeof(lineinfo))) + return -EFAULT; +- if (lineinfo.line_offset > gdev->ngpio) ++ if (lineinfo.line_offset >= gdev->ngpio) + return -EINVAL; + + desc = &gdev->descs[lineinfo.line_offset]; diff --git a/queue-4.8/gpio-gpio_get_line-handle-event-_ioctl-fix-file-descriptor-leak.patch b/queue-4.8/gpio-gpio_get_line-handle-event-_ioctl-fix-file-descriptor-leak.patch new file mode 100644 index 00000000000..7159e893f67 --- /dev/null +++ b/queue-4.8/gpio-gpio_get_line-handle-event-_ioctl-fix-file-descriptor-leak.patch @@ -0,0 +1,168 @@ +From 953b956a2e6d35298e684f251bad98ea6c96f982 Mon Sep 17 00:00:00 2001 +From: Lars-Peter Clausen +Date: Mon, 24 Oct 2016 13:59:15 +0200 +Subject: gpio: GPIO_GET_LINE{HANDLE,EVENT}_IOCTL: Fix file descriptor leak + +From: Lars-Peter Clausen + +commit 953b956a2e6d35298e684f251bad98ea6c96f982 upstream. + +When allocating a new line handle or event a file is allocated that it is +associated to. The file is attached to a file descriptor of the current +process and the file descriptor is returned to userspace using +copy_to_user(). If this copy operation fails the line handle or event +allocation is aborted, all acquired resources are freed and an error is +returned. + +But the file struct is not freed and left attached to the userspace +application and even though the file descriptor number was not copied it is +trivial to guess. If a userspace application performs a IOCTL on such a +left over file descriptor it will trigger a use-after-free and if the file +descriptor is closed (latest when the application exits) a double-free is +triggered. + +anon_inode_getfd() performs 3 tasks, allocate a file struct, allocate a +file descriptor for the current process and install the file struct in the +file descriptor. As soon as the file struct is installed in the file +descriptor it is accessible by userspace (even if the IOCTL itself hasn't +completed yet), this means uninstalling the fd on the error path is not an +option, since userspace might already got a reference to the file. + +Instead anon_inode_getfd() needs to be broken into its individual steps. +The allocation of the file struct and file descriptor is done first, then +the copy_to_user() is executed and only if it succeeds the file is +installed. + +Since the file struct is reference counted it can not be just freed, but +its reference needs to be dropped, which will also call the release() +callback, which will free the state attached to the file. So in this case +the normal error cleanup path should not be taken. + +Fixes: d932cd49182f ("gpio: free handles in fringe cases") +Signed-off-by: Lars-Peter Clausen +Signed-off-by: Linus Walleij +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpio/gpiolib.c | 57 ++++++++++++++++++++++++++++++++++++++----------- + 1 file changed, 45 insertions(+), 12 deletions(-) + +--- a/drivers/gpio/gpiolib.c ++++ b/drivers/gpio/gpiolib.c +@@ -21,6 +21,7 @@ + #include + #include + #include ++#include + #include + #include + #include +@@ -421,6 +422,7 @@ static int linehandle_create(struct gpio + { + struct gpiohandle_request handlereq; + struct linehandle_state *lh; ++ struct file *file; + int fd, i, ret; + + if (copy_from_user(&handlereq, ip, sizeof(handlereq))) +@@ -497,26 +499,41 @@ static int linehandle_create(struct gpio + i--; + lh->numdescs = handlereq.lines; + +- fd = anon_inode_getfd("gpio-linehandle", +- &linehandle_fileops, +- lh, +- O_RDONLY | O_CLOEXEC); ++ fd = get_unused_fd_flags(O_RDONLY | O_CLOEXEC); + if (fd < 0) { + ret = fd; + goto out_free_descs; + } + ++ file = anon_inode_getfile("gpio-linehandle", ++ &linehandle_fileops, ++ lh, ++ O_RDONLY | O_CLOEXEC); ++ if (IS_ERR(file)) { ++ ret = PTR_ERR(file); ++ goto out_put_unused_fd; ++ } ++ + handlereq.fd = fd; + if (copy_to_user(ip, &handlereq, sizeof(handlereq))) { +- ret = -EFAULT; +- goto out_free_descs; ++ /* ++ * fput() will trigger the release() callback, so do not go onto ++ * the regular error cleanup path here. ++ */ ++ fput(file); ++ put_unused_fd(fd); ++ return -EFAULT; + } + ++ fd_install(fd, file); ++ + dev_dbg(&gdev->dev, "registered chardev handle for %d lines\n", + lh->numdescs); + + return 0; + ++out_put_unused_fd: ++ put_unused_fd(fd); + out_free_descs: + for (; i >= 0; i--) + gpiod_free(lh->descs[i]); +@@ -719,6 +736,7 @@ static int lineevent_create(struct gpio_ + struct gpioevent_request eventreq; + struct lineevent_state *le; + struct gpio_desc *desc; ++ struct file *file; + u32 offset; + u32 lflags; + u32 eflags; +@@ -813,23 +831,38 @@ static int lineevent_create(struct gpio_ + if (ret) + goto out_free_desc; + +- fd = anon_inode_getfd("gpio-event", +- &lineevent_fileops, +- le, +- O_RDONLY | O_CLOEXEC); ++ fd = get_unused_fd_flags(O_RDONLY | O_CLOEXEC); + if (fd < 0) { + ret = fd; + goto out_free_irq; + } + ++ file = anon_inode_getfile("gpio-event", ++ &lineevent_fileops, ++ le, ++ O_RDONLY | O_CLOEXEC); ++ if (IS_ERR(file)) { ++ ret = PTR_ERR(file); ++ goto out_put_unused_fd; ++ } ++ + eventreq.fd = fd; + if (copy_to_user(ip, &eventreq, sizeof(eventreq))) { +- ret = -EFAULT; +- goto out_free_irq; ++ /* ++ * fput() will trigger the release() callback, so do not go onto ++ * the regular error cleanup path here. ++ */ ++ fput(file); ++ put_unused_fd(fd); ++ return -EFAULT; + } + ++ fd_install(fd, file); ++ + return 0; + ++out_put_unused_fd: ++ put_unused_fd(fd); + out_free_irq: + free_irq(le->irq, le); + out_free_desc: diff --git a/queue-4.8/gpio-gpio_get_lineevent_ioctl-reject-invalid-line-and-event-flags.patch b/queue-4.8/gpio-gpio_get_lineevent_ioctl-reject-invalid-line-and-event-flags.patch new file mode 100644 index 00000000000..39c4d4cc436 --- /dev/null +++ b/queue-4.8/gpio-gpio_get_lineevent_ioctl-reject-invalid-line-and-event-flags.patch @@ -0,0 +1,60 @@ +From ac7dbb991ee5afc0beacce3a252dcaaa249a7786 Mon Sep 17 00:00:00 2001 +From: Lars-Peter Clausen +Date: Tue, 18 Oct 2016 16:54:06 +0200 +Subject: gpio: GPIO_GET_LINEEVENT_IOCTL: Reject invalid line and event flags + +From: Lars-Peter Clausen + +commit ac7dbb991ee5afc0beacce3a252dcaaa249a7786 upstream. + +The GPIO_GET_LINEEVENT_IOCTL currently ignores unknown or undefined +linehandle and lineevent flags. From a backwards and forwards compatibility +viewpoint it is highly desirable to reject unknown flags though. + +On one hand an application that is using newer flags and is running on +an older kernel has no way to detect if the new flags were handled +correctly if they are silently discarded. + +On the other hand an application that (accidentally) passes undefined flags +will run fine on an older kernel, but may break on a newer kernel when +these flags get defined. + +Ensure that requests that have undefined flags set are rejected with an +error, rather than silently discarding the undefined flags. + +Fixes: 61f922db7221 ("gpio: userspace ABI for reading GPIO line events") +Signed-off-by: Lars-Peter Clausen +Signed-off-by: Linus Walleij +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpio/gpiolib.c | 11 +++++++++++ + 1 file changed, 11 insertions(+) + +--- a/drivers/gpio/gpiolib.c ++++ b/drivers/gpio/gpiolib.c +@@ -554,6 +554,10 @@ struct lineevent_state { + struct mutex read_lock; + }; + ++#define GPIOEVENT_REQUEST_VALID_FLAGS \ ++ (GPIOEVENT_REQUEST_RISING_EDGE | \ ++ GPIOEVENT_REQUEST_FALLING_EDGE) ++ + static unsigned int lineevent_poll(struct file *filep, + struct poll_table_struct *wait) + { +@@ -748,6 +752,13 @@ static int lineevent_create(struct gpio_ + ret = -EINVAL; + goto out_free_label; + } ++ ++ /* Return an error if a unknown flag is set */ ++ if ((lflags & ~GPIOHANDLE_REQUEST_VALID_FLAGS) || ++ (eflags & ~GPIOEVENT_REQUEST_VALID_FLAGS)) { ++ ret = -EINVAL; ++ goto out_free_label; ++ } + + /* This is just wrong: we don't look for events on output lines */ + if (lflags & GPIOHANDLE_REQUEST_OUTPUT) { diff --git a/queue-4.8/gpio-gpio_get_lineevent_ioctl-validate-line-offset.patch b/queue-4.8/gpio-gpio_get_lineevent_ioctl-validate-line-offset.patch new file mode 100644 index 00000000000..180e689c7e6 --- /dev/null +++ b/queue-4.8/gpio-gpio_get_lineevent_ioctl-validate-line-offset.patch @@ -0,0 +1,39 @@ +From b8b0e3d303654b3bb7b31b0266c513fd6f4132ce Mon Sep 17 00:00:00 2001 +From: Lars-Peter Clausen +Date: Tue, 18 Oct 2016 16:54:03 +0200 +Subject: gpio: GPIO_GET_LINEEVENT_IOCTL: Validate line offset + +From: Lars-Peter Clausen + +commit b8b0e3d303654b3bb7b31b0266c513fd6f4132ce upstream. + +The line offset that is used as an index into the descs array is provided +by userspace and might go beyond the bounds of the array. If that happens +undefined behavior will occur. + +Make sure that the offset is within the bounds of the desc array and reject +any requests that specify a value outside of it. + +Fixes: 61f922db7221 ("gpio: userspace ABI for reading GPIO line events") +Signed-off-by: Lars-Peter Clausen +Signed-off-by: Linus Walleij +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpio/gpiolib.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/drivers/gpio/gpiolib.c ++++ b/drivers/gpio/gpiolib.c +@@ -731,6 +731,11 @@ static int lineevent_create(struct gpio_ + lflags = eventreq.handleflags; + eflags = eventreq.eventflags; + ++ if (offset >= gdev->ngpio) { ++ ret = -EINVAL; ++ goto out_free_label; ++ } ++ + /* This is just wrong: we don't look for events on output lines */ + if (lflags & GPIOHANDLE_REQUEST_OUTPUT) { + ret = -EINVAL; diff --git a/queue-4.8/gpio-gpio_get_linehandle_ioctl-reject-invalid-line-flags.patch b/queue-4.8/gpio-gpio_get_linehandle_ioctl-reject-invalid-line-flags.patch new file mode 100644 index 00000000000..d4e0020ab61 --- /dev/null +++ b/queue-4.8/gpio-gpio_get_linehandle_ioctl-reject-invalid-line-flags.patch @@ -0,0 +1,62 @@ +From e3e847c7f15a27c80f526b2a7a8d4dd7ce0960a0 Mon Sep 17 00:00:00 2001 +From: Lars-Peter Clausen +Date: Tue, 18 Oct 2016 16:54:05 +0200 +Subject: gpio: GPIO_GET_LINEHANDLE_IOCTL: Reject invalid line flags + +From: Lars-Peter Clausen + +commit e3e847c7f15a27c80f526b2a7a8d4dd7ce0960a0 upstream. + +The GPIO_GET_LINEHANDLE_IOCTL currently ignores unknown or undefined +linehandle flags. From a backwards and forwards compatibility viewpoint it +is highly desirable to reject unknown flags though. + +On one hand an application that is using newer flags and is running on +an older kernel has no way to detect if the new flags were handled +correctly if they are silently discarded. + +On the other hand an application that (accidentally) passes undefined flags +will run fine on an older kernel, but may break on a newer kernel when +these flags get defined. + +Ensure that requests that have undefined flags set are rejected with an +error, rather than silently discarding the undefined flags. + +Fixes: d7c51b47ac11 ("gpio: userspace ABI for reading/writing GPIO lines") +Signed-off-by: Lars-Peter Clausen +Signed-off-by: Linus Walleij +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpio/gpiolib.c | 13 +++++++++++++ + 1 file changed, 13 insertions(+) + +--- a/drivers/gpio/gpiolib.c ++++ b/drivers/gpio/gpiolib.c +@@ -331,6 +331,13 @@ struct linehandle_state { + u32 numdescs; + }; + ++#define GPIOHANDLE_REQUEST_VALID_FLAGS \ ++ (GPIOHANDLE_REQUEST_INPUT | \ ++ GPIOHANDLE_REQUEST_OUTPUT | \ ++ GPIOHANDLE_REQUEST_ACTIVE_LOW | \ ++ GPIOHANDLE_REQUEST_OPEN_DRAIN | \ ++ GPIOHANDLE_REQUEST_OPEN_SOURCE) ++ + static long linehandle_ioctl(struct file *filep, unsigned int cmd, + unsigned long arg) + { +@@ -448,6 +455,12 @@ static int linehandle_create(struct gpio + ret = -EINVAL; + goto out_free_descs; + } ++ ++ /* Return an error if a unknown flag is set */ ++ if (lflags & ~GPIOHANDLE_REQUEST_VALID_FLAGS) { ++ ret = -EINVAL; ++ goto out_free_descs; ++ } + + desc = &gdev->descs[offset]; + ret = gpiod_request(desc, lh->label); diff --git a/queue-4.8/gpio-gpio_get_linehandle_ioctl-validate-line-offset.patch b/queue-4.8/gpio-gpio_get_linehandle_ioctl-validate-line-offset.patch new file mode 100644 index 00000000000..87aab1264b0 --- /dev/null +++ b/queue-4.8/gpio-gpio_get_linehandle_ioctl-validate-line-offset.patch @@ -0,0 +1,39 @@ +From e405f9fcb63602d35f7a419ededa3f952a395a72 Mon Sep 17 00:00:00 2001 +From: Lars-Peter Clausen +Date: Tue, 18 Oct 2016 16:54:01 +0200 +Subject: gpio: GPIO_GET_LINEHANDLE_IOCTL: Validate line offset + +From: Lars-Peter Clausen + +commit e405f9fcb63602d35f7a419ededa3f952a395a72 upstream. + +The line offset that is used as an index into the descs array is provided +by userspace and might go beyond the bounds of the array. If that happens +undefined behavior will occur. + +Make sure that the offset is within the bounds of the desc array and reject +any requests that specify a value outside of it. + +Fixes: d7c51b47ac11 ("gpio: userspace ABI for reading/writing GPIO lines") +Signed-off-by: Lars-Peter Clausen +Signed-off-by: Linus Walleij +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpio/gpiolib.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/drivers/gpio/gpiolib.c ++++ b/drivers/gpio/gpiolib.c +@@ -442,6 +442,11 @@ static int linehandle_create(struct gpio + u32 lflags = handlereq.flags; + struct gpio_desc *desc; + ++ if (offset >= gdev->ngpio) { ++ ret = -EINVAL; ++ goto out_free_descs; ++ } ++ + desc = &gdev->descs[offset]; + ret = gpiod_request(desc, lh->label); + if (ret) diff --git a/queue-4.8/gpio-gpiohandle_get_line_values_ioctl-fix-another-information-leak.patch b/queue-4.8/gpio-gpiohandle_get_line_values_ioctl-fix-another-information-leak.patch new file mode 100644 index 00000000000..4d54afa5176 --- /dev/null +++ b/queue-4.8/gpio-gpiohandle_get_line_values_ioctl-fix-another-information-leak.patch @@ -0,0 +1,39 @@ +From d82aa4a8f2e8df9673ddb099262355da4c9b99b1 Mon Sep 17 00:00:00 2001 +From: Lars-Peter Clausen +Date: Tue, 18 Oct 2016 16:54:04 +0200 +Subject: gpio: GPIOHANDLE_GET_LINE_VALUES_IOCTL: Fix another information leak + +From: Lars-Peter Clausen + +commit d82aa4a8f2e8df9673ddb099262355da4c9b99b1 upstream. + +The GPIOHANDLE_GET_LINE_VALUES_IOCTL handler allocates a gpiohandle_data +struct on the stack and then passes it to copy_to_user(). But only the +first element of the values array in the struct is set, which leaves the +struct partially initialized. + +This exposes the previous, potentially sensitive, stack content to the +issuing userspace application. To avoid this make sure that the struct is +fully initialized. + +Cc: stable@vger.kernel.org +Fixes: 61f922db7221 ("gpio: userspace ABI for reading GPIO line events") +Signed-off-by: Lars-Peter Clausen +Signed-off-by: Linus Walleij +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpio/gpiolib.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/gpio/gpiolib.c ++++ b/drivers/gpio/gpiolib.c +@@ -645,6 +645,8 @@ static long lineevent_ioctl(struct file + if (cmd == GPIOHANDLE_GET_LINE_VALUES_IOCTL) { + int val; + ++ memset(&ghd, 0, sizeof(ghd)); ++ + val = gpiod_get_value_cansleep(le->desc); + if (val < 0) + return val; diff --git a/queue-4.8/gpio-gpiohandle_get_line_values_ioctl-fix-information-leak.patch b/queue-4.8/gpio-gpiohandle_get_line_values_ioctl-fix-information-leak.patch new file mode 100644 index 00000000000..9df4826de44 --- /dev/null +++ b/queue-4.8/gpio-gpiohandle_get_line_values_ioctl-fix-information-leak.patch @@ -0,0 +1,38 @@ +From 3eded5d83bf4e36ad78775c7ceb44a45480b0abd Mon Sep 17 00:00:00 2001 +From: Lars-Peter Clausen +Date: Tue, 18 Oct 2016 16:54:02 +0200 +Subject: gpio: GPIOHANDLE_GET_LINE_VALUES_IOCTL: Fix information leak + +From: Lars-Peter Clausen + +commit 3eded5d83bf4e36ad78775c7ceb44a45480b0abd upstream. + +The GPIOHANDLE_GET_LINE_VALUES_IOCTL handler allocates a gpiohandle_data +struct on the stack and then passes it to copy_to_user(). But depending on +the number of requested line handles the struct is only partially +initialized. + +This exposes the previous, potentially sensitive, stack content to the +issuing userspace application. To avoid this make sure that the struct is +fully initialized. + +Fixes: d7c51b47ac11 ("gpio: userspace ABI for reading/writing GPIO lines") +Signed-off-by: Lars-Peter Clausen +Signed-off-by: Linus Walleij +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpio/gpiolib.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/gpio/gpiolib.c ++++ b/drivers/gpio/gpiolib.c +@@ -342,6 +342,8 @@ static long linehandle_ioctl(struct file + if (cmd == GPIOHANDLE_GET_LINE_VALUES_IOCTL) { + int val; + ++ memset(&ghd, 0, sizeof(ghd)); ++ + /* TODO: check if descriptors are really input */ + for (i = 0; i < lh->numdescs; i++) { + val = gpiod_get_value_cansleep(lh->descs[i]); diff --git a/queue-4.8/keys-fix-short-sprintf-buffer-in-proc-keys-show-function.patch b/queue-4.8/keys-fix-short-sprintf-buffer-in-proc-keys-show-function.patch new file mode 100644 index 00000000000..de58a216e39 --- /dev/null +++ b/queue-4.8/keys-fix-short-sprintf-buffer-in-proc-keys-show-function.patch @@ -0,0 +1,74 @@ +From 03dab869b7b239c4e013ec82aea22e181e441cfc Mon Sep 17 00:00:00 2001 +From: David Howells +Date: Wed, 26 Oct 2016 15:01:54 +0100 +Subject: KEYS: Fix short sprintf buffer in /proc/keys show function + +From: David Howells + +commit 03dab869b7b239c4e013ec82aea22e181e441cfc upstream. + +This fixes CVE-2016-7042. + +Fix a short sprintf buffer in proc_keys_show(). If the gcc stack protector +is turned on, this can cause a panic due to stack corruption. + +The problem is that xbuf[] is not big enough to hold a 64-bit timeout +rendered as weeks: + + (gdb) p 0xffffffffffffffffULL/(60*60*24*7) + $2 = 30500568904943 + +That's 14 chars plus NUL, not 11 chars plus NUL. + +Expand the buffer to 16 chars. + +I think the unpatched code apparently works if the stack-protector is not +enabled because on a 32-bit machine the buffer won't be overflowed and on a +64-bit machine there's a 64-bit aligned pointer at one side and an int that +isn't checked again on the other side. + +The panic incurred looks something like: + +Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffff81352ebe +CPU: 0 PID: 1692 Comm: reproducer Not tainted 4.7.2-201.fc24.x86_64 #1 +Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 + 0000000000000086 00000000fbbd2679 ffff8800a044bc00 ffffffff813d941f + ffffffff81a28d58 ffff8800a044bc98 ffff8800a044bc88 ffffffff811b2cb6 + ffff880000000010 ffff8800a044bc98 ffff8800a044bc30 00000000fbbd2679 +Call Trace: + [] dump_stack+0x63/0x84 + [] panic+0xde/0x22a + [] ? proc_keys_show+0x3ce/0x3d0 + [] __stack_chk_fail+0x19/0x30 + [] proc_keys_show+0x3ce/0x3d0 + [] ? key_validate+0x50/0x50 + [] ? key_default_cmp+0x20/0x20 + [] seq_read+0x2cc/0x390 + [] proc_reg_read+0x42/0x70 + [] __vfs_read+0x37/0x150 + [] ? security_file_permission+0xa0/0xc0 + [] vfs_read+0x96/0x130 + [] SyS_read+0x55/0xc0 + [] entry_SYSCALL_64_fastpath+0x1a/0xa4 + +Reported-by: Ondrej Kozina +Signed-off-by: David Howells +Tested-by: Ondrej Kozina +Signed-off-by: James Morris +Signed-off-by: Greg Kroah-Hartman + +--- + security/keys/proc.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/security/keys/proc.c ++++ b/security/keys/proc.c +@@ -181,7 +181,7 @@ static int proc_keys_show(struct seq_fil + struct timespec now; + unsigned long timo; + key_ref_t key_ref, skey_ref; +- char xbuf[12]; ++ char xbuf[16]; + int rc; + + struct keyring_search_context ctx = { diff --git a/queue-4.8/keys-sort-out-big_key-initialisation.patch b/queue-4.8/keys-sort-out-big_key-initialisation.patch new file mode 100644 index 00000000000..b61144e392a --- /dev/null +++ b/queue-4.8/keys-sort-out-big_key-initialisation.patch @@ -0,0 +1,134 @@ +From 7df3e59c3d1df4f87fe874c7956ef7a3d2f4d5fb Mon Sep 17 00:00:00 2001 +From: David Howells +Date: Wed, 26 Oct 2016 15:02:01 +0100 +Subject: KEYS: Sort out big_key initialisation + +From: David Howells + +commit 7df3e59c3d1df4f87fe874c7956ef7a3d2f4d5fb upstream. + +big_key has two separate initialisation functions, one that registers the +key type and one that registers the crypto. If the key type fails to +register, there's no problem if the crypto registers successfully because +there's no way to reach the crypto except through the key type. + +However, if the key type registers successfully but the crypto does not, +big_key_rng and big_key_blkcipher may end up set to NULL - but the code +neither checks for this nor unregisters the big key key type. + +Furthermore, since the key type is registered before the crypto, it is +theoretically possible for the kernel to try adding a big_key before the +crypto is set up, leading to the same effect. + +Fix this by merging big_key_crypto_init() and big_key_init() and calling +the resulting function late. If they're going to be encrypted, we +shouldn't be creating big_keys before we have the facilities to do the +encryption available. The key type registration is also moved after the +crypto initialisation. + +The fix also includes message printing on failure. + +If the big_key type isn't correctly set up, simply doing: + + dd if=/dev/zero bs=4096 count=1 | keyctl padd big_key a @s + +ought to cause an oops. + +Fixes: 13100a72f40f5748a04017e0ab3df4cf27c809ef ('Security: Keys: Big keys stored encrypted') +Signed-off-by: David Howells +cc: Peter Hlavaty +cc: Kirill Marinushkin +cc: Artem Savkov +Signed-off-by: James Morris +Signed-off-by: Greg Kroah-Hartman + +--- + security/keys/big_key.c | 59 ++++++++++++++++++++++++++---------------------- + 1 file changed, 32 insertions(+), 27 deletions(-) + +--- a/security/keys/big_key.c ++++ b/security/keys/big_key.c +@@ -9,6 +9,7 @@ + * 2 of the Licence, or (at your option) any later version. + */ + ++#define pr_fmt(fmt) "big_key: "fmt + #include + #include + #include +@@ -341,44 +342,48 @@ error: + */ + static int __init big_key_init(void) + { +- return register_key_type(&key_type_big_key); +-} +- +-/* +- * Initialize big_key crypto and RNG algorithms +- */ +-static int __init big_key_crypto_init(void) +-{ +- int ret = -EINVAL; ++ struct crypto_skcipher *cipher; ++ struct crypto_rng *rng; ++ int ret; + +- /* init RNG */ +- big_key_rng = crypto_alloc_rng(big_key_rng_name, 0, 0); +- if (IS_ERR(big_key_rng)) { +- big_key_rng = NULL; +- return -EFAULT; ++ rng = crypto_alloc_rng(big_key_rng_name, 0, 0); ++ if (IS_ERR(rng)) { ++ pr_err("Can't alloc rng: %ld\n", PTR_ERR(rng)); ++ return PTR_ERR(rng); + } + ++ big_key_rng = rng; ++ + /* seed RNG */ +- ret = crypto_rng_reset(big_key_rng, NULL, crypto_rng_seedsize(big_key_rng)); +- if (ret) +- goto error; ++ ret = crypto_rng_reset(rng, NULL, crypto_rng_seedsize(rng)); ++ if (ret) { ++ pr_err("Can't reset rng: %d\n", ret); ++ goto error_rng; ++ } + + /* init block cipher */ +- big_key_skcipher = crypto_alloc_skcipher(big_key_alg_name, +- 0, CRYPTO_ALG_ASYNC); +- if (IS_ERR(big_key_skcipher)) { +- big_key_skcipher = NULL; +- ret = -EFAULT; +- goto error; ++ cipher = crypto_alloc_skcipher(big_key_alg_name, 0, CRYPTO_ALG_ASYNC); ++ if (IS_ERR(cipher)) { ++ ret = PTR_ERR(cipher); ++ pr_err("Can't alloc crypto: %d\n", ret); ++ goto error_rng; ++ } ++ ++ big_key_skcipher = cipher; ++ ++ ret = register_key_type(&key_type_big_key); ++ if (ret < 0) { ++ pr_err("Can't register type: %d\n", ret); ++ goto error_cipher; + } + + return 0; + +-error: ++error_cipher: ++ crypto_free_skcipher(big_key_skcipher); ++error_rng: + crypto_free_rng(big_key_rng); +- big_key_rng = NULL; + return ret; + } + +-device_initcall(big_key_init); +-late_initcall(big_key_crypto_init); ++late_initcall(big_key_init); diff --git a/queue-4.8/libxfs-clean-up-_calc_dquots_per_chunk.patch b/queue-4.8/libxfs-clean-up-_calc_dquots_per_chunk.patch new file mode 100644 index 00000000000..6c8ee8a9513 --- /dev/null +++ b/queue-4.8/libxfs-clean-up-_calc_dquots_per_chunk.patch @@ -0,0 +1,35 @@ +From 58d789678546d46d7bbd809dd7dab417c0f23655 Mon Sep 17 00:00:00 2001 +From: "Darrick J. Wong" +Date: Thu, 20 Oct 2016 15:46:18 +1100 +Subject: libxfs: clean up _calc_dquots_per_chunk + +From: Darrick J. Wong + +commit 58d789678546d46d7bbd809dd7dab417c0f23655 upstream. + +The function xfs_calc_dquots_per_chunk takes a parameter in units +of basic blocks. The kernel seems to get the units wrong, but +userspace got 'fixed' by commenting out the unnecessary conversion. +Fix both. + +Signed-off-by: Darrick J. Wong +Reviewed-by: Eric Sandeen +Signed-off-by: Dave Chinner +Signed-off-by: Greg Kroah-Hartman + +--- + fs/xfs/libxfs/xfs_dquot_buf.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +--- a/fs/xfs/libxfs/xfs_dquot_buf.c ++++ b/fs/xfs/libxfs/xfs_dquot_buf.c +@@ -191,8 +191,7 @@ xfs_dquot_buf_verify_crc( + if (mp->m_quotainfo) + ndquots = mp->m_quotainfo->qi_dqperchunk; + else +- ndquots = xfs_calc_dquots_per_chunk( +- XFS_BB_TO_FSB(mp, bp->b_length)); ++ ndquots = xfs_calc_dquots_per_chunk(bp->b_length); + + for (i = 0; i < ndquots; i++, d++) { + if (!xfs_verify_cksum((char *)d, sizeof(struct xfs_dqblk), diff --git a/queue-4.8/mm-list_lru.c-avoid-error-path-null-pointer-deref.patch b/queue-4.8/mm-list_lru.c-avoid-error-path-null-pointer-deref.patch new file mode 100644 index 00000000000..1d1f84f9b77 --- /dev/null +++ b/queue-4.8/mm-list_lru.c-avoid-error-path-null-pointer-deref.patch @@ -0,0 +1,44 @@ +From 1bc11d70b5db7c6bb1414b283d7f09b1fe1ac0d0 Mon Sep 17 00:00:00 2001 +From: Alexander Polakov +Date: Thu, 27 Oct 2016 17:46:27 -0700 +Subject: mm/list_lru.c: avoid error-path NULL pointer deref + +From: Alexander Polakov + +commit 1bc11d70b5db7c6bb1414b283d7f09b1fe1ac0d0 upstream. + +As described in https://bugzilla.kernel.org/show_bug.cgi?id=177821: + +After some analysis it seems to be that the problem is in alloc_super(). +In case list_lru_init_memcg() fails it goes into destroy_super(), which +calls list_lru_destroy(). + +And in list_lru_init() we see that in case memcg_init_list_lru() fails, +lru->node is freed, but not set NULL, which then leads list_lru_destroy() +to believe it is initialized and call memcg_destroy_list_lru(). +memcg_destroy_list_lru() in turn can access lru->node[i].memcg_lrus, +which is NULL. + +[akpm@linux-foundation.org: add comment] +Signed-off-by: Alexander Polakov +Acked-by: Vladimir Davydov +Cc: Al Viro +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + mm/list_lru.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/mm/list_lru.c ++++ b/mm/list_lru.c +@@ -554,6 +554,8 @@ int __list_lru_init(struct list_lru *lru + err = memcg_init_list_lru(lru, memcg_aware); + if (err) { + kfree(lru->node); ++ /* Do this so a list_lru_destroy() doesn't crash: */ ++ lru->node = NULL; + goto out; + } + diff --git a/queue-4.8/mm-memcontrol-do-not-recurse-in-direct-reclaim.patch b/queue-4.8/mm-memcontrol-do-not-recurse-in-direct-reclaim.patch new file mode 100644 index 00000000000..8e7315da66b --- /dev/null +++ b/queue-4.8/mm-memcontrol-do-not-recurse-in-direct-reclaim.patch @@ -0,0 +1,103 @@ +From 89a2848381b5fcd9c4d9c0cd97680e3b28730e31 Mon Sep 17 00:00:00 2001 +From: Johannes Weiner +Date: Thu, 27 Oct 2016 17:46:56 -0700 +Subject: mm: memcontrol: do not recurse in direct reclaim + +From: Johannes Weiner + +commit 89a2848381b5fcd9c4d9c0cd97680e3b28730e31 upstream. + +On 4.0, we saw a stack corruption from a page fault entering direct +memory cgroup reclaim, calling into btrfs_releasepage(), which then +tried to allocate an extent and recursed back into a kmem charge ad +nauseam: + + [...] + btrfs_releasepage+0x2c/0x30 + try_to_release_page+0x32/0x50 + shrink_page_list+0x6da/0x7a0 + shrink_inactive_list+0x1e5/0x510 + shrink_lruvec+0x605/0x7f0 + shrink_zone+0xee/0x320 + do_try_to_free_pages+0x174/0x440 + try_to_free_mem_cgroup_pages+0xa7/0x130 + try_charge+0x17b/0x830 + memcg_charge_kmem+0x40/0x80 + new_slab+0x2d9/0x5a0 + __slab_alloc+0x2fd/0x44f + kmem_cache_alloc+0x193/0x1e0 + alloc_extent_state+0x21/0xc0 + __clear_extent_bit+0x2b5/0x400 + try_release_extent_mapping+0x1a3/0x220 + __btrfs_releasepage+0x31/0x70 + btrfs_releasepage+0x2c/0x30 + try_to_release_page+0x32/0x50 + shrink_page_list+0x6da/0x7a0 + shrink_inactive_list+0x1e5/0x510 + shrink_lruvec+0x605/0x7f0 + shrink_zone+0xee/0x320 + do_try_to_free_pages+0x174/0x440 + try_to_free_mem_cgroup_pages+0xa7/0x130 + try_charge+0x17b/0x830 + mem_cgroup_try_charge+0x65/0x1c0 + handle_mm_fault+0x117f/0x1510 + __do_page_fault+0x177/0x420 + do_page_fault+0xc/0x10 + page_fault+0x22/0x30 + +On later kernels, kmem charging is opt-in rather than opt-out, and that +particular kmem allocation in btrfs_releasepage() is no longer being +charged and won't recurse and overrun the stack anymore. + +But it's not impossible for an accounted allocation to happen from the +memcg direct reclaim context, and we needed to reproduce this crash many +times before we even got a useful stack trace out of it. + +Like other direct reclaimers, mark tasks in memcg reclaim PF_MEMALLOC to +avoid recursing into any other form of direct reclaim. Then let +recursive charges from PF_MEMALLOC contexts bypass the cgroup limit. + +Link: http://lkml.kernel.org/r/20161025141050.GA13019@cmpxchg.org +Signed-off-by: Johannes Weiner +Acked-by: Michal Hocko +Cc: Vladimir Davydov +Cc: Tejun Heo +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + mm/memcontrol.c | 9 +++++++++ + mm/vmscan.c | 2 ++ + 2 files changed, 11 insertions(+) + +--- a/mm/memcontrol.c ++++ b/mm/memcontrol.c +@@ -1947,6 +1947,15 @@ retry: + current->flags & PF_EXITING)) + goto force; + ++ /* ++ * Prevent unbounded recursion when reclaim operations need to ++ * allocate memory. This might exceed the limits temporarily, ++ * but we prefer facilitating memory reclaim and getting back ++ * under the limit over triggering OOM kills in these cases. ++ */ ++ if (unlikely(current->flags & PF_MEMALLOC)) ++ goto force; ++ + if (unlikely(task_in_memcg_oom(current))) + goto nomem; + +--- a/mm/vmscan.c ++++ b/mm/vmscan.c +@@ -3048,7 +3048,9 @@ unsigned long try_to_free_mem_cgroup_pag + sc.gfp_mask, + sc.reclaim_idx); + ++ current->flags |= PF_MEMALLOC; + nr_reclaimed = do_try_to_free_pages(zonelist, &sc); ++ current->flags &= ~PF_MEMALLOC; + + trace_mm_vmscan_memcg_reclaim_end(nr_reclaimed); + diff --git a/queue-4.8/mm-slab-fix-kmemcg-cache-creation-delayed-issue.patch b/queue-4.8/mm-slab-fix-kmemcg-cache-creation-delayed-issue.patch new file mode 100644 index 00000000000..709c483d3b6 --- /dev/null +++ b/queue-4.8/mm-slab-fix-kmemcg-cache-creation-delayed-issue.patch @@ -0,0 +1,51 @@ +From 86d9f48534e800e4d62cdc1b5aaf539f4c1d47d6 Mon Sep 17 00:00:00 2001 +From: Joonsoo Kim +Date: Thu, 27 Oct 2016 17:46:18 -0700 +Subject: mm/slab: fix kmemcg cache creation delayed issue + +From: Joonsoo Kim + +commit 86d9f48534e800e4d62cdc1b5aaf539f4c1d47d6 upstream. + +There is a bug report that SLAB makes extreme load average due to over +2000 kworker thread. + + https://bugzilla.kernel.org/show_bug.cgi?id=172981 + +This issue is caused by kmemcg feature that try to create new set of +kmem_caches for each memcg. Recently, kmem_cache creation is slowed by +synchronize_sched() and futher kmem_cache creation is also delayed since +kmem_cache creation is synchronized by a global slab_mutex lock. So, +the number of kworker that try to create kmem_cache increases quietly. + +synchronize_sched() is for lockless access to node's shared array but +it's not needed when a new kmem_cache is created. So, this patch rules +out that case. + +Fixes: 801faf0db894 ("mm/slab: lockless decision to grow cache") +Link: http://lkml.kernel.org/r/1475734855-4837-1-git-send-email-iamjoonsoo.kim@lge.com +Reported-by: Doug Smythies +Tested-by: Doug Smythies +Signed-off-by: Joonsoo Kim +Cc: Christoph Lameter +Cc: Pekka Enberg +Cc: David Rientjes +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + mm/slab.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/mm/slab.c ++++ b/mm/slab.c +@@ -964,7 +964,7 @@ static int setup_kmem_cache_node(struct + * guaranteed to be valid until irq is re-enabled, because it will be + * freed after synchronize_sched(). + */ +- if (force_change) ++ if (old_shared && force_change) + synchronize_sched(); + + fail: diff --git a/queue-4.8/powerpc-64-fix-race-condition-in-setting-lock-bit-in-idle-wakeup-code.patch b/queue-4.8/powerpc-64-fix-race-condition-in-setting-lock-bit-in-idle-wakeup-code.patch new file mode 100644 index 00000000000..f30f7bfacb6 --- /dev/null +++ b/queue-4.8/powerpc-64-fix-race-condition-in-setting-lock-bit-in-idle-wakeup-code.patch @@ -0,0 +1,55 @@ +From 09b7e37b18eecc1e347f4b1a3bc863f32801f634 Mon Sep 17 00:00:00 2001 +From: Paul Mackerras +Date: Fri, 21 Oct 2016 20:04:17 +1100 +Subject: powerpc/64: Fix race condition in setting lock bit in idle/wakeup code + +From: Paul Mackerras + +commit 09b7e37b18eecc1e347f4b1a3bc863f32801f634 upstream. + +This fixes a race condition where one thread that is entering or +leaving a power-saving state can inadvertently ignore the lock bit +that was set by another thread, and potentially also clear it. +The core_idle_lock_held function is called when the lock bit is +seen to be set. It polls the lock bit until it is clear, then +does a lwarx to load the word containing the lock bit and thread +idle bits so it can be updated. However, it is possible that the +value loaded with the lwarx has the lock bit set, even though an +immediately preceding lwz loaded a value with the lock bit clear. +If this happens then we go ahead and update the word despite the +lock bit being set, and when called from pnv_enter_arch207_idle_mode, +we will subsequently clear the lock bit. + +No identifiable misbehaviour has been attributed to this race. + +This fixes it by checking the lock bit in the value loaded by the +lwarx. If it is set then we just go back and keep on polling. + +Fixes: b32aadc1a8ed ("powerpc/powernv: Fix race in updating core_idle_state") +Signed-off-by: Paul Mackerras +Signed-off-by: Michael Ellerman +Signed-off-by: Greg Kroah-Hartman + +--- + arch/powerpc/kernel/idle_book3s.S | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/arch/powerpc/kernel/idle_book3s.S ++++ b/arch/powerpc/kernel/idle_book3s.S +@@ -90,6 +90,7 @@ ALT_FTR_SECTION_END_IFSET(CPU_FTR_ARCH_3 + * Threads will spin in HMT_LOW until the lock bit is cleared. + * r14 - pointer to core_idle_state + * r15 - used to load contents of core_idle_state ++ * r9 - used as a temporary variable + */ + + core_idle_lock_held: +@@ -99,6 +100,8 @@ core_idle_lock_held: + bne 3b + HMT_MEDIUM + lwarx r15,0,r14 ++ andi. r9,r15,PNV_CORE_IDLE_LOCK_BIT ++ bne core_idle_lock_held + blr + + /* diff --git a/queue-4.8/powerpc-64-re-fix-race-condition-between-going-idle-and-entering-guest.patch b/queue-4.8/powerpc-64-re-fix-race-condition-between-going-idle-and-entering-guest.patch new file mode 100644 index 00000000000..51eef1a14a2 --- /dev/null +++ b/queue-4.8/powerpc-64-re-fix-race-condition-between-going-idle-and-entering-guest.patch @@ -0,0 +1,95 @@ +From 56c46222af0d09149fadec2a3ce9d4889de01cc6 Mon Sep 17 00:00:00 2001 +From: Paul Mackerras +Date: Fri, 21 Oct 2016 20:03:05 +1100 +Subject: powerpc/64: Re-fix race condition between going idle and entering guest + +From: Paul Mackerras + +commit 56c46222af0d09149fadec2a3ce9d4889de01cc6 upstream. + +Commit 8117ac6a6c2f ("powerpc/powernv: Switch off MMU before entering +nap/sleep/rvwinkle mode", 2014-12-10) fixed a race condition where one +thread entering a KVM guest could switch the MMU context to the guest +while another thread was still in host kernel context with the MMU on. +That commit moved the point where a thread entering a power-saving +mode set its kvm_hstate.hwthread_state field in its PACA to +KVM_HWTHREAD_IN_IDLE from a point where the MMU was on to after the +MMU had been switched off. That commit also added a comment +explaining that we have to switch to real mode before setting +hwthread_state to avoid this race. + +Nevertheless, commit 4eae2c9ae54a ("powerpc/powernv: Make +pnv_powersave_common more generic", 2016-07-08) subsequently moved +the setting of hwthread_state back to a point where the MMU is on, +thus reintroducing the race, despite the comment saying that this +should not be done being included in full in the context lines of +the patch that did it. + +This fixes the race again and adds a bigger and shoutier comment +explaining the potential race condition. + +Fixes: 4eae2c9ae54a ("powerpc/powernv: Make pnv_powersave_common more generic") +Signed-off-by: Paul Mackerras +Reviewed-by: Shreyas B. Prabhu +Signed-off-by: Michael Ellerman +Signed-off-by: Greg Kroah-Hartman + +--- + arch/powerpc/kernel/idle_book3s.S | 32 ++++++++++++++++++++++++++------ + 1 file changed, 26 insertions(+), 6 deletions(-) + +--- a/arch/powerpc/kernel/idle_book3s.S ++++ b/arch/powerpc/kernel/idle_book3s.S +@@ -163,12 +163,6 @@ _GLOBAL(pnv_powersave_common) + std r9,_MSR(r1) + std r1,PACAR1(r13) + +-#ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE +- /* Tell KVM we're entering idle */ +- li r4,KVM_HWTHREAD_IN_IDLE +- stb r4,HSTATE_HWTHREAD_STATE(r13) +-#endif +- + /* + * Go to real mode to do the nap, as required by the architecture. + * Also, we need to be in real mode before setting hwthread_state, +@@ -185,6 +179,26 @@ _GLOBAL(pnv_powersave_common) + + .globl pnv_enter_arch207_idle_mode + pnv_enter_arch207_idle_mode: ++#ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE ++ /* Tell KVM we're entering idle */ ++ li r4,KVM_HWTHREAD_IN_IDLE ++ /******************************************************/ ++ /* N O T E W E L L ! ! ! N O T E W E L L */ ++ /* The following store to HSTATE_HWTHREAD_STATE(r13) */ ++ /* MUST occur in real mode, i.e. with the MMU off, */ ++ /* and the MMU must stay off until we clear this flag */ ++ /* and test HSTATE_HWTHREAD_REQ(r13) in the system */ ++ /* reset interrupt vector in exceptions-64s.S. */ ++ /* The reason is that another thread can switch the */ ++ /* MMU to a guest context whenever this flag is set */ ++ /* to KVM_HWTHREAD_IN_IDLE, and if the MMU was on, */ ++ /* that would potentially cause this thread to start */ ++ /* executing instructions from guest memory in */ ++ /* hypervisor mode, leading to a host crash or data */ ++ /* corruption, or worse. */ ++ /******************************************************/ ++ stb r4,HSTATE_HWTHREAD_STATE(r13) ++#endif + stb r3,PACA_THREAD_IDLE_STATE(r13) + cmpwi cr3,r3,PNV_THREAD_SLEEP + bge cr3,2f +@@ -250,6 +264,12 @@ enter_winkle: + * r3 - requested stop state + */ + power_enter_stop: ++#ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE ++ /* Tell KVM we're entering idle */ ++ li r4,KVM_HWTHREAD_IN_IDLE ++ /* DO THIS IN REAL MODE! See comment above. */ ++ stb r4,HSTATE_HWTHREAD_STATE(r13) ++#endif + /* + * Check if the requested state is a deep idle state. + */ diff --git a/queue-4.8/powerpc-convert-cmp-to-cmpd-in-idle-enter-sequence.patch b/queue-4.8/powerpc-convert-cmp-to-cmpd-in-idle-enter-sequence.patch new file mode 100644 index 00000000000..7674e80f2ac --- /dev/null +++ b/queue-4.8/powerpc-convert-cmp-to-cmpd-in-idle-enter-sequence.patch @@ -0,0 +1,43 @@ +From 80f23935cadb1c654e81951f5a8b7ceae0acc1b4 Mon Sep 17 00:00:00 2001 +From: Segher Boessenkool +Date: Thu, 6 Oct 2016 13:42:19 +0000 +Subject: powerpc: Convert cmp to cmpd in idle enter sequence + +From: Segher Boessenkool + +commit 80f23935cadb1c654e81951f5a8b7ceae0acc1b4 upstream. + +PowerPC's "cmp" instruction has four operands. Normally people write +"cmpw" or "cmpd" for the second cmp operand 0 or 1. But, frequently +people forget, and write "cmp" with just three operands. + +With older binutils this is silently accepted as if this was "cmpw", +while often "cmpd" is wanted. With newer binutils GAS will complain +about this for 64-bit code. For 32-bit code it still silently assumes +"cmpw" is what is meant. + +In this instance the code comes directly from ISA v2.07, including the +cmp, but cmpd is correct. Backport to stable so that new toolchains can +build old kernels. + +Fixes: 948cf67c4726 ("powerpc: Add NAP mode support on Power7 in HV mode") +Reviewed-by: Vaidyanathan Srinivasan +Signed-off-by: Segher Boessenkool +Signed-off-by: Michael Ellerman +Signed-off-by: Greg Kroah-Hartman + +--- + arch/powerpc/include/asm/cpuidle.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/powerpc/include/asm/cpuidle.h ++++ b/arch/powerpc/include/asm/cpuidle.h +@@ -26,7 +26,7 @@ extern u64 pnv_first_deep_stop_state; + std r0,0(r1); \ + ptesync; \ + ld r0,0(r1); \ +-1: cmp cr0,r0,r0; \ ++1: cmpd cr0,r0,r0; \ + bne 1b; \ + IDLE_INST; \ + b . diff --git a/queue-4.8/powerpc-mm-radix-use-tlbiel-only-if-we-ever-ran-on-the-current-cpu.patch b/queue-4.8/powerpc-mm-radix-use-tlbiel-only-if-we-ever-ran-on-the-current-cpu.patch new file mode 100644 index 00000000000..d9f84039cf6 --- /dev/null +++ b/queue-4.8/powerpc-mm-radix-use-tlbiel-only-if-we-ever-ran-on-the-current-cpu.patch @@ -0,0 +1,99 @@ +From bd77c4498616e27d5725b5959d880ce2272fefa9 Mon Sep 17 00:00:00 2001 +From: "Aneesh Kumar K.V" +Date: Mon, 24 Oct 2016 08:50:43 +0530 +Subject: powerpc/mm/radix: Use tlbiel only if we ever ran on the current cpu + +From: Aneesh Kumar K.V + +commit bd77c4498616e27d5725b5959d880ce2272fefa9 upstream. + +Before this patch, we used tlbiel, if we ever ran only on this core. +That was mostly derived from the nohash usage of the same. But is +incorrect, the ISA 3.0 clarifies tlbiel such that: + +"All TLB entries that have all of the following properties are made +invalid on the thread executing the tlbiel instruction" + +ie. tlbiel only invalidates TLB entries on the current thread. So if the +mm has been used on any other thread (aka. cpu) then we must broadcast +the invalidate. + +This bug could lead to invalid TLB entries if a program runs on multiple +threads of a core. + +Hence use tlbiel, if we only ever ran on only the current cpu. + +Fixes: 1a472c9dba6b ("powerpc/mm/radix: Add tlbflush routines") +Signed-off-by: Aneesh Kumar K.V +Signed-off-by: Michael Ellerman +Signed-off-by: Greg Kroah-Hartman + +--- + arch/powerpc/include/asm/tlb.h | 12 ++++++++++++ + arch/powerpc/mm/tlb-radix.c | 8 ++++---- + 2 files changed, 16 insertions(+), 4 deletions(-) + +--- a/arch/powerpc/include/asm/tlb.h ++++ b/arch/powerpc/include/asm/tlb.h +@@ -52,11 +52,23 @@ static inline int mm_is_core_local(struc + return cpumask_subset(mm_cpumask(mm), + topology_sibling_cpumask(smp_processor_id())); + } ++ ++static inline int mm_is_thread_local(struct mm_struct *mm) ++{ ++ return cpumask_equal(mm_cpumask(mm), ++ cpumask_of(smp_processor_id())); ++} ++ + #else + static inline int mm_is_core_local(struct mm_struct *mm) + { + return 1; + } ++ ++static inline int mm_is_thread_local(struct mm_struct *mm) ++{ ++ return 1; ++} + #endif + + #endif /* __KERNEL__ */ +--- a/arch/powerpc/mm/tlb-radix.c ++++ b/arch/powerpc/mm/tlb-radix.c +@@ -175,7 +175,7 @@ void radix__flush_tlb_mm(struct mm_struc + if (unlikely(pid == MMU_NO_CONTEXT)) + goto no_context; + +- if (!mm_is_core_local(mm)) { ++ if (!mm_is_thread_local(mm)) { + int lock_tlbie = !mmu_has_feature(MMU_FTR_LOCKLESS_TLBIE); + + if (lock_tlbie) +@@ -201,7 +201,7 @@ void radix__flush_tlb_pwc(struct mmu_gat + if (unlikely(pid == MMU_NO_CONTEXT)) + goto no_context; + +- if (!mm_is_core_local(mm)) { ++ if (!mm_is_thread_local(mm)) { + int lock_tlbie = !mmu_has_feature(MMU_FTR_LOCKLESS_TLBIE); + + if (lock_tlbie) +@@ -226,7 +226,7 @@ void radix__flush_tlb_page_psize(struct + pid = mm ? mm->context.id : 0; + if (unlikely(pid == MMU_NO_CONTEXT)) + goto bail; +- if (!mm_is_core_local(mm)) { ++ if (!mm_is_thread_local(mm)) { + int lock_tlbie = !mmu_has_feature(MMU_FTR_LOCKLESS_TLBIE); + + if (lock_tlbie) +@@ -321,7 +321,7 @@ void radix__flush_tlb_range_psize(struct + { + unsigned long pid; + unsigned long addr; +- int local = mm_is_core_local(mm); ++ int local = mm_is_thread_local(mm); + unsigned long ap = mmu_get_ap(psize); + int lock_tlbie = !mmu_has_feature(MMU_FTR_LOCKLESS_TLBIE); + unsigned long page_size = 1UL << mmu_psize_defs[psize].shift; diff --git a/queue-4.8/security-keys-make-big_keys-dependent-on-stdrng.patch b/queue-4.8/security-keys-make-big_keys-dependent-on-stdrng.patch new file mode 100644 index 00000000000..2efdd2adf64 --- /dev/null +++ b/queue-4.8/security-keys-make-big_keys-dependent-on-stdrng.patch @@ -0,0 +1,37 @@ +From 31e6ec4519c0fe0ee4a2f6ba3ab278e9506b9500 Mon Sep 17 00:00:00 2001 +From: Artem Savkov +Date: Wed, 26 Oct 2016 15:02:09 +0100 +Subject: security/keys: make BIG_KEYS dependent on stdrng. + +From: Artem Savkov + +commit 31e6ec4519c0fe0ee4a2f6ba3ab278e9506b9500 upstream. + +Since BIG_KEYS can't be compiled as module it requires one of the "stdrng" +providers to be compiled into kernel. Otherwise big_key_crypto_init() fails +on crypto_alloc_rng step and next dereference of big_key_skcipher (e.g. in +big_key_preparse()) results in a NULL pointer dereference. + +Fixes: 13100a72f40f5748a04017e0ab3df4cf27c809ef ('Security: Keys: Big keys stored encrypted') +Signed-off-by: Artem Savkov +Signed-off-by: David Howells +cc: Stephan Mueller +cc: Kirill Marinushkin +Signed-off-by: James Morris +Signed-off-by: Greg Kroah-Hartman + +--- + security/keys/Kconfig | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/security/keys/Kconfig ++++ b/security/keys/Kconfig +@@ -41,7 +41,7 @@ config BIG_KEYS + bool "Large payload keys" + depends on KEYS + depends on TMPFS +- select CRYPTO ++ depends on (CRYPTO_ANSI_CPRNG = y || CRYPTO_DRBG = y) + select CRYPTO_AES + select CRYPTO_ECB + select CRYPTO_RNG diff --git a/queue-4.8/series b/queue-4.8/series index def6540c0d6..e9883abd403 100644 --- a/queue-4.8/series +++ b/queue-4.8/series @@ -6,3 +6,37 @@ drm-dp-mst-clear-port-pdt-when-tearing-down-the-i2c-adapter.patch spi-fsl-espi-avoid-processing-uninitalized-data-on-error.patch spi-mark-device-nodes-only-in-case-of-successful-instantiation.patch h8300-fix-syscall-restarting.patch +gpio-acpi-fix-returned-error-from-acpi_dev_gpio_irq_get.patch +gpio-gpio_get_chipinfo_ioctl-fix-line-offset-validation.patch +gpio-gpio_get_chipinfo_ioctl-fix-information-leak.patch +gpio-gpio_get_linehandle_ioctl-validate-line-offset.patch +gpio-gpiohandle_get_line_values_ioctl-fix-information-leak.patch +gpio-gpio_get_lineevent_ioctl-validate-line-offset.patch +gpio-gpio_get_linehandle_ioctl-reject-invalid-line-flags.patch +gpio-gpio_get_lineevent_ioctl-reject-invalid-line-and-event-flags.patch +gpio-gpiohandle_get_line_values_ioctl-fix-another-information-leak.patch +gpio-gpio_get_line-handle-event-_ioctl-fix-file-descriptor-leak.patch +libxfs-clean-up-_calc_dquots_per_chunk.patch +mm-list_lru.c-avoid-error-path-null-pointer-deref.patch +mm-slab-fix-kmemcg-cache-creation-delayed-issue.patch +mm-memcontrol-do-not-recurse-in-direct-reclaim.patch +thermal-powerclamp-correct-cpu-support-check.patch +keys-fix-short-sprintf-buffer-in-proc-keys-show-function.patch +keys-sort-out-big_key-initialisation.patch +security-keys-make-big_keys-dependent-on-stdrng.patch +device-dax-fix-percpu_ref_exit-ordering.patch +alsa-usb-audio-add-quirk-for-syntek-stk1160.patch +alsa-seq-fix-time-account-regression.patch +alsa-hda-allow-40-bit-dma-mask-for-nvidia-devices.patch +alsa-hda-adding-a-new-group-of-pin-cfg-into-alc295-pin-quirk-table.patch +alsa-hda-fix-surround-output-pins-for-asrock-b150m-mobo.patch +alsa-hda-fix-headset-mic-detection-problem-for-two-dell-laptops.patch +android-binder-add-strong-ref-checks.patch +android-binder-clear-binder-and-cookie-when-setting-handle-in-flat-binder-struct.patch +cxl-fix-leaking-pid-refs-in-some-error-paths.patch +btrfs-fix-races-on-root_log_ctx-lists.patch +powerpc-convert-cmp-to-cmpd-in-idle-enter-sequence.patch +powerpc-mm-radix-use-tlbiel-only-if-we-ever-ran-on-the-current-cpu.patch +powerpc-64-re-fix-race-condition-between-going-idle-and-entering-guest.patch +powerpc-64-fix-race-condition-in-setting-lock-bit-in-idle-wakeup-code.patch +x86-microcode-amd-fix-more-fallout-from-config_randomize_memory-y.patch diff --git a/queue-4.8/thermal-powerclamp-correct-cpu-support-check.patch b/queue-4.8/thermal-powerclamp-correct-cpu-support-check.patch new file mode 100644 index 00000000000..06ee81ce850 --- /dev/null +++ b/queue-4.8/thermal-powerclamp-correct-cpu-support-check.patch @@ -0,0 +1,52 @@ +From 3105f234e0aba43e44e277c20f9b32ee8add43d4 Mon Sep 17 00:00:00 2001 +From: Eric Ernst +Date: Thu, 6 Oct 2016 08:56:49 -0700 +Subject: thermal/powerclamp: correct cpu support check + +From: Eric Ernst + +commit 3105f234e0aba43e44e277c20f9b32ee8add43d4 upstream. + +Initial logic for checking CPU match resulted in OR of CPU features +rather than the intended AND. + +Updated to use boot_cpu_has macro rather than x86_match_cpu. + +In addition, MWAIT is the only required CPU feature for idle +injection to work. Drop other feature requirements since they are +only needed for optimal efficiency. + +Signed-off-by: Eric Ernst +Acked-by: Jacob Pan +Signed-off-by: Zhang Rui +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/thermal/intel_powerclamp.c | 14 ++------------ + 1 file changed, 2 insertions(+), 12 deletions(-) + +--- a/drivers/thermal/intel_powerclamp.c ++++ b/drivers/thermal/intel_powerclamp.c +@@ -669,20 +669,10 @@ static struct thermal_cooling_device_ops + .set_cur_state = powerclamp_set_cur_state, + }; + +-static const struct x86_cpu_id intel_powerclamp_ids[] __initconst = { +- { X86_VENDOR_INTEL, X86_FAMILY_ANY, X86_MODEL_ANY, X86_FEATURE_MWAIT }, +- { X86_VENDOR_INTEL, X86_FAMILY_ANY, X86_MODEL_ANY, X86_FEATURE_ARAT }, +- { X86_VENDOR_INTEL, X86_FAMILY_ANY, X86_MODEL_ANY, X86_FEATURE_NONSTOP_TSC }, +- { X86_VENDOR_INTEL, X86_FAMILY_ANY, X86_MODEL_ANY, X86_FEATURE_CONSTANT_TSC}, +- {} +-}; +-MODULE_DEVICE_TABLE(x86cpu, intel_powerclamp_ids); +- + static int __init powerclamp_probe(void) + { +- if (!x86_match_cpu(intel_powerclamp_ids)) { +- pr_err("Intel powerclamp does not run on family %d model %d\n", +- boot_cpu_data.x86, boot_cpu_data.x86_model); ++ if (!boot_cpu_has(X86_FEATURE_MWAIT)) { ++ pr_err("CPU does not support MWAIT"); + return -ENODEV; + } + diff --git a/queue-4.8/x86-microcode-amd-fix-more-fallout-from-config_randomize_memory-y.patch b/queue-4.8/x86-microcode-amd-fix-more-fallout-from-config_randomize_memory-y.patch new file mode 100644 index 00000000000..02375d60006 --- /dev/null +++ b/queue-4.8/x86-microcode-amd-fix-more-fallout-from-config_randomize_memory-y.patch @@ -0,0 +1,65 @@ +From 1c27f646b18fb56308dff82784ca61951bad0b48 Mon Sep 17 00:00:00 2001 +From: Borislav Petkov +Date: Thu, 27 Oct 2016 14:36:23 +0200 +Subject: x86/microcode/AMD: Fix more fallout from CONFIG_RANDOMIZE_MEMORY=y + +From: Borislav Petkov + +commit 1c27f646b18fb56308dff82784ca61951bad0b48 upstream. + +We needed the physical address of the container in order to compute the +offset within the relocated ramdisk. And we did this by doing __pa() on +the virtual address. + +However, __pa() does checks whether the physical address is within +PAGE_OFFSET and __START_KERNEL_map - see __phys_addr() - which fail +if we have CONFIG_RANDOMIZE_MEMORY enabled: we feed a virtual address +which *doesn't* have the randomization offset into a function which uses +PAGE_OFFSET which *does* have that offset. + +This makes this check fire: + + VIRTUAL_BUG_ON((x > y) || !phys_addr_valid(x)); + ^^^^^^ + +due to the randomization offset. + +The fix is as simple as using __pa_nodebug() because we do that +randomization offset accounting later in that function ourselves. + +Reported-by: Bob Peterson +Tested-by: Bob Peterson +Signed-off-by: Borislav Petkov +Cc: Andreas Gruenbacher +Cc: Andy Lutomirski +Cc: Andy Lutomirski +Cc: Borislav Petkov +Cc: Brian Gerst +Cc: Denys Vlasenko +Cc: H. Peter Anvin +Cc: Josh Poimboeuf +Cc: Linus Torvalds +Cc: Mel Gorman +Cc: Peter Zijlstra +Cc: Steven Whitehouse +Cc: Thomas Gleixner +Cc: linux-mm +Link: http://lkml.kernel.org/r/20161027123623.j2jri5bandimboff@pd.tnic +Signed-off-by: Ingo Molnar +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/cpu/microcode/amd.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/x86/kernel/cpu/microcode/amd.c ++++ b/arch/x86/kernel/cpu/microcode/amd.c +@@ -429,7 +429,7 @@ int __init save_microcode_in_initrd_amd( + * We need the physical address of the container for both bitness since + * boot_params.hdr.ramdisk_image is a physical address. + */ +- cont = __pa(container); ++ cont = __pa_nodebug(container); + cont_va = container; + #endif +