From: Greg Kroah-Hartman Date: Fri, 31 Jul 2015 01:24:47 +0000 (-0700) Subject: 3.10-stable patches X-Git-Tag: v4.1.4~14 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=1192723d4059ee87391c3bb1c46428d6a13c887d;p=thirdparty%2Fkernel%2Fstable-queue.git 3.10-stable patches added patches: __bitmap_parselist-fix-bug-in-empty-string-handling.patch mac80211-prevent-possible-crypto-tx-tailroom-corruption.patch mmc-card-fixup-request-missing-in-mmc_blk_issue_rw_rq.patch --- diff --git a/queue-3.10/__bitmap_parselist-fix-bug-in-empty-string-handling.patch b/queue-3.10/__bitmap_parselist-fix-bug-in-empty-string-handling.patch new file mode 100644 index 00000000000..53d2ebe7cf6 --- /dev/null +++ b/queue-3.10/__bitmap_parselist-fix-bug-in-empty-string-handling.patch @@ -0,0 +1,82 @@ +From 2528a8b8f457d7432552d0e2b6f0f4046bb702f4 Mon Sep 17 00:00:00 2001 +From: Chris Metcalf +Date: Thu, 25 Jun 2015 15:02:08 -0700 +Subject: __bitmap_parselist: fix bug in empty string handling + +From: Chris Metcalf + +commit 2528a8b8f457d7432552d0e2b6f0f4046bb702f4 upstream. + +bitmap_parselist("", &mask, nmaskbits) will erroneously set bit zero in +the mask. The same bug is visible in cpumask_parselist() since it is +layered on top of the bitmask code, e.g. if you boot with "isolcpus=", +you will actually end up with cpu zero isolated. + +The bug was introduced in commit 4b060420a596 ("bitmap, irq: add +smp_affinity_list interface to /proc/irq") when bitmap_parselist() was +generalized to support userspace as well as kernelspace. + +Fixes: 4b060420a596 ("bitmap, irq: add smp_affinity_list interface to /proc/irq") +Signed-off-by: Chris Metcalf +Cc: Rasmus Villemoes +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + lib/bitmap.c | 17 +++++++++-------- + 1 file changed, 9 insertions(+), 8 deletions(-) + +--- a/lib/bitmap.c ++++ b/lib/bitmap.c +@@ -603,12 +603,12 @@ static int __bitmap_parselist(const char + unsigned a, b; + int c, old_c, totaldigits; + const char __user __force *ubuf = (const char __user __force *)buf; +- int exp_digit, in_range; ++ int at_start, in_range; + + totaldigits = c = 0; + bitmap_zero(maskp, nmaskbits); + do { +- exp_digit = 1; ++ at_start = 1; + in_range = 0; + a = b = 0; + +@@ -637,11 +637,10 @@ static int __bitmap_parselist(const char + break; + + if (c == '-') { +- if (exp_digit || in_range) ++ if (at_start || in_range) + return -EINVAL; + b = 0; + in_range = 1; +- exp_digit = 1; + continue; + } + +@@ -651,16 +650,18 @@ static int __bitmap_parselist(const char + b = b * 10 + (c - '0'); + if (!in_range) + a = b; +- exp_digit = 0; ++ at_start = 0; + totaldigits++; + } + if (!(a <= b)) + return -EINVAL; + if (b >= nmaskbits) + return -ERANGE; +- while (a <= b) { +- set_bit(a, maskp); +- a++; ++ if (!at_start) { ++ while (a <= b) { ++ set_bit(a, maskp); ++ a++; ++ } + } + } while (buflen && c == ','); + return 0; diff --git a/queue-3.10/mac80211-prevent-possible-crypto-tx-tailroom-corruption.patch b/queue-3.10/mac80211-prevent-possible-crypto-tx-tailroom-corruption.patch new file mode 100644 index 00000000000..15455586cfb --- /dev/null +++ b/queue-3.10/mac80211-prevent-possible-crypto-tx-tailroom-corruption.patch @@ -0,0 +1,59 @@ +From ab499db80fcf07c18e4053f91a619500f663e90e Mon Sep 17 00:00:00 2001 +From: Michal Kazior +Date: Fri, 22 May 2015 10:22:40 +0200 +Subject: mac80211: prevent possible crypto tx tailroom corruption + +From: Michal Kazior + +commit ab499db80fcf07c18e4053f91a619500f663e90e upstream. + +There was a possible race between +ieee80211_reconfig() and +ieee80211_delayed_tailroom_dec(). This could +result in inability to transmit data if driver +crashed during roaming or rekeying and subsequent +skbs with insufficient tailroom appeared. + +This race was probably never seen in the wild +because a device driver would have to crash AND +recover within 0.5s which is very unlikely. + +I was able to prove this race exists after +changing the delay to 10s locally and crashing +ath10k via debugfs immediately after GTK +rekeying. In case of ath10k the counter went below +0. This was harmless but other drivers which +actually require tailroom (e.g. for WEP ICV or +MMIC) could end up with the counter at 0 instead +of >0 and introduce insufficient skb tailroom +failures because mac80211 would not resize skbs +appropriately anymore. + +Fixes: 8d1f7ecd2af5 ("mac80211: defer tailroom counter manipulation when roaming") +Signed-off-by: Michal Kazior +Signed-off-by: Johannes Berg +Signed-off-by: Greg Kroah-Hartman + +--- + net/mac80211/main.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/net/mac80211/main.c ++++ b/net/mac80211/main.c +@@ -257,6 +257,7 @@ static void ieee80211_restart_work(struc + { + struct ieee80211_local *local = + container_of(work, struct ieee80211_local, restart_work); ++ struct ieee80211_sub_if_data *sdata; + + /* wait for scan work complete */ + flush_workqueue(local->workqueue); +@@ -269,6 +270,8 @@ static void ieee80211_restart_work(struc + mutex_unlock(&local->mtx); + + rtnl_lock(); ++ list_for_each_entry(sdata, &local->interfaces, list) ++ flush_delayed_work(&sdata->dec_tailroom_needed_wk); + ieee80211_scan_cancel(local); + ieee80211_reconfig(local); + rtnl_unlock(); diff --git a/queue-3.10/mmc-card-fixup-request-missing-in-mmc_blk_issue_rw_rq.patch b/queue-3.10/mmc-card-fixup-request-missing-in-mmc_blk_issue_rw_rq.patch new file mode 100644 index 00000000000..52254acd3b8 --- /dev/null +++ b/queue-3.10/mmc-card-fixup-request-missing-in-mmc_blk_issue_rw_rq.patch @@ -0,0 +1,55 @@ +From 29535f7b797df35cc9b6b3bca635591cdd3dd2a8 Mon Sep 17 00:00:00 2001 +From: Ding Wang +Date: Mon, 18 May 2015 20:14:15 +0800 +Subject: mmc: card: Fixup request missing in mmc_blk_issue_rw_rq + +From: Ding Wang + +commit 29535f7b797df35cc9b6b3bca635591cdd3dd2a8 upstream. + +The current handler of MMC_BLK_CMD_ERR in mmc_blk_issue_rw_rq function +may cause new coming request permanent missing when the ongoing +request (previoulsy started) complete end. + +The problem scenario is as follows: +(1) Request A is ongoing; +(2) Request B arrived, and finally mmc_blk_issue_rw_rq() is called; +(3) Request A encounters the MMC_BLK_CMD_ERR error; +(4) In the error handling of MMC_BLK_CMD_ERR, suppose mmc_blk_cmd_err() + end request A completed and return zero. Continue the error handling, + suppose mmc_blk_reset() reset device success; +(5) Continue the execution, while loop completed because variable ret + is zero now; +(6) Finally, mmc_blk_issue_rw_rq() return without processing request B. + +The process related to the missing request may wait that IO request +complete forever, possibly crashing the application or hanging the system. + +Fix this issue by starting new request when reset success. + +Signed-off-by: Ding Wang +Fixes: 67716327eec7 ("mmc: block: add eMMC hardware reset support") +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mmc/card/block.c | 8 +++++--- + 1 file changed, 5 insertions(+), 3 deletions(-) + +--- a/drivers/mmc/card/block.c ++++ b/drivers/mmc/card/block.c +@@ -1835,9 +1835,11 @@ static int mmc_blk_issue_rw_rq(struct mm + break; + case MMC_BLK_CMD_ERR: + ret = mmc_blk_cmd_err(md, card, brq, req, ret); +- if (!mmc_blk_reset(md, card->host, type)) +- break; +- goto cmd_abort; ++ if (mmc_blk_reset(md, card->host, type)) ++ goto cmd_abort; ++ if (!ret) ++ goto start_new_req; ++ break; + case MMC_BLK_RETRY: + if (retry++ < 5) + break; diff --git a/queue-3.10/series b/queue-3.10/series index d1370f0c9de..18c7e69d71c 100644 --- a/queue-3.10/series +++ b/queue-3.10/series @@ -70,3 +70,6 @@ acpica-tables-fix-an-issue-that-facs-initialization-is-performed-twice.patch iscsi-target-convert-iscsi_thread_set-usage-to-kthread.h.patch iser-target-fix-possible-deadlock-in-rdma_cm-connection-error.patch iser-target-release-stale-iser-connections.patch +mmc-card-fixup-request-missing-in-mmc_blk_issue_rw_rq.patch +__bitmap_parselist-fix-bug-in-empty-string-handling.patch +mac80211-prevent-possible-crypto-tx-tailroom-corruption.patch