commit d6ccbff9be43dbb6113a6a3f107c3d066052097e
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Feb 5 13:03:47 2020 +0000

    Linux 4.4.213

commit 6d929d2c49f76d711529417169d31bd36afd5c4e
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Fri Jan 31 09:31:05 2020 -0500

    btrfs: do not zero f_bavail if we have available space
    
    [ Upstream commit d55966c4279bfc6a0cf0b32bf13f5df228a1eeb6 ]
    
    There was some logic added a while ago to clear out f_bavail in statfs()
    if we did not have enough free metadata space to satisfy our global
    reserve.  This was incorrect at the time, however didn't really pose a
    problem for normal file systems because we would often allocate chunks
    if we got this low on free metadata space, and thus wouldn't really hit
    this case unless we were actually full.
    
    Fast forward to today and now we are much better about not allocating
    metadata chunks all of the time.  Couple this with d792b0f19711 ("btrfs:
    always reserve our entire size for the global reserve") which now means
    we'll easily have a larger global reserve than our free space, we are
    now more likely to trip over this while still having plenty of space.
    
    Fix this by skipping this logic if the global rsv's space_info is not
    full.  space_info->full is 0 unless we've attempted to allocate a chunk
    for that space_info and that has failed.  If this happens then the space
    for the global reserve is definitely sacred and we need to report
    b_avail == 0, but before then we can just use our calculated b_avail.
    
    Reported-by: Martin Steigerwald <martin@lichtvoll.de>
    Fixes: ca8a51b3a979 ("btrfs: statfs: report zero available if metadata are exhausted")
    CC: stable@vger.kernel.org # 4.5+
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    Tested-By: Martin Steigerwald <martin@lichtvoll.de>
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 078210b5b0d611f5ed0cb78ad945410c3cfcd5fb
Author: Luis de Bethencourt <luisbg@osg.samsung.com>
Date:   Wed Mar 30 21:53:38 2016 +0100

    btrfs: fix mixed block count of available space
    
    [ Upstream commit ae02d1bd070767e109f4a6f1bb1f466e9698a355 ]
    
    Metadata for mixed block is already accounted in total data and should not
    be counted as part of the free metadata space.
    
    Signed-off-by: Luis de Bethencourt <luisbg@osg.samsung.com>
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=114281
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 571277b6ff27e65ca1a42a2f1faf87942c4ba5bb
Author: Praveen Chaudhary <praveen5582@gmail.com>
Date:   Thu Jan 23 12:33:28 2020 -0800

    net: Fix skb->csum update in inet_proto_csum_replace16().
    
    [ Upstream commit 189c9b1e94539b11c80636bc13e9cf47529e7bba ]
    
    skb->csum is updated incorrectly, when manipulation for
    NF_NAT_MANIP_SRC\DST is done on IPV6 packet.
    
    Fix:
    There is no need to update skb->csum in inet_proto_csum_replace16(),
    because update in two fields a.) IPv6 src/dst address and b.) L4 header
    checksum cancels each other for skb->csum calculation. Whereas
    inet_proto_csum_replace4 function needs to update skb->csum, because
    update in 3 fields a.) IPv4 src/dst address, b.) IPv4 Header checksum
    and c.) L4 header checksum results in same diff as L4 Header checksum
    for skb->csum calculation.
    
    [ pablo@netfilter.org: a few comestic documentation edits ]
    Signed-off-by: Praveen Chaudhary <pchaudhary@linkedin.com>
    Signed-off-by: Zhenggen Xu <zxu@linkedin.com>
    Signed-off-by: Andy Stracner <astracner@linkedin.com>
    Reviewed-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c10c5bb8a8b32a18cb3a408b28350b17ec9cda4c
Author: Vasily Averin <vvs@virtuozzo.com>
Date:   Thu Jan 23 10:11:13 2020 +0300

    l2t_seq_next should increase position index
    
    [ Upstream commit 66018a102f7756cf72db4d2704e1b93969d9d332 ]
    
    if seq_file .next fuction does not change position index,
    read after some lseek can generate unexpected output.
    
    https://bugzilla.kernel.org/show_bug.cgi?id=206283
    Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6ffe7ec419b5dc0c41d4862fd1fe436494a2523b
Author: Vasily Averin <vvs@virtuozzo.com>
Date:   Thu Jan 23 10:11:08 2020 +0300

    seq_tab_next() should increase position index
    
    [ Upstream commit 70a87287c821e9721b62463777f55ba588ac4623 ]
    
    if seq_file .next fuction does not change position index,
    read after some lseek can generate unexpected output.
    
    https://bugzilla.kernel.org/show_bug.cgi?id=206283
    Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6d82377af9ba9ae9215610411f167fb8e5a4cc0d
Author: Finn Thain <fthain@telegraphics.com.au>
Date:   Thu Jan 23 09:07:26 2020 +1100

    net/sonic: Quiesce SONIC before re-initializing descriptor memory
    
    [ Upstream commit 3f4b7e6a2be982fd8820a2b54d46dd9c351db899 ]
    
    Make sure the SONIC's DMA engine is idle before altering the transmit
    and receive descriptors. Add a helper for this as it will be needed
    again.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Tested-by: Stan Johnson <userm57@yahoo.com>
    Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ffcfac3ae24ef552b4b0cd01ee0ad2e583202ba6
Author: Finn Thain <fthain@telegraphics.com.au>
Date:   Thu Jan 23 09:07:26 2020 +1100

    net/sonic: Fix receive buffer handling
    
    [ Upstream commit 9e311820f67e740f4fb8dcb82b4c4b5b05bdd1a5 ]
    
    The SONIC can sometimes advance its rx buffer pointer (RRP register)
    without advancing its rx descriptor pointer (CRDA register). As a result
    the index of the current rx descriptor may not equal that of the current
    rx buffer. The driver mistakenly assumes that they are always equal.
    This assumption leads to incorrect packet lengths and possible packet
    duplication. Avoid this by calling a new function to locate the buffer
    corresponding to a given descriptor.
    
    Fixes: efcce839360f ("[PATCH] macsonic/jazzsonic network drivers update")
    Tested-by: Stan Johnson <userm57@yahoo.com>
    Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1bd3de96497766f9769e941c09a41a7479642644
Author: Finn Thain <fthain@telegraphics.com.au>
Date:   Thu Jan 23 09:07:26 2020 +1100

    net/sonic: Use MMIO accessors
    
    [ Upstream commit e3885f576196ddfc670b3d53e745de96ffcb49ab ]
    
    The driver accesses descriptor memory which is simultaneously accessed by
    the chip, so the compiler must not be allowed to re-order CPU accesses.
    sonic_buf_get() used 'volatile' to prevent that. sonic_buf_put() should
    have done so too but was overlooked.
    
    Fixes: efcce839360f ("[PATCH] macsonic/jazzsonic network drivers update")
    Tested-by: Stan Johnson <userm57@yahoo.com>
    Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6425373e5397630b8a7672b9bf2b1acad241dd54
Author: Finn Thain <fthain@telegraphics.com.au>
Date:   Thu Jan 23 09:07:26 2020 +1100

    net/sonic: Add mutual exclusion for accessing shared state
    
    [ Upstream commit 865ad2f2201dc18685ba2686f13217f8b3a9c52c ]
    
    The netif_stop_queue() call in sonic_send_packet() races with the
    netif_wake_queue() call in sonic_interrupt(). This causes issues
    like "NETDEV WATCHDOG: eth0 (macsonic): transmit queue 0 timed out".
    Fix this by disabling interrupts when accessing tx_skb[] and next_tx.
    Update a comment to clarify the synchronization properties.
    
    Fixes: efcce839360f ("[PATCH] macsonic/jazzsonic network drivers update")
    Tested-by: Stan Johnson <userm57@yahoo.com>
    Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c2f59355e72aa1eccfe779930d804fac32a7489b
Author: Madalin Bucur <madalin.bucur@oss.nxp.com>
Date:   Wed Jan 22 15:20:29 2020 +0200

    net/fsl: treat fsl,erratum-a011043
    
    [ Upstream commit 1d3ca681b9d9575ccf696ebc2840a1ebb1fd4074 ]
    
    When fsl,erratum-a011043 is set, adjust for erratum A011043:
    MDIO reads to internal PCS registers may result in having
    the MDIO_CFG[MDIO_RD_ER] bit set, even when there is no
    error and read data (MDIO_DATA[MDIO_DATA]) is correct.
    Software may get false read error when reading internal
    PCS registers through MDIO. As a workaround, all internal
    MDIO accesses should ignore the MDIO_CFG[MDIO_RD_ER] bit.
    
    Signed-off-by: Madalin Bucur <madalin.bucur@oss.nxp.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 16b53f6d116d6790fc69c13420dd75b6fd82527c
Author: Manish Chopra <manishc@marvell.com>
Date:   Wed Jan 22 01:43:38 2020 -0800

    qlcnic: Fix CPU soft lockup while collecting firmware dump
    
    [ Upstream commit 22e984493a41bf8081f13d9ed84def3ca8cfd427 ]
    
    Driver while collecting firmware dump takes longer time to
    collect/process some of the firmware dump entries/memories.
    Bigger capture masks makes it worse as it results in larger
    amount of data being collected and results in CPU soft lockup.
    Place cond_resched() in some of the driver flows that are
    expectedly time consuming to relinquish the CPU to avoid CPU
    soft lockup panic.
    
    Signed-off-by: Shahed Shaikh <shshaikh@marvell.com>
    Tested-by: Yonggen Xu <Yonggen.Xu@dell.com>
    Signed-off-by: Manish Chopra <manishc@marvell.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit e38df4efddb5c2d428a1b33bdeb02ddb7e97f655
Author: Hayes Wang <hayeswang@realtek.com>
Date:   Wed Jan 22 16:02:07 2020 +0800

    r8152: get default setting of WOL before initializing
    
    [ Upstream commit 9583a3638dc07cc1878f41265e85ed497f72efcb ]
    
    Initailization would reset runtime suspend by tp->saved_wolopts, so
    the tp->saved_wolopts should be set before initializing.
    
    Signed-off-by: Hayes Wang <hayeswang@realtek.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit bd786d8d13d528fddc4570a5b9a6f52c4b937791
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Wed Jan 22 15:07:28 2020 +1100

    airo: Add missing CAP_NET_ADMIN check in AIROOLDIOCTL/SIOCDEVPRIVATE
    
    [ Upstream commit 78f7a7566f5eb59321e99b55a6fdb16ea05b37d1 ]
    
    The driver for Cisco Aironet 4500 and 4800 series cards (airo.c),
    implements AIROOLDIOCTL/SIOCDEVPRIVATE in airo_ioctl().
    
    The ioctl handler copies an aironet_ioctl struct from userspace, which
    includes a command. Some of the commands are handled in readrids(),
    where the user controlled command is converted into a driver-internal
    value called "ridcode".
    
    There are two command values, AIROGWEPKTMP and AIROGWEPKNV, which
    correspond to ridcode values of RID_WEP_TEMP and RID_WEP_PERM
    respectively. These commands both have checks that the user has
    CAP_NET_ADMIN, with the comment that "Only super-user can read WEP
    keys", otherwise they return -EPERM.
    
    However there is another command value, AIRORRID, that lets the user
    specify the ridcode value directly, with no other checks. This means
    the user can bypass the CAP_NET_ADMIN check on AIROGWEPKTMP and
    AIROGWEPKNV.
    
    Fix it by moving the CAP_NET_ADMIN check out of the command handling
    and instead do it later based on the ridcode. That way regardless of
    whether the ridcode is set via AIROGWEPKTMP or AIROGWEPKNV, or passed
    in using AIRORID, we always do the CAP_NET_ADMIN check.
    
    Found by Ilja by code inspection, not tested as I don't have the
    required hardware.
    
    Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 98fd2fc6f18c107f925d0519d10ea03177c2a537
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Wed Jan 22 15:07:27 2020 +1100

    airo: Fix possible info leak in AIROOLDIOCTL/SIOCDEVPRIVATE
    
    [ Upstream commit d6bce2137f5d6bb1093e96d2f801479099b28094 ]
    
    The driver for Cisco Aironet 4500 and 4800 series cards (airo.c),
    implements AIROOLDIOCTL/SIOCDEVPRIVATE in airo_ioctl().
    
    The ioctl handler copies an aironet_ioctl struct from userspace, which
    includes a command and a length. Some of the commands are handled in
    readrids(), which kmalloc()'s a buffer of RIDSIZE (2048) bytes.
    
    That buffer is then passed to PC4500_readrid(), which has two cases.
    The else case does some setup and then reads up to RIDSIZE bytes from
    the hardware into the kmalloc()'ed buffer.
    
    Here len == RIDSIZE, pBuf is the kmalloc()'ed buffer:
    
            // read the rid length field
            bap_read(ai, pBuf, 2, BAP1);
            // length for remaining part of rid
            len = min(len, (int)le16_to_cpu(*(__le16*)pBuf)) - 2;
            ...
            // read remainder of the rid
            rc = bap_read(ai, ((__le16*)pBuf)+1, len, BAP1);
    
    PC4500_readrid() then returns to readrids() which does:
    
            len = comp->len;
            if (copy_to_user(comp->data, iobuf, min(len, (int)RIDSIZE))) {
    
    Where comp->len is the user controlled length field.
    
    So if the "rid length field" returned by the hardware is < 2048, and
    the user requests 2048 bytes in comp->len, we will leak the previous
    contents of the kmalloc()'ed buffer to userspace.
    
    Fix it by kzalloc()'ing the buffer.
    
    Found by Ilja by code inspection, not tested as I don't have the
    required hardware.
    
    Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 337776ece904d493448b1f2257b76ac43fe7e625
Author: Hannes Reinecke <hare@suse.de>
Date:   Thu Jan 16 11:20:53 2020 +0100

    scsi: fnic: do not queue commands during fwreset
    
    [ Upstream commit 0e2209629fec427ba75a6351486153a9feddd36b ]
    
    When a link is going down the driver will be calling fnic_cleanup_io(),
    which will traverse all commands and calling 'done' for each found command.
    While the traversal is handled under the host_lock, calling 'done' happens
    after the host_lock is being dropped.
    
    As fnic_queuecommand_lck() is being called with the host_lock held, it
    might well be that it will pick the command being selected for abortion
    from the above routine and enqueue it for sending, but then 'done' is being
    called on that very command from the above routine.
    
    Which of course confuses the hell out of the scsi midlayer.
    
    So fix this by not queueing commands when fnic_cleanup_io is active.
    
    Link: https://lore.kernel.org/r/20200116102053.62755-1-hare@suse.de
    Signed-off-by: Hannes Reinecke <hare@suse.de>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d233bd93b6ac06b0bd4f244c44549e029c7c47ad
Author: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date:   Mon Jan 13 09:32:46 2020 +0100

    vti[6]: fix packet tx through bpf_redirect()
    
    [ Upstream commit 95224166a9032ff5d08fca633d37113078ce7d01 ]
    
    With an ebpf program that redirects packets through a vti[6] interface,
    the packets are dropped because no dst is attached.
    
    This could also be reproduced with an AF_PACKET socket, with the following
    python script (vti1 is an ip_vti interface):
    
     import socket
     send_s = socket.socket(socket.AF_PACKET, socket.SOCK_RAW, 0)
     # scapy
     # p = IP(src='10.100.0.2', dst='10.200.0.1')/ICMP(type='echo-request')
     # raw(p)
     req = b'E\x00\x00\x1c\x00\x01\x00\x00@\x01e\xb2\nd\x00\x02\n\xc8\x00\x01\x08\x00\xf7\xff\x00\x00\x00\x00'
     send_s.sendto(req, ('vti1', 0x800, 0, 0))
    
    Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 18330f2ae8af3c713c40d46dac4f7b6e2ef10eca
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Jan 7 21:07:35 2020 +0100

    wireless: wext: avoid gcc -O3 warning
    
    [ Upstream commit e16119655c9e6c4aa5767cd971baa9c491f41b13 ]
    
    After the introduction of CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE_O3,
    the wext code produces a bogus warning:
    
    In function 'iw_handler_get_iwstats',
        inlined from 'ioctl_standard_call' at net/wireless/wext-core.c:1015:9,
        inlined from 'wireless_process_ioctl' at net/wireless/wext-core.c:935:10,
        inlined from 'wext_ioctl_dispatch.part.8' at net/wireless/wext-core.c:986:8,
        inlined from 'wext_handle_ioctl':
    net/wireless/wext-core.c:671:3: error: argument 1 null where non-null expected [-Werror=nonnull]
       memcpy(extra, stats, sizeof(struct iw_statistics));
       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    In file included from arch/x86/include/asm/string.h:5,
    net/wireless/wext-core.c: In function 'wext_handle_ioctl':
    arch/x86/include/asm/string_64.h:14:14: note: in a call to function 'memcpy' declared here
    
    The problem is that ioctl_standard_call() sometimes calls the handler
    with a NULL argument that would cause a problem for iw_handler_get_iwstats.
    However, iw_handler_get_iwstats never actually gets called that way.
    
    Marking that function as noinline avoids the warning and leads
    to slightly smaller object code as well.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Link: https://lore.kernel.org/r/20200107200741.3588770-1-arnd@arndb.de
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 3864a2a1fbb6714fe37e409e35886b3f5a053e6e
Author: Cambda Zhu <cambda@linux.alibaba.com>
Date:   Wed Nov 27 17:03:55 2019 +0800

    ixgbe: Fix calculation of queue with VFs and flow director on interface flap
    
    [ Upstream commit 4fad78ad6422d9bca62135bbed8b6abc4cbb85b8 ]
    
    This patch fixes the calculation of queue when we restore flow director
    filters after resetting adapter. In ixgbe_fdir_filter_restore(), filter's
    vf may be zero which makes the queue outside of the rx_ring array.
    
    The calculation is changed to the same as ixgbe_add_ethtool_fdir_entry().
    
    Signed-off-by: Cambda Zhu <cambda@linux.alibaba.com>
    Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit aa3971194e4a99f6fe42b856c872ebfcf0204276
Author: Radoslaw Tyl <radoslawx.tyl@intel.com>
Date:   Mon Nov 25 15:24:52 2019 +0100

    ixgbevf: Remove limit of 10 entries for unicast filter list
    
    [ Upstream commit aa604651d523b1493988d0bf6710339f3ee60272 ]
    
    Currently, though the FDB entry is added to VF, it does not appear in
    RAR filters. VF driver only allows to add 10 entries. Attempting to add
    another causes an error. This patch removes limitation and allows use of
    all free RAR entries for the FDB if needed.
    
    Fixes: 46ec20ff7d ("ixgbevf: Add macvlan support in the set rx mode op")
    Signed-off-by: Radoslaw Tyl <radoslawx.tyl@intel.com>
    Acked-by: Paul Menzel <pmenzel@molgen.mpg.de>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c69bc89b8deeadc4f9cf0c173899ab9769fb11ba
Author: Lubomir Rintel <lkundrak@v3.sk>
Date:   Wed Dec 18 20:04:54 2019 +0100

    clk: mmp2: Fix the order of timer mux parents
    
    [ Upstream commit 8bea5ac0fbc5b2103f8779ddff216122e3c2e1ad ]
    
    Determined empirically, no documentation is available.
    
    The OLPC XO-1.75 laptop used parent 1, that one being VCTCXO/4 (65MHz), but
    thought it's a VCTCXO/2 (130MHz). The mmp2 timer driver, not knowing
    what is going on, ended up just dividing the rate as of
    commit f36797ee4380 ("ARM: mmp/mmp2: dt: enable the clock")'
    
    Link: https://lore.kernel.org/r/20191218190454.420358-3-lkundrak@v3.sk
    Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
    Acked-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Olof Johansson <olof@lixom.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0406d59c89c88f6e636ac2c70fc36adf893f0c18
Author: Lee Jones <lee.jones@linaro.org>
Date:   Mon Feb 3 13:21:30 2020 +0000

    media: si470x-i2c: Move free() past last use of 'radio'
    
    A pointer to 'struct si470x_device' is currently used after free:
    
      drivers/media/radio/si470x/radio-si470x-i2c.c:462:25-30: ERROR: reference
        preceded by free on line 460
    
    Shift the call to free() down past its final use.
    
    NB: Not sending to Mainline, since the problem does not exist there, it was
    caused by the backport of 2df200ab234a ("media: si470x-i2c: add missed
    operations in remove") to the stable trees.
    
    Cc: <stable@vger.kernel.org> # v3.18+
    Reported-by: kbuild test robot <lkp@intel.com>
    Reported-by: Julia Lawall <julia.lawall@lip6.fr>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1da25d34b29b0640f83e0720ec2eb100c4d2c333
Author: Bin Liu <b-liu@ti.com>
Date:   Wed Dec 11 10:10:03 2019 -0600

    usb: dwc3: turn off VBUS when leaving host mode
    
    [ Upstream commit 09ed259fac621634d51cd986aa8d65f035662658 ]
    
    VBUS should be turned off when leaving the host mode.
    Set GCTL_PRTCAP to device mode in teardown to de-assert DRVVBUS pin to
    turn off VBUS power.
    
    Fixes: 5f94adfeed97 ("usb: dwc3: core: refactor mode initialization to its own function")
    Cc: stable@vger.kernel.org
    Signed-off-by: Bin Liu <b-liu@ti.com>
    Signed-off-by: Felipe Balbi <balbi@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit c39cef9673d12b5c57252ae5ef537596386cb6f0
Author: Zhenzhong Duan <zhenzhong.duan@gmail.com>
Date:   Mon Jan 13 11:48:42 2020 +0800

    ttyprintk: fix a potential deadlock in interrupt context issue
    
    commit 9a655c77ff8fc65699a3f98e237db563b37c439b upstream.
    
    tpk_write()/tpk_close() could be interrupted when holding a mutex, then
    in timer handler tpk_write() may be called again trying to acquire same
    mutex, lead to deadlock.
    
    Google syzbot reported this issue with CONFIG_DEBUG_ATOMIC_SLEEP
    enabled:
    
    BUG: sleeping function called from invalid context at
    kernel/locking/mutex.c:938
    in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 0, name: swapper/1
    1 lock held by swapper/1/0:
    ...
    Call Trace:
      <IRQ>
      dump_stack+0x197/0x210
      ___might_sleep.cold+0x1fb/0x23e
      __might_sleep+0x95/0x190
      __mutex_lock+0xc5/0x13c0
      mutex_lock_nested+0x16/0x20
      tpk_write+0x5d/0x340
      resync_tnc+0x1b6/0x320
      call_timer_fn+0x1ac/0x780
      run_timer_softirq+0x6c3/0x1790
      __do_softirq+0x262/0x98c
      irq_exit+0x19b/0x1e0
      smp_apic_timer_interrupt+0x1a3/0x610
      apic_timer_interrupt+0xf/0x20
      </IRQ>
    
    See link https://syzkaller.appspot.com/bug?extid=2eeef62ee31f9460ad65 for
    more details.
    
    Fix it by using spinlock in process context instead of mutex and having
    interrupt disabled in critical section.
    
    Reported-by: syzbot+2eeef62ee31f9460ad65@syzkaller.appspotmail.com
    Signed-off-by: Zhenzhong Duan <zhenzhong.duan@gmail.com>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Link: https://lore.kernel.org/r/20200113034842.435-1-zhenzhong.duan@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit adcd161ae408e2364e5bee917d9e36f8bb65a649
Author: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Date:   Tue Nov 12 10:22:28 2019 +0100

    media: dvb-usb/dvb-usb-urb.c: initialize actlen to 0
    
    commit 569bc8d6a6a50acb5fcf07fb10b8d2d461fdbf93 upstream.
    
    This fixes a syzbot failure since actlen could be uninitialized,
    but it was still used.
    
    Syzbot link:
    
    https://syzkaller.appspot.com/bug?extid=6bf9606ee955b646c0e1
    
    Reported-and-tested-by: syzbot+6bf9606ee955b646c0e1@syzkaller.appspotmail.com
    
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Acked-by: Sean Young <sean@mess.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f97f40aa9acad80851890015661c0995467c71b1
Author: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Date:   Tue Nov 12 10:22:24 2019 +0100

    media: gspca: zero usb_buf
    
    commit de89d0864f66c2a1b75becfdd6bf3793c07ce870 upstream.
    
    Allocate gspca_dev->usb_buf with kzalloc instead of kmalloc to
    ensure it is property zeroed. This fixes various syzbot errors
    about uninitialized data.
    
    Syzbot links:
    
    https://syzkaller.appspot.com/bug?extid=32310fc2aea76898d074
    https://syzkaller.appspot.com/bug?extid=99706d6390be1ac542a2
    https://syzkaller.appspot.com/bug?extid=64437af5c781a7f0e08e
    
    Reported-and-tested-by: syzbot+32310fc2aea76898d074@syzkaller.appspotmail.com
    Reported-and-tested-by: syzbot+99706d6390be1ac542a2@syzkaller.appspotmail.com
    Reported-and-tested-by: syzbot+64437af5c781a7f0e08e@syzkaller.appspotmail.com
    
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 299ec5f621f9668b7a84fbe7e16b9176af22212d
Author: Sean Young <sean@mess.org>
Date:   Sun Nov 10 11:04:40 2019 +0100

    media: digitv: don't continue if remote control state can't be read
    
    commit eecc70d22ae51225de1ef629c1159f7116476b2e upstream.
    
    This results in an uninitialized variable read.
    
    Reported-by: syzbot+6bf9606ee955b646c0e1@syzkaller.appspotmail.com
    Signed-off-by: Sean Young <sean@mess.org>
    Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 37f739275ff4160df79029087fe1e0452f56899d
Author: Jan Kara <jack@suse.cz>
Date:   Thu Dec 12 11:30:03 2019 +0100

    reiserfs: Fix memory leak of journal device string
    
    commit 5474ca7da6f34fa95e82edc747d5faa19cbdfb5c upstream.
    
    When a filesystem is mounted with jdev mount option, we store the
    journal device name in an allocated string in superblock. However we
    fail to ever free that string. Fix it.
    
    Reported-by: syzbot+1c6756baf4b16b94d2a6@syzkaller.appspotmail.com
    Fixes: c3aa077648e1 ("reiserfs: Properly display mount options in /proc/mounts")
    CC: stable@vger.kernel.org
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 364474e723933e18639e602a5dec84483b09ab2c
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Jan 30 22:11:07 2020 -0800

    mm/mempolicy.c: fix out of bounds write in mpol_parse_str()
    
    commit c7a91bc7c2e17e0a9c8b9745a2cb118891218fd1 upstream.
    
    What we are trying to do is change the '=' character to a NUL terminator
    and then at the end of the function we restore it back to an '='.  The
    problem is there are two error paths where we jump to the end of the
    function before we have replaced the '=' with NUL.
    
    We end up putting the '=' in the wrong place (possibly one element
    before the start of the buffer).
    
    Link: http://lkml.kernel.org/r/20200115055426.vdjwvry44nfug7yy@kili.mountain
    Reported-by: syzbot+e64a13c5369a194d67df@syzkaller.appspotmail.com
    Fixes: 095f1fc4ebf3 ("mempolicy: rework shmem mpol parsing and display")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Vlastimil Babka <vbabka@suse.cz>
    Dmitry Vyukov <dvyukov@google.com>
    Cc: Michal Hocko <mhocko@kernel.org>
    Cc: Dan Carpenter <dan.carpenter@oracle.com>
    Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ac4ba8055d59384aabd38e9099c5758641dc94f5
Author: Dirk Behme <dirk.behme@de.bosch.com>
Date:   Tue Jan 21 16:54:39 2020 +0100

    arm64: kbuild: remove compressed images on 'make ARCH=arm64 (dist)clean'
    
    commit d7bbd6c1b01cb5dd13c245d4586a83145c1d5f52 upstream.
    
    Since v4.3-rc1 commit 0723c05fb75e44 ("arm64: enable more compressed
    Image formats"), it is possible to build Image.{bz2,lz4,lzma,lzo}
    AArch64 images. However, the commit missed adding support for removing
    those images on 'make ARCH=arm64 (dist)clean'.
    
    Fix this by adding them to the target list.
    Make sure to match the order of the recipes in the makefile.
    
    Cc: stable@vger.kernel.org # v4.3+
    Fixes: 0723c05fb75e44 ("arm64: enable more compressed Image formats")
    Signed-off-by: Dirk Behme <dirk.behme@de.bosch.com>
    Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
    Reviewed-by: Masahiro Yamada <yamada.masahiro@socionext.com>
    Signed-off-by: Will Deacon <will@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a44a554303213de606340c19d4903472026b85f3
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Tue Nov 19 17:41:31 2019 +0800

    crypto: pcrypt - Fix user-after-free on module unload
    
    [ Upstream commit 07bfd9bdf568a38d9440c607b72342036011f727 ]
    
    On module unload of pcrypt we must unregister the crypto algorithms
    first and then tear down the padata structure.  As otherwise the
    crypto algorithms are still alive and can be used while the padata
    structure is being freed.
    
    Fixes: 5068c7a883d1 ("crypto: pcrypt - Add pcrypt crypto...")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a77a9c9125f37ab0dfb86a9bc105c157dc18e8a9
Author: Al Viro <viro@zeniv.linux.org.uk>
Date:   Sat Feb 1 16:26:45 2020 +0000

    vfs: fix do_last() regression
    
    commit 6404674acd596de41fd3ad5f267b4525494a891a upstream.
    
    Brown paperbag time: fetching ->i_uid/->i_mode really should've been
    done from nd->inode.  I even suggested that, but the reason for that has
    slipped through the cracks and I went for dir->d_inode instead - made
    for more "obvious" patch.
    
    Analysis:
    
     - at the entry into do_last() and all the way to step_into(): dir (aka
       nd->path.dentry) is known not to have been freed; so's nd->inode and
       it's equal to dir->d_inode unless we are already doomed to -ECHILD.
       inode of the file to get opened is not known.
    
     - after step_into(): inode of the file to get opened is known; dir
       might be pointing to freed memory/be negative/etc.
    
     - at the call of may_create_in_sticky(): guaranteed to be out of RCU
       mode; inode of the file to get opened is known and pinned; dir might
       be garbage.
    
    The last was the reason for the original patch.  Except that at the
    do_last() entry we can be in RCU mode and it is possible that
    nd->path.dentry->d_inode has already changed under us.
    
    In that case we are going to fail with -ECHILD, but we need to be
    careful; nd->inode is pointing to valid struct inode and it's the same
    as nd->path.dentry->d_inode in "won't fail with -ECHILD" case, so we
    should use that.
    
    Reported-by: "Rantala, Tommi T. (Nokia - FI/Espoo)" <tommi.t.rantala@nokia.com>
    Reported-by: syzbot+190005201ced78a74ad6@syzkaller.appspotmail.com
    Wearing-brown-paperbag: Al Viro <viro@zeniv.linux.org.uk>
    Cc: stable@kernel.org
    Fixes: d0cb50185ae9 ("do_last(): fetch directory ->i_mode and ->i_uid before it's too late")
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f6b09fe8365955e5b5343464ca88134471d6184e
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Thu Dec 5 13:45:05 2019 +0800

    crypto: af_alg - Use bh_lock_sock in sk_destruct
    
    commit 37f96694cf73ba116993a9d2d99ad6a75fa7fdb0 upstream.
    
    As af_alg_release_parent may be called from BH context (most notably
    due to an async request that only completes after socket closure,
    or as reported here because of an RCU-delayed sk_destruct call), we
    must use bh_lock_sock instead of lock_sock.
    
    Reported-by: syzbot+c2f1558d49e25cc36e5e@syzkaller.appspotmail.com
    Reported-by: Eric Dumazet <eric.dumazet@gmail.com>
    Fixes: c840ac6af3f8 ("crypto: af_alg - Disallow bind/setkey/...")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 391af3d825fbf432d27e9b965dff57cb80fb53d0
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Jan 24 14:57:20 2020 -0800

    net_sched: ematch: reject invalid TCF_EM_SIMPLE
    
    [ Upstream commit 55cd9f67f1e45de8517cdaab985fb8e56c0bc1d8 ]
    
    It is possible for malicious userspace to set TCF_EM_SIMPLE bit
    even for matches that should not have this bit set.
    
    This can fool two places using tcf_em_is_simple()
    
    1) tcf_em_tree_destroy() -> memory leak of em->data
       if ops->destroy() is NULL
    
    2) tcf_em_tree_dump() wrongly report/leak 4 low-order bytes
       of a kernel pointer.
    
    BUG: memory leak
    unreferenced object 0xffff888121850a40 (size 32):
      comm "syz-executor927", pid 7193, jiffies 4294941655 (age 19.840s)
      hex dump (first 32 bytes):
        00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00  ................
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      backtrace:
        [<00000000f67036ea>] kmemleak_alloc_recursive include/linux/kmemleak.h:43 [inline]
        [<00000000f67036ea>] slab_post_alloc_hook mm/slab.h:586 [inline]
        [<00000000f67036ea>] slab_alloc mm/slab.c:3320 [inline]
        [<00000000f67036ea>] __do_kmalloc mm/slab.c:3654 [inline]
        [<00000000f67036ea>] __kmalloc_track_caller+0x165/0x300 mm/slab.c:3671
        [<00000000fab0cc8e>] kmemdup+0x27/0x60 mm/util.c:127
        [<00000000d9992e0a>] kmemdup include/linux/string.h:453 [inline]
        [<00000000d9992e0a>] em_nbyte_change+0x5b/0x90 net/sched/em_nbyte.c:32
        [<000000007e04f711>] tcf_em_validate net/sched/ematch.c:241 [inline]
        [<000000007e04f711>] tcf_em_tree_validate net/sched/ematch.c:359 [inline]
        [<000000007e04f711>] tcf_em_tree_validate+0x332/0x46f net/sched/ematch.c:300
        [<000000007a769204>] basic_set_parms net/sched/cls_basic.c:157 [inline]
        [<000000007a769204>] basic_change+0x1d7/0x5f0 net/sched/cls_basic.c:219
        [<00000000e57a5997>] tc_new_tfilter+0x566/0xf70 net/sched/cls_api.c:2104
        [<0000000074b68559>] rtnetlink_rcv_msg+0x3b2/0x4b0 net/core/rtnetlink.c:5415
        [<00000000b7fe53fb>] netlink_rcv_skb+0x61/0x170 net/netlink/af_netlink.c:2477
        [<00000000e83a40d0>] rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5442
        [<00000000d62ba933>] netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline]
        [<00000000d62ba933>] netlink_unicast+0x223/0x310 net/netlink/af_netlink.c:1328
        [<0000000088070f72>] netlink_sendmsg+0x2c0/0x570 net/netlink/af_netlink.c:1917
        [<00000000f70b15ea>] sock_sendmsg_nosec net/socket.c:639 [inline]
        [<00000000f70b15ea>] sock_sendmsg+0x54/0x70 net/socket.c:659
        [<00000000ef95a9be>] ____sys_sendmsg+0x2d0/0x300 net/socket.c:2330
        [<00000000b650f1ab>] ___sys_sendmsg+0x8a/0xd0 net/socket.c:2384
        [<0000000055bfa74a>] __sys_sendmsg+0x80/0xf0 net/socket.c:2417
        [<000000002abac183>] __do_sys_sendmsg net/socket.c:2426 [inline]
        [<000000002abac183>] __se_sys_sendmsg net/socket.c:2424 [inline]
        [<000000002abac183>] __x64_sys_sendmsg+0x23/0x30 net/socket.c:2424
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reported-by: syzbot+03c4738ed29d5d366ddf@syzkaller.appspotmail.com
    Cc: Cong Wang <xiyou.wangcong@gmail.com>
    Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 980494f6d53216a8f8ff97fd8c5a851e78ea95f9
Author: Laura Abbott <labbott@fedoraproject.org>
Date:   Tue Sep 8 09:53:38 2015 -0700

    usb-storage: Disable UAS on JMicron SATA enclosure
    
    [ Upstream commit bc3bdb12bbb3492067c8719011576370e959a2e6 ]
    
    Steve Ellis reported incorrect block sizes and alignement
    offsets with a SATA enclosure. Adding a quirk to disable
    UAS fixes the problems.
    
    Reported-by: Steven Ellis <sellis@redhat.com>
    Cc: Pacho Ramos <pachoramos@gmail.com>
    Signed-off-by: Laura Abbott <labbott@fedoraproject.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 104c94d7a0316a81cee8c16995e0d918f952f7da
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Jan 7 21:43:59 2020 +0100

    atm: eni: fix uninitialized variable warning
    
    [ Upstream commit 30780d086a83332adcd9362281201cee7c3d9d19 ]
    
    With -O3, gcc has found an actual unintialized variable stored
    into an mmio register in two instances:
    
    drivers/atm/eni.c: In function 'discard':
    drivers/atm/eni.c:465:13: error: 'dma[1]' is used uninitialized in this function [-Werror=uninitialized]
       writel(dma[i*2+1],eni_dev->rx_dma+dma_wr*8+4);
                 ^
    drivers/atm/eni.c:465:13: error: 'dma[3]' is used uninitialized in this function [-Werror=uninitialized]
    
    Change the code to always write zeroes instead.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b6547a7db83929a457adad01a97eaf70c9a76dd6
Author: Krzysztof Kozlowski <krzk@kernel.org>
Date:   Sat Jan 4 15:31:43 2020 +0100

    net: wan: sdla: Fix cast from pointer to integer of different size
    
    [ Upstream commit 00c0688cecadbf7ac2f5b4cdb36d912a2d3f0cca ]
    
    Since net_device.mem_start is unsigned long, it should not be cast to
    int right before casting to pointer.  This fixes warning (compile
    testing on alpha architecture):
    
        drivers/net/wan/sdla.c: In function ‘sdla_transmit’:
        drivers/net/wan/sdla.c:711:13: warning:
            cast to pointer from integer of different size [-Wint-to-pointer-cast]
    
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 93e0aca969d9833e923a41bc46ea1ede0a463bd9
Author: Fenghua Yu <fenghua.yu@intel.com>
Date:   Thu Jan 2 13:27:06 2020 -0800

    drivers/net/b44: Change to non-atomic bit operations on pwol_mask
    
    [ Upstream commit f11421ba4af706cb4f5703de34fa77fba8472776 ]
    
    Atomic operations that span cache lines are super-expensive on x86
    (not just to the current processor, but also to other processes as all
    memory operations are blocked until the operation completes). Upcoming
    x86 processors have a switch to cause such operations to generate a #AC
    trap. It is expected that some real time systems will enable this mode
    in BIOS.
    
    In preparation for this, it is necessary to fix code that may execute
    atomic instructions with operands that cross cachelines because the #AC
    trap will crash the kernel.
    
    Since "pwol_mask" is local and never exposed to concurrency, there is
    no need to set bits in pwol_mask using atomic operations.
    
    Directly operate on the byte which contains the bit instead of using
    __set_bit() to avoid any big endian concern due to type cast to
    unsigned long in __set_bit().
    
    Suggested-by: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
    Signed-off-by: Tony Luck <tony.luck@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a40ee3d6d29b6a89b9b4d8c7cead47723bd5ca92
Author: Andreas Kemnade <andreas@kemnade.info>
Date:   Fri Dec 13 22:48:02 2019 +0100

    watchdog: rn5t618_wdt: fix module aliases
    
    [ Upstream commit a76dfb859cd42df6e3d1910659128ffcd2fb6ba2 ]
    
    Platform device aliases were missing so module autoloading
    did not work.
    
    Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/20191213214802.22268-1-andreas@kemnade.info
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 16ebb24441be0ec6163a0d8d5f9440d6c147dc63
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Dec 10 12:44:26 2019 +0100

    zd1211rw: fix storage endpoint lookup
    
    commit 2d68bb2687abb747558b933e80845ff31570a49c upstream.
    
    Make sure to use the current alternate setting when verifying the
    storage interface descriptors to avoid submitting an URB to an invalid
    endpoint.
    
    Failing to do so could cause the driver to misbehave or trigger a WARN()
    in usb_submit_urb() that kernels with panic_on_warn set would choke on.
    
    Fixes: a1030e92c150 ("[PATCH] zd1211rw: Convert installer CDROM device into WLAN device")
    Cc: stable <stable@vger.kernel.org>     # 2.6.19
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cc62a25dba105e4636b9bafcd1a1f836960ee659
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Dec 10 12:44:24 2019 +0100

    rtl8xxxu: fix interface sanity check
    
    commit 39a4281c312f2d226c710bc656ce380c621a2b16 upstream.
    
    Make sure to use the current alternate setting when verifying the
    interface descriptors to avoid binding to an invalid interface.
    
    Failing to do so could cause the driver to misbehave or trigger a WARN()
    in usb_submit_urb() that kernels with panic_on_warn set would choke on.
    
    Fixes: 26f1fad29ad9 ("New driver: rtl8xxxu (mac80211)")
    Cc: stable <stable@vger.kernel.org>     # 4.4
    Cc: Jes Sorensen <Jes.Sorensen@redhat.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8e0d0c6786776567a70ec564b885299b8af17b25
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Dec 10 12:44:22 2019 +0100

    brcmfmac: fix interface sanity check
    
    commit 3428fbcd6e6c0850b1a8b2a12082b7b2aabb3da3 upstream.
    
    Make sure to use the current alternate setting when verifying the
    interface descriptors to avoid binding to an invalid interface.
    
    Failing to do so could cause the driver to misbehave or trigger a WARN()
    in usb_submit_urb() that kernels with panic_on_warn set would choke on.
    
    Fixes: 71bb244ba2fd ("brcm80211: fmac: add USB support for bcm43235/6/8 chipsets")
    Cc: stable <stable@vger.kernel.org>     # 3.4
    Cc: Arend van Spriel <arend@broadcom.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f1f36e7796a57c3ad54205b7b75b345dcf4c4189
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Dec 10 12:44:20 2019 +0100

    ath9k: fix storage endpoint lookup
    
    commit 0ef332951e856efa89507cdd13ba8f4fb8d4db12 upstream.
    
    Make sure to use the current alternate setting when verifying the
    storage interface descriptors to avoid submitting an URB to an invalid
    endpoint.
    
    Failing to do so could cause the driver to misbehave or trigger a WARN()
    in usb_submit_urb() that kernels with panic_on_warn set would choke on.
    
    Fixes: 36bcce430657 ("ath9k_htc: Handle storage devices")
    Cc: stable <stable@vger.kernel.org>     # 2.6.39
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b9e9c736dea99c6b1b8771a27ddd813e48a7f275
Author: Malcolm Priestley <tvboxspy@gmail.com>
Date:   Wed Jan 8 21:41:36 2020 +0000

    staging: vt6656: Fix false Tx excessive retries reporting.
    
    commit 9dd631fa99dc0a0dfbd191173bf355ba30ea786a upstream.
    
    The driver reporting  IEEE80211_TX_STAT_ACK is not being handled
    correctly. The driver should only report on TSR_TMO flag is not
    set indicating no transmission errors and when not IEEE80211_TX_CTL_NO_ACK
    is being requested.
    
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
    Link: https://lore.kernel.org/r/340f1f7f-c310-dca5-476f-abc059b9cd97@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4f92be3f8154583fa04c4f4a48416d5c3cc47355
Author: Malcolm Priestley <tvboxspy@gmail.com>
Date:   Wed Jan 8 21:41:20 2020 +0000

    staging: vt6656: use NULLFUCTION stack on mac80211
    
    commit d579c43c82f093e63639151625b2139166c730fd upstream.
    
    It appears that the drivers does not go into power save correctly the
    NULL data packets are not being transmitted because it not enabled
    in mac80211.
    
    The driver needs to capture ieee80211_is_nullfunc headers and
    copy the duration_id to it's own duration data header.
    
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
    Link: https://lore.kernel.org/r/610971ae-555b-a6c3-61b3-444a0c1e35b4@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3c25bc66459562e6e8021affad59f89885d198b7
Author: Malcolm Priestley <tvboxspy@gmail.com>
Date:   Wed Jan 8 21:40:58 2020 +0000

    staging: vt6656: correct packet types for CTS protect, mode.
    
    commit d971fdd3412f8342747778fb59b8803720ed82b1 upstream.
    
    It appears that the driver still transmits in CTS protect mode even
    though it is not enabled in mac80211.
    
    That is both packet types PK_TYPE_11GA and PK_TYPE_11GB both use CTS protect.
    The only difference between them GA does not use B rates.
    
    Find if only B rate in GB or GA in protect mode otherwise transmit packets
    as PK_TYPE_11A.
    
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
    Link: https://lore.kernel.org/r/9c1323ff-dbb3-0eaa-43e1-9453f7390dc0@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e5a7333b9140582d4cb9eccb995445f4845610bc
Author: Colin Ian King <colin.king@canonical.com>
Date:   Tue Jan 14 18:16:04 2020 +0000

    staging: wlan-ng: ensure error return is actually returned
    
    commit 4cc41cbce536876678b35e03c4a8a7bb72c78fa9 upstream.
    
    Currently when the call to prism2sta_ifst fails a netdev_err error
    is reported, error return variable result is set to -1 but the
    function always returns 0 for success.  Fix this by returning
    the error value in variable result rather than 0.
    
    Addresses-Coverity: ("Unused value")
    Fixes: 00b3ed168508 ("Staging: add wlan-ng prism2 usb driver")
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200114181604.390235-1-colin.king@canonical.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 917c8fe39f4d42c3850b22d6a0bf3ffab1466d19
Author: Andrey Shvetsov <andrey.shvetsov@k2l.de>
Date:   Thu Jan 16 18:22:39 2020 +0100

    staging: most: net: fix buffer overflow
    
    commit 4d1356ac12f4d5180d0df345d85ff0ee42b89c72 upstream.
    
    If the length of the socket buffer is 0xFFFFFFFF (max size for an
    unsigned int), then payload_len becomes 0xFFFFFFF1 after subtracting 14
    (ETH_HLEN).  Then, mdp_len is set to payload_len + 16 (MDP_HDR_LEN)
    which overflows and results in a value of 2.  These values for
    payload_len and mdp_len will pass current buffer size checks.
    
    This patch checks if derived from skb->len sum may overflow.
    
    The check is based on the following idea:
    
    For any `unsigned V1, V2` and derived `unsigned SUM = V1 + V2`,
    `V1 + V2` overflows iif `SUM < V1`.
    
    Reported-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Andrey Shvetsov <andrey.shvetsov@k2l.de>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200116172238.6046-1-andrey.shvetsov@microchip.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 32c4ed0c4ab87049392eed36d7e92e6b22dd46cd
Author: Johan Hovold <johan@kernel.org>
Date:   Wed Jan 22 11:15:28 2020 +0100

    USB: serial: ir-usb: fix IrLAP framing
    
    commit 38c0d5bdf4973f9f5a888166e9d3e9ed0d32057a upstream.
    
    Commit f4a4cbb2047e ("USB: ir-usb: reimplement using generic framework")
    switched to using the generic write implementation which may combine
    multiple write requests into larger transfers. This can break the IrLAP
    protocol where end-of-frame is determined using the USB short packet
    mechanism, for example, if multiple frames are sent in rapid succession.
    
    Fixes: f4a4cbb2047e ("USB: ir-usb: reimplement using generic framework")
    Cc: stable <stable@vger.kernel.org>     # 2.6.35
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 39fa352a77dd67cecac212a9ff84369ed7c34de7
Author: Johan Hovold <johan@kernel.org>
Date:   Wed Jan 22 11:15:27 2020 +0100

    USB: serial: ir-usb: fix link-speed handling
    
    commit 17a0184ca17e288decdca8b2841531e34d49285f upstream.
    
    Commit e0d795e4f36c ("usb: irda: cleanup on ir-usb module") added a USB
    IrDA header with common defines, but mistakingly switched to using the
    class-descriptor baud-rate bitmask values for the outbound header.
    
    This broke link-speed handling for rates above 9600 baud, but a device
    would also be able to operate at the default 9600 baud until a
    link-speed request was issued (e.g. using the TCGETS ioctl).
    
    Fixes: e0d795e4f36c ("usb: irda: cleanup on ir-usb module")
    Cc: stable <stable@vger.kernel.org>     # 2.6.27
    Cc: Felipe Balbi <balbi@kernel.org>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fa2cee6f614a0ce47fda9b65c8f1f0a379a61b14
Author: Johan Hovold <johan@kernel.org>
Date:   Wed Jan 22 11:15:26 2020 +0100

    USB: serial: ir-usb: add missing endpoint sanity check
    
    commit 2988a8ae7476fe9535ab620320790d1714bdad1d upstream.
    
    Add missing endpoint sanity check to avoid dereferencing a NULL-pointer
    on open() in case a device lacks a bulk-out endpoint.
    
    Note that prior to commit f4a4cbb2047e ("USB: ir-usb: reimplement using
    generic framework") the oops would instead happen on open() if the
    device lacked a bulk-in endpoint and on write() if it lacked a bulk-out
    endpoint.
    
    Fixes: f4a4cbb2047e ("USB: ir-usb: reimplement using generic framework")
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Cc: stable <stable@vger.kernel.org>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ba1814393f495e884f4400e3273d57d5ade00abd
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Dec 10 12:44:25 2019 +0100

    rsi_91x_usb: fix interface sanity check
    
    commit 3139b180906af43bc09bd3373fc2338a8271d9d9 upstream.
    
    Make sure to use the current alternate setting when verifying the
    interface descriptors to avoid binding to an invalid interface.
    
    Failing to do so could cause the driver to misbehave or trigger a WARN()
    in usb_submit_urb() that kernels with panic_on_warn set would choke on.
    
    Fixes: dad0d04fa7ba ("rsi: Add RS9113 wireless driver")
    Cc: stable <stable@vger.kernel.org>     # 3.15
    Cc: Fariya Fatima <fariyaf@gmail.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 036951850f0e843cb3c90345d55ba724c06748e5
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Dec 10 12:44:23 2019 +0100

    orinoco_usb: fix interface sanity check
    
    commit b73e05aa543cf8db4f4927e36952360d71291d41 upstream.
    
    Make sure to use the current alternate setting when verifying the
    interface descriptors to avoid binding to an invalid interface.
    
    Failing to do so could cause the driver to misbehave or trigger a WARN()
    in usb_submit_urb() that kernels with panic_on_warn set would choke on.
    
    Fixes: 9afac70a7305 ("orinoco: add orinoco_usb driver")
    Cc: stable <stable@vger.kernel.org>     # 2.6.35
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1f4ffc0fcdfa9f180b95b47e3053003b7425b826
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Jan 29 10:40:41 2020 +0100

    ALSA: pcm: Add missing copy ops check before clearing buffer
    
    [ this is a fix specific to 4.4.y and 4.9.y stable trees;
      4.14.y and older already contain the right fix ]
    
    The stable 4.4.y and 4.9.y backports of the upstream commit
    add9d56d7b37 ("ALSA: pcm: Avoid possible info leaks from PCM stream
    buffers") dropped the check of substream->ops->copy_user as copy_user
    is a new member that isn't present in the older kernels.
    Although upstream drivers should work without this NULL check, it may
    cause a regression with a downstream driver that sets some
    inaccessible address to runtime->dma_area, leading to a crash at
    worst.
    
    Since such drivers must have ops->copy member on older kernels instead
    of ops->copy_user, this patch adds the missing check of ops->copy for
    fixing the regression.
    
    Reported-and-tested-by: Andreas Schneider <asn@cryptomilk.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>