From: Greg Kroah-Hartman Date: Mon, 24 Apr 2017 08:02:40 +0000 (+0100) Subject: 4.4-stable patches X-Git-Tag: v4.4.64~7 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=ed9b2c048314c0b7478d428628cd36650c673ac9;p=thirdparty%2Fkernel%2Fstable-queue.git 4.4-stable patches added patches: acpi-power-avoid-maybe-uninitialized-warning.patch input-elantech-add-fujitsu-lifebook-e547-to-force-crc_enabled.patch mac80211-reject-tods-broadcast-data-frames.patch mmc-sdhci-esdhc-imx-increase-the-pad-i-o-drive-strength-for-ddr50-card.patch powerpc-kprobe-fix-oops-when-kprobed-on-stdu-instruction.patch ubi-upd-always-flush-after-prepared-for-an-update.patch --- diff --git a/queue-4.4/acpi-power-avoid-maybe-uninitialized-warning.patch b/queue-4.4/acpi-power-avoid-maybe-uninitialized-warning.patch new file mode 100644 index 00000000000..0563f519b63 --- /dev/null +++ b/queue-4.4/acpi-power-avoid-maybe-uninitialized-warning.patch @@ -0,0 +1,45 @@ +From fe8c470ab87d90e4b5115902dd94eced7e3305c3 Mon Sep 17 00:00:00 2001 +From: Arnd Bergmann +Date: Wed, 19 Apr 2017 19:47:04 +0200 +Subject: ACPI / power: Avoid maybe-uninitialized warning + +From: Arnd Bergmann + +commit fe8c470ab87d90e4b5115902dd94eced7e3305c3 upstream. + +gcc -O2 cannot always prove that the loop in acpi_power_get_inferred_state() +is enterered at least once, so it assumes that cur_state might not get +initialized: + +drivers/acpi/power.c: In function 'acpi_power_get_inferred_state': +drivers/acpi/power.c:222:9: error: 'cur_state' may be used uninitialized in this function [-Werror=maybe-uninitialized] + +This sets the variable to zero at the start of the loop, to ensure that +there is well-defined behavior even for an empty list. This gets rid of +the warning. + +The warning first showed up when the -Os flag got removed in a bug fix +patch in linux-4.11-rc5. + +I would suggest merging this addon patch on top of that bug fix to avoid +introducing a new warning in the stable kernels. + +Fixes: 61b79e16c68d (ACPI: Fix incompatibility with mcount-based function graph tracing) +Signed-off-by: Arnd Bergmann +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/acpi/power.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/acpi/power.c ++++ b/drivers/acpi/power.c +@@ -200,6 +200,7 @@ static int acpi_power_get_list_state(str + return -EINVAL; + + /* The state of the list is 'on' IFF all resources are 'on'. */ ++ cur_state = 0; + list_for_each_entry(entry, list, node) { + struct acpi_power_resource *resource = entry->resource; + acpi_handle handle = resource->device.handle; diff --git a/queue-4.4/input-elantech-add-fujitsu-lifebook-e547-to-force-crc_enabled.patch b/queue-4.4/input-elantech-add-fujitsu-lifebook-e547-to-force-crc_enabled.patch new file mode 100644 index 00000000000..68645951339 --- /dev/null +++ b/queue-4.4/input-elantech-add-fujitsu-lifebook-e547-to-force-crc_enabled.patch @@ -0,0 +1,49 @@ +From 704de489e0e3640a2ee2d0daf173e9f7375582ba Mon Sep 17 00:00:00 2001 +From: Thorsten Leemhuis +Date: Tue, 18 Apr 2017 11:14:28 -0700 +Subject: Input: elantech - add Fujitsu Lifebook E547 to force crc_enabled + +From: Thorsten Leemhuis + +commit 704de489e0e3640a2ee2d0daf173e9f7375582ba upstream. + +Temporary got a Lifebook E547 into my hands and noticed the touchpad +only works after running: + + echo "1" > /sys/devices/platform/i8042/serio2/crc_enabled + +Add it to the list of machines that need this workaround. + +Signed-off-by: Thorsten Leemhuis +Reviewed-by: Ulrik De Bie +Signed-off-by: Dmitry Torokhov +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/input/mouse/elantech.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +--- a/drivers/input/mouse/elantech.c ++++ b/drivers/input/mouse/elantech.c +@@ -1122,6 +1122,7 @@ static int elantech_get_resolution_v4(st + * Asus UX32VD 0x361f02 00, 15, 0e clickpad + * Avatar AVIU-145A2 0x361f00 ? clickpad + * Fujitsu LIFEBOOK E544 0x470f00 d0, 12, 09 2 hw buttons ++ * Fujitsu LIFEBOOK E547 0x470f00 50, 12, 09 2 hw buttons + * Fujitsu LIFEBOOK E554 0x570f01 40, 14, 0c 2 hw buttons + * Fujitsu T725 0x470f01 05, 12, 09 2 hw buttons + * Fujitsu H730 0x570f00 c0, 14, 0c 3 hw buttons (**) +@@ -1528,6 +1529,13 @@ static const struct dmi_system_id elante + }, + }, + { ++ /* Fujitsu LIFEBOOK E547 does not work with crc_enabled == 0 */ ++ .matches = { ++ DMI_MATCH(DMI_SYS_VENDOR, "FUJITSU"), ++ DMI_MATCH(DMI_PRODUCT_NAME, "LIFEBOOK E547"), ++ }, ++ }, ++ { + /* Fujitsu LIFEBOOK E554 does not work with crc_enabled == 0 */ + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "FUJITSU"), diff --git a/queue-4.4/mac80211-reject-tods-broadcast-data-frames.patch b/queue-4.4/mac80211-reject-tods-broadcast-data-frames.patch new file mode 100644 index 00000000000..bc0b508e01e --- /dev/null +++ b/queue-4.4/mac80211-reject-tods-broadcast-data-frames.patch @@ -0,0 +1,63 @@ +From 3018e947d7fd536d57e2b550c33e456d921fff8c Mon Sep 17 00:00:00 2001 +From: Johannes Berg +Date: Thu, 20 Apr 2017 21:32:16 +0200 +Subject: mac80211: reject ToDS broadcast data frames + +From: Johannes Berg + +commit 3018e947d7fd536d57e2b550c33e456d921fff8c upstream. + +AP/AP_VLAN modes don't accept any real 802.11 multicast data +frames, but since they do need to accept broadcast management +frames the same is currently permitted for data frames. This +opens a security problem because such frames would be decrypted +with the GTK, and could even contain unicast L3 frames. + +Since the spec says that ToDS frames must always have the BSSID +as the RA (addr1), reject any other data frames. + +The problem was originally reported in "Predicting, Decrypting, +and Abusing WPA2/802.11 Group Keys" at usenix +https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/vanhoef +and brought to my attention by Jouni. + +Reported-by: Jouni Malinen +Signed-off-by: Johannes Berg +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +-- + +--- + net/mac80211/rx.c | 21 +++++++++++++++++++++ + 1 file changed, 21 insertions(+) + +--- a/net/mac80211/rx.c ++++ b/net/mac80211/rx.c +@@ -3396,6 +3396,27 @@ static bool ieee80211_accept_frame(struc + !ether_addr_equal(bssid, hdr->addr1)) + return false; + } ++ ++ /* ++ * 802.11-2016 Table 9-26 says that for data frames, A1 must be ++ * the BSSID - we've checked that already but may have accepted ++ * the wildcard (ff:ff:ff:ff:ff:ff). ++ * ++ * It also says: ++ * The BSSID of the Data frame is determined as follows: ++ * a) If the STA is contained within an AP or is associated ++ * with an AP, the BSSID is the address currently in use ++ * by the STA contained in the AP. ++ * ++ * So we should not accept data frames with an address that's ++ * multicast. ++ * ++ * Accepting it also opens a security problem because stations ++ * could encrypt it with the GTK and inject traffic that way. ++ */ ++ if (ieee80211_is_data(hdr->frame_control) && multicast) ++ return false; ++ + return true; + case NL80211_IFTYPE_WDS: + if (bssid || !ieee80211_is_data(hdr->frame_control)) diff --git a/queue-4.4/mmc-sdhci-esdhc-imx-increase-the-pad-i-o-drive-strength-for-ddr50-card.patch b/queue-4.4/mmc-sdhci-esdhc-imx-increase-the-pad-i-o-drive-strength-for-ddr50-card.patch new file mode 100644 index 00000000000..3eed4abb542 --- /dev/null +++ b/queue-4.4/mmc-sdhci-esdhc-imx-increase-the-pad-i-o-drive-strength-for-ddr50-card.patch @@ -0,0 +1,40 @@ +From 9f327845358d3dd0d8a5a7a5436b0aa5c432e757 Mon Sep 17 00:00:00 2001 +From: Haibo Chen +Date: Wed, 19 Apr 2017 10:53:51 +0800 +Subject: mmc: sdhci-esdhc-imx: increase the pad I/O drive strength for DDR50 card + +From: Haibo Chen + +commit 9f327845358d3dd0d8a5a7a5436b0aa5c432e757 upstream. + +Currently for DDR50 card, it need tuning in default. We meet tuning fail +issue for DDR50 card and some data CRC error when DDR50 sd card works. + +This is because the default pad I/O drive strength can't make sure DDR50 +card work stable. So increase the pad I/O drive strength for DDR50 card, +and use pins_100mhz. + +This fixes DDR50 card support for IMX since DDR50 tuning was enabled from +commit 9faac7b95ea4 ("mmc: sdhci: enable tuning for DDR50") + +Tested-and-reported-by: Tim Harvey +Signed-off-by: Haibo Chen +Acked-by: Dong Aisheng +Acked-by: Adrian Hunter +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mmc/host/sdhci-esdhc-imx.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/mmc/host/sdhci-esdhc-imx.c ++++ b/drivers/mmc/host/sdhci-esdhc-imx.c +@@ -804,6 +804,7 @@ static int esdhc_change_pinstate(struct + + switch (uhs) { + case MMC_TIMING_UHS_SDR50: ++ case MMC_TIMING_UHS_DDR50: + pinctrl = imx_data->pins_100mhz; + break; + case MMC_TIMING_UHS_SDR104: diff --git a/queue-4.4/powerpc-kprobe-fix-oops-when-kprobed-on-stdu-instruction.patch b/queue-4.4/powerpc-kprobe-fix-oops-when-kprobed-on-stdu-instruction.patch new file mode 100644 index 00000000000..a7126c47cf3 --- /dev/null +++ b/queue-4.4/powerpc-kprobe-fix-oops-when-kprobed-on-stdu-instruction.patch @@ -0,0 +1,64 @@ +From 9e1ba4f27f018742a1aa95d11e35106feba08ec1 Mon Sep 17 00:00:00 2001 +From: Ravi Bangoria +Date: Tue, 11 Apr 2017 10:38:13 +0530 +Subject: powerpc/kprobe: Fix oops when kprobed on 'stdu' instruction + +From: Ravi Bangoria + +commit 9e1ba4f27f018742a1aa95d11e35106feba08ec1 upstream. + +If we set a kprobe on a 'stdu' instruction on powerpc64, we see a kernel +OOPS: + + Bad kernel stack pointer cd93c840 at c000000000009868 + Oops: Bad kernel stack pointer, sig: 6 [#1] + ... + GPR00: c000001fcd93cb30 00000000cd93c840 c0000000015c5e00 00000000cd93c840 + ... + NIP [c000000000009868] resume_kernel+0x2c/0x58 + LR [c000000000006208] program_check_common+0x108/0x180 + +On a 64-bit system when the user probes on a 'stdu' instruction, the kernel does +not emulate actual store in emulate_step() because it may corrupt the exception +frame. So the kernel does the actual store operation in exception return code +i.e. resume_kernel(). + +resume_kernel() loads the saved stack pointer from memory using lwz, which only +loads the low 32-bits of the address, causing the kernel crash. + +Fix this by loading the 64-bit value instead. + +Fixes: be96f63375a1 ("powerpc: Split out instruction analysis part of emulate_step()") +Signed-off-by: Ravi Bangoria +Reviewed-by: Naveen N. Rao +Reviewed-by: Ananth N Mavinakayanahalli +[mpe: Change log massage, add stable tag] +Signed-off-by: Michael Ellerman +Signed-off-by: Greg Kroah-Hartman + +--- + arch/powerpc/kernel/entry_64.S | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/arch/powerpc/kernel/entry_64.S ++++ b/arch/powerpc/kernel/entry_64.S +@@ -716,7 +716,7 @@ resume_kernel: + + addi r8,r1,INT_FRAME_SIZE /* Get the kprobed function entry */ + +- lwz r3,GPR1(r1) ++ ld r3,GPR1(r1) + subi r3,r3,INT_FRAME_SIZE /* dst: Allocate a trampoline exception frame */ + mr r4,r1 /* src: current exception frame */ + mr r1,r3 /* Reroute the trampoline frame to r1 */ +@@ -730,8 +730,8 @@ resume_kernel: + addi r6,r6,8 + bdnz 2b + +- /* Do real store operation to complete stwu */ +- lwz r5,GPR1(r1) ++ /* Do real store operation to complete stdu */ ++ ld r5,GPR1(r1) + std r8,0(r5) + + /* Clear _TIF_EMULATE_STACK_STORE flag */ diff --git a/queue-4.4/series b/queue-4.4/series index b5fb7186d8b..7454d40e577 100644 --- a/queue-4.4/series +++ b/queue-4.4/series @@ -10,3 +10,9 @@ drivers-hv-don-t-leak-memory-in-vmbus_establish_gpadl.patch drivers-hv-get-rid-of-timeout-in-vmbus_open.patch drivers-hv-vmbus-reduce-the-delay-between-retries-in-vmbus_post_msg.patch vsock-detach-qp-check-should-filter-out-non-matching-qps.patch +input-elantech-add-fujitsu-lifebook-e547-to-force-crc_enabled.patch +acpi-power-avoid-maybe-uninitialized-warning.patch +mmc-sdhci-esdhc-imx-increase-the-pad-i-o-drive-strength-for-ddr50-card.patch +mac80211-reject-tods-broadcast-data-frames.patch +ubi-upd-always-flush-after-prepared-for-an-update.patch +powerpc-kprobe-fix-oops-when-kprobed-on-stdu-instruction.patch diff --git a/queue-4.4/ubi-upd-always-flush-after-prepared-for-an-update.patch b/queue-4.4/ubi-upd-always-flush-after-prepared-for-an-update.patch new file mode 100644 index 00000000000..a2b306c0fbc --- /dev/null +++ b/queue-4.4/ubi-upd-always-flush-after-prepared-for-an-update.patch @@ -0,0 +1,64 @@ +From 9cd9a21ce070be8a918ffd3381468315a7a76ba6 Mon Sep 17 00:00:00 2001 +From: Sebastian Siewior +Date: Wed, 22 Feb 2017 17:15:21 +0100 +Subject: ubi/upd: Always flush after prepared for an update + +From: Sebastian Siewior + +commit 9cd9a21ce070be8a918ffd3381468315a7a76ba6 upstream. + +In commit 6afaf8a484cb ("UBI: flush wl before clearing update marker") I +managed to trigger and fix a similar bug. Now here is another version of +which I assumed it wouldn't matter back then but it turns out UBI has a +check for it and will error out like this: + +|ubi0 warning: validate_vid_hdr: inconsistent used_ebs +|ubi0 error: validate_vid_hdr: inconsistent VID header at PEB 592 + +All you need to trigger this is? "ubiupdatevol /dev/ubi0_0 file" + a +powercut in the middle of the operation. +ubi_start_update() sets the update-marker and puts all EBs on the erase +list. After that userland can proceed to write new data while the old EB +aren't erased completely. A powercut at this point is usually not that +much of a tragedy. UBI won't give read access to the static volume +because it has the update marker. It will most likely set the corrupted +flag because it misses some EBs. +So we are all good. Unless the size of the image that has been written +differs from the old image in the magnitude of at least one EB. In that +case UBI will find two different values for `used_ebs' and refuse to +attach the image with the error message mentioned above. + +So in order not to get in the situation, the patch will ensure that we +wait until everything is removed before it tries to write any data. +The alternative would be to detect such a case and remove all EBs at the +attached time after we processed the volume-table and see the +update-marker set. The patch looks bigger and I doubt it is worth it +since usually the write() will wait from time to time for a new EB since +usually there not that many spare EB that can be used. + +Signed-off-by: Sebastian Andrzej Siewior +Signed-off-by: Richard Weinberger +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mtd/ubi/upd.c | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +--- a/drivers/mtd/ubi/upd.c ++++ b/drivers/mtd/ubi/upd.c +@@ -148,11 +148,11 @@ int ubi_start_update(struct ubi_device * + return err; + } + +- if (bytes == 0) { +- err = ubi_wl_flush(ubi, UBI_ALL, UBI_ALL); +- if (err) +- return err; ++ err = ubi_wl_flush(ubi, UBI_ALL, UBI_ALL); ++ if (err) ++ return err; + ++ if (bytes == 0) { + err = clear_update_marker(ubi, vol, 0); + if (err) + return err;