From aaef9ef02b47f9d5f600d96b9e853c23b09c5262 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Tue, 10 Sep 2019 12:29:24 +0100 Subject: [PATCH] 4.9-stable patches added patches: alsa-hda-fix-potential-endless-loop-at-applying-quirks.patch alsa-hda-realtek-fix-overridden-device-specific-initialization.patch drm-vmwgfx-fix-double-free-in-vmw_recv_msg.patch powerpc-tm-fix-fp-vmx-unavailable-exceptions-inside-a-transaction.patch sched-fair-don-t-assign-runtime-for-throttled-cfs_rq.patch --- ...tial-endless-loop-at-applying-quirks.patch | 43 +++++++ ...idden-device-specific-initialization.patch | 69 +++++++++++ ...wgfx-fix-double-free-in-vmw_recv_msg.patch | 68 +++++++++++ ...able-exceptions-inside-a-transaction.patch | 114 ++++++++++++++++++ ...-assign-runtime-for-throttled-cfs_rq.patch | 73 +++++++++++ 5 files changed, 367 insertions(+) create mode 100644 queue-4.9/alsa-hda-fix-potential-endless-loop-at-applying-quirks.patch create mode 100644 queue-4.9/alsa-hda-realtek-fix-overridden-device-specific-initialization.patch create mode 100644 queue-4.9/drm-vmwgfx-fix-double-free-in-vmw_recv_msg.patch create mode 100644 queue-4.9/powerpc-tm-fix-fp-vmx-unavailable-exceptions-inside-a-transaction.patch create mode 100644 queue-4.9/sched-fair-don-t-assign-runtime-for-throttled-cfs_rq.patch diff --git a/queue-4.9/alsa-hda-fix-potential-endless-loop-at-applying-quirks.patch b/queue-4.9/alsa-hda-fix-potential-endless-loop-at-applying-quirks.patch new file mode 100644 index 00000000000..4d3a524a72a --- /dev/null +++ b/queue-4.9/alsa-hda-fix-potential-endless-loop-at-applying-quirks.patch @@ -0,0 +1,43 @@ +From 333f31436d3db19f4286f8862a00ea1d8d8420a1 Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Thu, 29 Aug 2019 09:52:02 +0200 +Subject: ALSA: hda - Fix potential endless loop at applying quirks + +From: Takashi Iwai + +commit 333f31436d3db19f4286f8862a00ea1d8d8420a1 upstream. + +Since the chained quirks via chained_before flag is applied before the +depth check, it may lead to the endless recursive calls, when the +chain were set up incorrectly. Fix it by moving the depth check at +the beginning of the loop. + +Fixes: 1f57825077dc ("ALSA: hda - Add chained_before flag to the fixup entry") +Cc: +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman + +--- + sound/pci/hda/hda_auto_parser.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/sound/pci/hda/hda_auto_parser.c ++++ b/sound/pci/hda/hda_auto_parser.c +@@ -827,6 +827,8 @@ static void apply_fixup(struct hda_codec + while (id >= 0) { + const struct hda_fixup *fix = codec->fixup_list + id; + ++ if (++depth > 10) ++ break; + if (fix->chained_before) + apply_fixup(codec, fix->chain_id, action, depth + 1); + +@@ -866,8 +868,6 @@ static void apply_fixup(struct hda_codec + } + if (!fix->chained || fix->chained_before) + break; +- if (++depth > 10) +- break; + id = fix->chain_id; + } + } diff --git a/queue-4.9/alsa-hda-realtek-fix-overridden-device-specific-initialization.patch b/queue-4.9/alsa-hda-realtek-fix-overridden-device-specific-initialization.patch new file mode 100644 index 00000000000..9049062f7a3 --- /dev/null +++ b/queue-4.9/alsa-hda-realtek-fix-overridden-device-specific-initialization.patch @@ -0,0 +1,69 @@ +From 89781d0806c2c4f29072d3f00cb2dd4274aabc3d Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Fri, 30 Aug 2019 12:03:38 +0200 +Subject: ALSA: hda/realtek - Fix overridden device-specific initialization + +From: Takashi Iwai + +commit 89781d0806c2c4f29072d3f00cb2dd4274aabc3d upstream. + +The recent change to shuffle the codec initialization procedure for +Realtek via commit 607ca3bd220f ("ALSA: hda/realtek - EAPD turn on +later") caused the silent output on some machines. This change was +supposed to be safe, but it isn't actually; some devices have quirk +setups to override the EAPD via COEF or BTL in the additional verb +table, which is applied at the beginning of snd_hda_gen_init(). And +this EAPD setup is again overridden in alc_auto_init_amp(). + +For recovering from the regression, tell snd_hda_gen_init() not to +apply the verbs there by a new flag, then apply the verbs in +alc_init(). + +BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204727 +Fixes: 607ca3bd220f ("ALSA: hda/realtek - EAPD turn on later") +Cc: +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman + +--- + sound/pci/hda/hda_generic.c | 3 ++- + sound/pci/hda/hda_generic.h | 1 + + sound/pci/hda/patch_realtek.c | 2 ++ + 3 files changed, 5 insertions(+), 1 deletion(-) + +--- a/sound/pci/hda/hda_generic.c ++++ b/sound/pci/hda/hda_generic.c +@@ -5807,7 +5807,8 @@ int snd_hda_gen_init(struct hda_codec *c + if (spec->init_hook) + spec->init_hook(codec); + +- snd_hda_apply_verbs(codec); ++ if (!spec->skip_verbs) ++ snd_hda_apply_verbs(codec); + + init_multi_out(codec); + init_extra_out(codec); +--- a/sound/pci/hda/hda_generic.h ++++ b/sound/pci/hda/hda_generic.h +@@ -236,6 +236,7 @@ struct hda_gen_spec { + unsigned int indep_hp_enabled:1; /* independent HP enabled */ + unsigned int have_aamix_ctl:1; + unsigned int hp_mic_jack_modes:1; ++ unsigned int skip_verbs:1; /* don't apply verbs at snd_hda_gen_init() */ + + /* additional mute flags (only effective with auto_mute_via_amp=1) */ + u64 mute_bits; +--- a/sound/pci/hda/patch_realtek.c ++++ b/sound/pci/hda/patch_realtek.c +@@ -773,9 +773,11 @@ static int alc_init(struct hda_codec *co + if (spec->init_hook) + spec->init_hook(codec); + ++ spec->gen.skip_verbs = 1; /* applied in below */ + snd_hda_gen_init(codec); + alc_fix_pll(codec); + alc_auto_init_amp(codec, spec->init_amp); ++ snd_hda_apply_verbs(codec); /* apply verbs here after own init */ + + snd_hda_apply_fixup(codec, HDA_FIXUP_ACT_INIT); + diff --git a/queue-4.9/drm-vmwgfx-fix-double-free-in-vmw_recv_msg.patch b/queue-4.9/drm-vmwgfx-fix-double-free-in-vmw_recv_msg.patch new file mode 100644 index 00000000000..4c832340825 --- /dev/null +++ b/queue-4.9/drm-vmwgfx-fix-double-free-in-vmw_recv_msg.patch @@ -0,0 +1,68 @@ +From 08b0c891605acf727e43e3e03a25857d3e789b61 Mon Sep 17 00:00:00 2001 +From: Dan Carpenter +Date: Thu, 15 Aug 2019 11:30:50 +0300 +Subject: drm/vmwgfx: Fix double free in vmw_recv_msg() + +From: Dan Carpenter + +commit 08b0c891605acf727e43e3e03a25857d3e789b61 upstream. + +We recently added a kfree() after the end of the loop: + + if (retries == RETRIES) { + kfree(reply); + return -EINVAL; + } + +There are two problems. First the test is wrong and because retries +equals RETRIES if we succeed on the last iteration through the loop. +Second if we fail on the last iteration through the loop then the kfree +is a double free. + +When you're reading this code, please note the break statement at the +end of the while loop. This patch changes the loop so that if it's not +successful then "reply" is NULL and we can test for that afterward. + +Cc: +Fixes: 6b7c3b86f0b6 ("drm/vmwgfx: fix memory leak when too many retries have occurred") +Signed-off-by: Dan Carpenter +Reviewed-by: Thomas Hellstrom +Signed-off-by: Thomas Hellstrom +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/vmwgfx/vmwgfx_msg.c | 8 +++----- + 1 file changed, 3 insertions(+), 5 deletions(-) + +--- a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c ++++ b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c +@@ -264,7 +264,7 @@ static int vmw_recv_msg(struct rpc_chann + + if ((HIGH_WORD(ebx) & MESSAGE_STATUS_SUCCESS) == 0) { + kfree(reply); +- ++ reply = NULL; + if ((HIGH_WORD(ebx) & MESSAGE_STATUS_CPT) != 0) { + /* A checkpoint occurred. Retry. */ + continue; +@@ -288,7 +288,7 @@ static int vmw_recv_msg(struct rpc_chann + + if ((HIGH_WORD(ecx) & MESSAGE_STATUS_SUCCESS) == 0) { + kfree(reply); +- ++ reply = NULL; + if ((HIGH_WORD(ecx) & MESSAGE_STATUS_CPT) != 0) { + /* A checkpoint occurred. Retry. */ + continue; +@@ -300,10 +300,8 @@ static int vmw_recv_msg(struct rpc_chann + break; + } + +- if (retries == RETRIES) { +- kfree(reply); ++ if (!reply) + return -EINVAL; +- } + + *msg_len = reply_len; + *msg = reply; diff --git a/queue-4.9/powerpc-tm-fix-fp-vmx-unavailable-exceptions-inside-a-transaction.patch b/queue-4.9/powerpc-tm-fix-fp-vmx-unavailable-exceptions-inside-a-transaction.patch new file mode 100644 index 00000000000..9e25f4b69c0 --- /dev/null +++ b/queue-4.9/powerpc-tm-fix-fp-vmx-unavailable-exceptions-inside-a-transaction.patch @@ -0,0 +1,114 @@ +From 8205d5d98ef7f155de211f5e2eb6ca03d95a5a60 Mon Sep 17 00:00:00 2001 +From: Gustavo Romero +Date: Wed, 4 Sep 2019 00:55:27 -0400 +Subject: powerpc/tm: Fix FP/VMX unavailable exceptions inside a transaction + +From: Gustavo Romero + +commit 8205d5d98ef7f155de211f5e2eb6ca03d95a5a60 upstream. + +When we take an FP unavailable exception in a transaction we have to +account for the hardware FP TM checkpointed registers being +incorrect. In this case for this process we know the current and +checkpointed FP registers must be the same (since FP wasn't used +inside the transaction) hence in the thread_struct we copy the current +FP registers to the checkpointed ones. + +This copy is done in tm_reclaim_thread(). We use thread->ckpt_regs.msr +to determine if FP was on when in userspace. thread->ckpt_regs.msr +represents the state of the MSR when exiting userspace. This is setup +by check_if_tm_restore_required(). + +Unfortunatley there is an optimisation in giveup_all() which returns +early if tsk->thread.regs->msr (via local variable `usermsr`) has +FP=VEC=VSX=SPE=0. This optimisation means that +check_if_tm_restore_required() is not called and hence +thread->ckpt_regs.msr is not updated and will contain an old value. + +This can happen if due to load_fp=255 we start a userspace process +with MSR FP=1 and then we are context switched out. In this case +thread->ckpt_regs.msr will contain FP=1. If that same process is then +context switched in and load_fp overflows, MSR will have FP=0. If that +process now enters a transaction and does an FP instruction, the FP +unavailable will not update thread->ckpt_regs.msr (the bug) and MSR +FP=1 will be retained in thread->ckpt_regs.msr. tm_reclaim_thread() +will then not perform the required memcpy and the checkpointed FP regs +in the thread struct will contain the wrong values. + +The code path for this happening is: + + Userspace: Kernel + Start userspace + with MSR FP/VEC/VSX/SPE=0 TM=1 + < ----- + ... + tbegin + bne + fp instruction + FP unavailable + ---- > + fp_unavailable_tm() + tm_reclaim_current() + tm_reclaim_thread() + giveup_all() + return early since FP/VMX/VSX=0 + /* ckpt MSR not updated (Incorrect) */ + tm_reclaim() + /* thread_struct ckpt FP regs contain junk (OK) */ + /* Sees ckpt MSR FP=1 (Incorrect) */ + no memcpy() performed + /* thread_struct ckpt FP regs not fixed (Incorrect) */ + tm_recheckpoint() + /* Put junk in hardware checkpoint FP regs */ + .... + < ----- + Return to userspace + with MSR TM=1 FP=1 + with junk in the FP TM checkpoint + TM rollback + reads FP junk + +This is a data integrity problem for the current process as the FP +registers are corrupted. It's also a security problem as the FP +registers from one process may be leaked to another. + +This patch moves up check_if_tm_restore_required() in giveup_all() to +ensure thread->ckpt_regs.msr is updated correctly. + +A simple testcase to replicate this will be posted to +tools/testing/selftests/powerpc/tm/tm-poison.c + +Similarly for VMX. + +This fixes CVE-2019-15030. + +Fixes: f48e91e87e67 ("powerpc/tm: Fix FP and VMX register corruption") +Cc: stable@vger.kernel.org # 4.12+ +Signed-off-by: Gustavo Romero +Signed-off-by: Michael Neuling +Signed-off-by: Michael Ellerman +Link: https://lore.kernel.org/r/20190904045529.23002-1-gromero@linux.vnet.ibm.com +Signed-off-by: Greg Kroah-Hartman + +--- + arch/powerpc/kernel/process.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/arch/powerpc/kernel/process.c ++++ b/arch/powerpc/kernel/process.c +@@ -476,13 +476,14 @@ void giveup_all(struct task_struct *tsk) + if (!tsk->thread.regs) + return; + ++ check_if_tm_restore_required(tsk); ++ + usermsr = tsk->thread.regs->msr; + + if ((usermsr & msr_all_available) == 0) + return; + + msr_check_and_set(msr_all_available); +- check_if_tm_restore_required(tsk); + + #ifdef CONFIG_PPC_FPU + if (usermsr & MSR_FP) diff --git a/queue-4.9/sched-fair-don-t-assign-runtime-for-throttled-cfs_rq.patch b/queue-4.9/sched-fair-don-t-assign-runtime-for-throttled-cfs_rq.patch new file mode 100644 index 00000000000..f5ff9ae9661 --- /dev/null +++ b/queue-4.9/sched-fair-don-t-assign-runtime-for-throttled-cfs_rq.patch @@ -0,0 +1,73 @@ +From 5e2d2cc2588bd3307ce3937acbc2ed03c830a861 Mon Sep 17 00:00:00 2001 +From: Liangyan +Date: Mon, 26 Aug 2019 20:16:33 +0800 +Subject: sched/fair: Don't assign runtime for throttled cfs_rq + +From: Liangyan + +commit 5e2d2cc2588bd3307ce3937acbc2ed03c830a861 upstream. + +do_sched_cfs_period_timer() will refill cfs_b runtime and call +distribute_cfs_runtime to unthrottle cfs_rq, sometimes cfs_b->runtime +will allocate all quota to one cfs_rq incorrectly, then other cfs_rqs +attached to this cfs_b can't get runtime and will be throttled. + +We find that one throttled cfs_rq has non-negative +cfs_rq->runtime_remaining and cause an unexpetced cast from s64 to u64 +in snippet: + + distribute_cfs_runtime() { + runtime = -cfs_rq->runtime_remaining + 1; + } + +The runtime here will change to a large number and consume all +cfs_b->runtime in this cfs_b period. + +According to Ben Segall, the throttled cfs_rq can have +account_cfs_rq_runtime called on it because it is throttled before +idle_balance, and the idle_balance calls update_rq_clock to add time +that is accounted to the task. + +This commit prevents cfs_rq to be assgined new runtime if it has been +throttled until that distribute_cfs_runtime is called. + +Signed-off-by: Liangyan +Signed-off-by: Peter Zijlstra (Intel) +Reviewed-by: Valentin Schneider +Reviewed-by: Ben Segall +Cc: Linus Torvalds +Cc: Peter Zijlstra +Cc: Thomas Gleixner +Cc: shanpeic@linux.alibaba.com +Cc: stable@vger.kernel.org +Cc: xlpang@linux.alibaba.com +Fixes: d3d9dc330236 ("sched: Throttle entities exceeding their allowed bandwidth") +Link: https://lkml.kernel.org/r/20190826121633.6538-1-liangyan.peng@linux.alibaba.com +Signed-off-by: Ingo Molnar +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/sched/fair.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/kernel/sched/fair.c ++++ b/kernel/sched/fair.c +@@ -3882,6 +3882,8 @@ static void __account_cfs_rq_runtime(str + if (likely(cfs_rq->runtime_remaining > 0)) + return; + ++ if (cfs_rq->throttled) ++ return; + /* + * if we're unable to extend our runtime we resched so that the active + * hierarchy can be throttled +@@ -4077,6 +4079,9 @@ static u64 distribute_cfs_runtime(struct + if (!cfs_rq_throttled(cfs_rq)) + goto next; + ++ /* By the above check, this should never be true */ ++ SCHED_WARN_ON(cfs_rq->runtime_remaining > 0); ++ + runtime = -cfs_rq->runtime_remaining + 1; + if (runtime > remaining) + runtime = remaining; -- 2.47.3