commit 779cde69dcc0c1d3c992c902a9d07bf7ec7b729b
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon Sep 16 08:19:34 2019 +0200

    Linux 4.9.193

commit 8d8276867b5ac539f1d6e166a028b51c8b1ceda8
Author: yongduan <yongduan@tencent.com>
Date:   Wed Sep 11 17:44:24 2019 +0800

    vhost: make sure log_num < in_num
    
    commit 060423bfdee3f8bc6e2c1bac97de24d5415e2bc4 upstream.
    
    The code assumes log_num < in_num everywhere, and that is true as long as
    in_num is incremented by descriptor iov count, and log_num by 1. However
    this breaks if there's a zero sized descriptor.
    
    As a result, if a malicious guest creates a vring desc with desc.len = 0,
    it may cause the host kernel to crash by overflowing the log array. This
    bug can be triggered during the VM migration.
    
    There's no need to log when desc.len = 0, so just don't increment log_num
    in this case.
    
    Fixes: 3a4d5c94e959 ("vhost_net: a kernel-level virtio server")
    Cc: stable@vger.kernel.org
    Reviewed-by: Lidong Chen <lidongchen@tencent.com>
    Signed-off-by: ruippan <ruippan@tencent.com>
    Signed-off-by: yongduan <yongduan@tencent.com>
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    Reviewed-by: Tyler Hicks <tyhicks@canonical.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5f3373bf6fed9cf71b0b31d2feea7412b2ec8db0
Author: Nathan Chancellor <natechancellor@gmail.com>
Date:   Thu Oct 18 12:13:40 2018 -0700

    clk: s2mps11: Add used attribute to s2mps11_dt_match
    
    [ Upstream commit 9c940bbe2bb47e03ca5e937d30b6a50bf9c0e671 ]
    
    Clang warns after commit 8985167ecf57 ("clk: s2mps11: Fix matching when
    built as module and DT node contains compatible"):
    
    drivers/clk/clk-s2mps11.c:242:34: warning: variable 's2mps11_dt_match'
    is not needed and will not be emitted [-Wunneeded-internal-declaration]
    static const struct of_device_id s2mps11_dt_match[] = {
                                     ^
    1 warning generated.
    
    This warning happens when a variable is used in some construct that
    doesn't require a reference to that variable to be emitted in the symbol
    table; in this case, it's MODULE_DEVICE_TABLE, which only needs to hold
    the data of the variable, not the variable itself.
    
    $ nm -S drivers/clk/clk-s2mps11.o | rg s2mps11_dt_match
    00000078 000003d4 R __mod_of__s2mps11_dt_match_device_table
    
    Normally, with device ID table variables, it means that the variable
    just needs to be tied to the device declaration at the bottom of the
    file, like s2mps11_clk_id:
    
    $ nm -S drivers/clk/clk-s2mps11.o | rg s2mps11_clk_id
    00000000 00000078 R __mod_platform__s2mps11_clk_id_device_table
    00000000 00000078 r s2mps11_clk_id
    
    However, because the comment above this deliberately doesn't want this
    variable added to .of_match_table, we need to mark s2mps11_dt_match as
    __used to silence this warning. This makes it clear to Clang that the
    variable is used for something, even if a reference to it isn't being
    emitted.
    
    Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
    Fixes: 8985167ecf57 ("clk: s2mps11: Fix matching when built as module and DT node contains compatible")
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 90741c3291f2f6c54068e1726370ed0b47ec4885
Author: Nicolas Boichat <drinkcat@chromium.org>
Date:   Thu Jul 11 20:52:27 2019 -0700

    scripts/decode_stacktrace: match basepath using shell prefix operator, not regex
    
    [ Upstream commit 31013836a71e07751a6827f9d2ad41ef502ddaff ]
    
    The basepath may contain special characters, which would confuse the regex
    matcher.  ${var#prefix} does the right thing.
    
    Link: http://lkml.kernel.org/r/20190518055946.181563-1-drinkcat@chromium.org
    Fixes: 67a28de47faa8358 ("scripts/decode_stacktrace: only strip base path when a prefix of the path")
    Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
    Reviewed-by: Stephen Boyd <swboyd@chromium.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6c59cb113e8c2082deab865d4ffb694cdfcbf61f
Author: Sven Eckelmann <sven@narfation.org>
Date:   Thu Aug 22 08:55:36 2019 +0200

    batman-adv: Only read OGM tvlv_len after buffer len check
    
    commit a15d56a60760aa9dbe26343b9a0ac5228f35d445 upstream.
    
    Multiple batadv_ogm_packet can be stored in an skbuff. The functions
    batadv_iv_ogm_send_to_if()/batadv_iv_ogm_receive() use
    batadv_iv_ogm_aggr_packet() to check if there is another additional
    batadv_ogm_packet in the skb or not before they continue processing the
    packet.
    
    The length for such an OGM is BATADV_OGM_HLEN +
    batadv_ogm_packet->tvlv_len. The check must first check that at least
    BATADV_OGM_HLEN bytes are available before it accesses tvlv_len (which is
    part of the header. Otherwise it might try read outside of the currently
    available skbuff to get the content of tvlv_len.
    
    Fixes: ef26157747d4 ("batman-adv: tvlv - basic infrastructure")
    Reported-by: syzbot+355cab184197dbbfa384@syzkaller.appspotmail.com
    Signed-off-by: Sven Eckelmann <sven@narfation.org>
    Acked-by: Antonio Quartulli <a@unstable.cc>
    Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cffe4e6087e84d42298d4872f7a86afe0065fae2
Author: Eric Dumazet <edumazet@google.com>
Date:   Mon Aug 12 04:57:27 2019 -0700

    batman-adv: fix uninit-value in batadv_netlink_get_ifindex()
    
    commit 3ee1bb7aae97324ec9078da1f00cb2176919563f upstream.
    
    batadv_netlink_get_ifindex() needs to make sure user passed
    a correct u32 attribute.
    
    syzbot reported :
    BUG: KMSAN: uninit-value in batadv_netlink_dump_hardif+0x70d/0x880 net/batman-adv/netlink.c:968
    CPU: 1 PID: 11705 Comm: syz-executor888 Not tainted 5.1.0+ #1
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    Call Trace:
     __dump_stack lib/dump_stack.c:77 [inline]
     dump_stack+0x191/0x1f0 lib/dump_stack.c:113
     kmsan_report+0x130/0x2a0 mm/kmsan/kmsan.c:622
     __msan_warning+0x75/0xe0 mm/kmsan/kmsan_instr.c:310
     batadv_netlink_dump_hardif+0x70d/0x880 net/batman-adv/netlink.c:968
     genl_lock_dumpit+0xc6/0x130 net/netlink/genetlink.c:482
     netlink_dump+0xa84/0x1ab0 net/netlink/af_netlink.c:2253
     __netlink_dump_start+0xa3a/0xb30 net/netlink/af_netlink.c:2361
     genl_family_rcv_msg net/netlink/genetlink.c:550 [inline]
     genl_rcv_msg+0xfc1/0x1a40 net/netlink/genetlink.c:627
     netlink_rcv_skb+0x431/0x620 net/netlink/af_netlink.c:2486
     genl_rcv+0x63/0x80 net/netlink/genetlink.c:638
     netlink_unicast_kernel net/netlink/af_netlink.c:1311 [inline]
     netlink_unicast+0xf3e/0x1020 net/netlink/af_netlink.c:1337
     netlink_sendmsg+0x127e/0x12f0 net/netlink/af_netlink.c:1926
     sock_sendmsg_nosec net/socket.c:651 [inline]
     sock_sendmsg net/socket.c:661 [inline]
     ___sys_sendmsg+0xcc6/0x1200 net/socket.c:2260
     __sys_sendmsg net/socket.c:2298 [inline]
     __do_sys_sendmsg net/socket.c:2307 [inline]
     __se_sys_sendmsg+0x305/0x460 net/socket.c:2305
     __x64_sys_sendmsg+0x4a/0x70 net/socket.c:2305
     do_syscall_64+0xbc/0xf0 arch/x86/entry/common.c:291
     entry_SYSCALL_64_after_hwframe+0x63/0xe7
    RIP: 0033:0x440209
    
    Fixes: b60620cf567b ("batman-adv: netlink: hardif query")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Sven Eckelmann <sven@narfation.org>
    Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aac633e9015d2f13f07522d024f906986ea50a06
Author: Tiwei Bie <tiwei.bie@intel.com>
Date:   Wed Aug 28 13:37:00 2019 +0800

    vhost/test: fix build for vhost test
    
    commit 264b563b8675771834419057cbe076c1a41fb666 upstream.
    
    Since vhost_exceeds_weight() was introduced, callers need to specify
    the packet weight and byte weight in vhost_dev_init(). Note that, the
    packet weight isn't counted in this patch to keep the original behavior
    unchanged.
    
    Fixes: e82b9b0727ff ("vhost: introduce vhost_exceeds_weight()")
    Cc: stable@vger.kernel.org
    Signed-off-by: Tiwei Bie <tiwei.bie@intel.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Jason Wang <jasowang@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f99a93352471791351d67b4f56a7ac891ec1b6aa
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri May 3 08:24:44 2019 -0700

    ip6: fix skb leak in ip6frag_expire_frag_queue()
    
    commit 47d3d7fdb10a21c223036b58bd70ffdc24a472c4 upstream.
    
    Since ip6frag_expire_frag_queue() now pulls the head skb
    from frag queue, we should no longer use skb_get(), since
    this leads to an skb leak.
    
    Stefan Bader initially reported a problem in 4.4.stable [1] caused
    by the skb_get(), so this patch should also fix this issue.
    
    296583.091021] kernel BUG at /build/linux-6VmqmP/linux-4.4.0/net/core/skbuff.c:1207!
    [296583.091734] Call Trace:
    [296583.091749]  [<ffffffff81740e50>] __pskb_pull_tail+0x50/0x350
    [296583.091764]  [<ffffffff8183939a>] _decode_session6+0x26a/0x400
    [296583.091779]  [<ffffffff817ec719>] __xfrm_decode_session+0x39/0x50
    [296583.091795]  [<ffffffff818239d0>] icmpv6_route_lookup+0xf0/0x1c0
    [296583.091809]  [<ffffffff81824421>] icmp6_send+0x5e1/0x940
    [296583.091823]  [<ffffffff81753238>] ? __netif_receive_skb+0x18/0x60
    [296583.091838]  [<ffffffff817532b2>] ? netif_receive_skb_internal+0x32/0xa0
    [296583.091858]  [<ffffffffc0199f74>] ? ixgbe_clean_rx_irq+0x594/0xac0 [ixgbe]
    [296583.091876]  [<ffffffffc04eb260>] ? nf_ct_net_exit+0x50/0x50 [nf_defrag_ipv6]
    [296583.091893]  [<ffffffff8183d431>] icmpv6_send+0x21/0x30
    [296583.091906]  [<ffffffff8182b500>] ip6_expire_frag_queue+0xe0/0x120
    [296583.091921]  [<ffffffffc04eb27f>] nf_ct_frag6_expire+0x1f/0x30 [nf_defrag_ipv6]
    [296583.091938]  [<ffffffff810f3b57>] call_timer_fn+0x37/0x140
    [296583.091951]  [<ffffffffc04eb260>] ? nf_ct_net_exit+0x50/0x50 [nf_defrag_ipv6]
    [296583.091968]  [<ffffffff810f5464>] run_timer_softirq+0x234/0x330
    [296583.091982]  [<ffffffff8108a339>] __do_softirq+0x109/0x2b0
    
    Fixes: d4289fcc9b16 ("net: IP6 defrag: use rbtrees for IPv6 defrag")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: Stefan Bader <stefan.bader@canonical.com>
    Cc: Peter Oskolkov <posk@google.com>
    Cc: Florian Westphal <fw@strlen.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 88d08316dabb6462c32d0adb62c4dade71405d92
Author: Cong Wang <xiyou.wangcong@gmail.com>
Date:   Fri Mar 22 16:26:19 2019 -0700

    xfrm: clean up xfrm protocol checks
    
    commit dbb2483b2a46fbaf833cfb5deb5ed9cace9c7399 upstream.
    
    In commit 6a53b7593233 ("xfrm: check id proto in validate_tmpl()")
    I introduced a check for xfrm protocol, but according to Herbert
    IPSEC_PROTO_ANY should only be used as a wildcard for lookup, so
    it should be removed from validate_tmpl().
    
    And, IPSEC_PROTO_ANY is expected to only match 3 IPSec-specific
    protocols, this is why xfrm_state_flush() could still miss
    IPPROTO_ROUTING, which leads that those entries are left in
    net->xfrm.state_all before exit net. Fix this by replacing
    IPSEC_PROTO_ANY with zero.
    
    This patch also extracts the check from validate_tmpl() to
    xfrm_id_proto_valid() and uses it in parse_ipsecrequest().
    With this, no other protocols should be added into xfrm.
    
    Fixes: 6a53b7593233 ("xfrm: check id proto in validate_tmpl()")
    Reported-by: syzbot+0bf0519d6e0de15914fe@syzkaller.appspotmail.com
    Cc: Steffen Klassert <steffen.klassert@secunet.com>
    Cc: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
    Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Zubin Mithra <zsm@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit acdf558ef62ceb71938d87f5b700b7ecc0bbee90
Author: Gustavo Romero <gromero@linux.ibm.com>
Date:   Wed Sep 4 00:55:27 2019 -0400

    powerpc/tm: Fix FP/VMX unavailable exceptions inside a transaction
    
    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 <gromero@linux.vnet.ibm.com>
    Signed-off-by: Michael Neuling <mikey@neuling.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20190904045529.23002-1-gromero@linux.vnet.ibm.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 161f7a6f396152da50d18151c075fe9aba16c6db
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Aug 15 11:30:50 2019 +0300

    drm/vmwgfx: Fix double free in vmw_recv_msg()
    
    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: <stable@vger.kernel.org>
    Fixes: 6b7c3b86f0b6 ("drm/vmwgfx: fix memory leak when too many retries have occurred")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
    Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0a3989a5e9ebbc7e779797bf4a0680d0f7fc800c
Author: Liangyan <liangyan.peng@linux.alibaba.com>
Date:   Mon Aug 26 20:16:33 2019 +0800

    sched/fair: Don't assign runtime for throttled cfs_rq
    
    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 <liangyan.peng@linux.alibaba.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Valentin Schneider <valentin.schneider@arm.com>
    Reviewed-by: Ben Segall <bsegall@google.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    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 <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a2663aaae045c90de72a14fd072798ee07619662
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Aug 30 12:03:38 2019 +0200

    ALSA: hda/realtek - Fix overridden device-specific initialization
    
    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: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit df4cdab26729040d3e9d31245d319fa2abc6c23d
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Aug 29 09:52:02 2019 +0200

    ALSA: hda - Fix potential endless loop at applying quirks
    
    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: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>