commit 49859d3c5536d4df90142b280e8135efd3de2833
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun Apr 8 14:27:40 2018 +0200

    Linux 4.15.16

commit b36c97615b985fe910fc6ae20afd2fad3b82ce8d
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Apr 6 09:46:28 2018 +0200

    Revert "ip6_vti: adjust vti mtu according to mtu of lower device"
    
    This reverts commit 813b2dad2cb59d2759f1538e65d56dcccdb18a94 which is
    commit 53c81e95df1793933f87748d36070a721f6cb287 upstream.
    
    Ben writes that there are a number of follow-on patches needed to fix
    this up, but they get complex to backport, and some custom fixes are
    needed, so let's just revert this and wait for a "real" set of patches
    to resolve this to be submitted if it is really needed.
    
    Reported-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Cc: Petr Vorel <pvorel@suse.cz>
    Cc: Alexey Kodanev <alexey.kodanev@oracle.com>
    Cc: David S. Miller <davem@davemloft.net>
    Cc: Stefano Brivio <sbrivio@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f4c360885236357b1aefa6c2be1aeef7c8daa6ab
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Apr 6 09:06:53 2018 +0200

    Revert "cpufreq: Fix governor module removal race"
    
    This reverts commit a853301f77b5c4feb5e17aebfd92018269525523 which was
    commit a8b149d32b663c1a4105273295184b78f53d33cf upstream.
    
    The backport was not correct, so just drop it entirely.
    
    Reported-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Cc: Viresh Kumar <viresh.kumar@linaro.org>
    Cc: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2dae6069c488ea958ff08593cca967e05a6acd24
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Apr 6 08:54:26 2018 +0200

    Revert "ARM: dts: omap3-n900: Fix the audio CODEC's reset pin"
    
    This reverts commit c91a501768717f449acd1c2cff1a8531e486c441 which was
    commit 7be4b5dc7ffa9499ac6ef33a5ffa9ff43f9b7057 upstream.
    
    It requires a driver that was not merged until 4.16, so remove it from
    this stable tree as it is pointless.
    
    Reported-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Cc: Andrew F. Davis <afd@ti.com>
    Cc: Tony Lindgren <tony@atomide.com>
    Cc: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0dd269e2a25b332daee24533cc76cde9a8e5772f
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri Apr 6 08:49:19 2018 +0200

    Revert "ARM: dts: am335x-pepper: Fix the audio CODEC's reset pin"
    
    This reverts commit cc578825b46e984c19b4a4630d3191d60ff83642 which was
    comit e153db03c6b7a035c797bcdf35262586f003ee93 upstream.
    
    It requires a driver that was not merged until 4.16, so remove it from
    this stable tree as it is pointless.
    
    Reported-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Cc: Andrew F. Davis <afd@ti.com>
    Cc: Tony Lindgren <tony@atomide.com>
    Cc: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 657fda9505c872fe4a32afbbd6cde0aa2aae4e32
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Wed Mar 21 12:49:29 2018 -0400

    Fix slab name "biovec-(1<<(21-12))"
    
    commit bd5c4facf59648581d2f1692dad7b107bf429954 upstream.
    
    I'm getting a slab named "biovec-(1<<(21-12))". It is caused by unintended
    expansion of the macro BIO_MAX_PAGES. This patch renames it to biovec-max.
    
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Cc: stable@vger.kernel.org      # v4.14+
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8282afd8abee4f4b5c31250b59bdc120d66c121c
Author: Matthias Brugger <matthias.bgg@gmail.com>
Date:   Thu Mar 15 17:54:20 2018 +0100

    net: hns: Fix ethtool private flags
    
    commit d61d263c8d82db7c4404a29ebc29674b1c0c05c9 upstream.
    
    The driver implementation returns support for private flags, while
    no private flags are present. When asked for the number of private
    flags it returns the number of statistic flag names.
    
    Fix this by returning EOPNOTSUPP for not implemented ethtool flags.
    
    Signed-off-by: Matthias Brugger <mbrugger@suse.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 84c68b621e9053fc18055464c39e270efb662306
Author: Keerthy <j-keerthy@ti.com>
Date:   Tue Oct 24 14:14:08 2017 +0530

    ARM: dts: DRA76-EVM: Set powerhold property for tps65917
    
    commit aac4619d028e2c444ac1217fc2d05b0322079dff upstream.
    
    Set powerhold property for tps65917
    
    Signed-off-by: Keerthy <j-keerthy@ti.com>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Cc: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3d07d9f2eebbb6014b6865529567c79dcfee7328
Author: Mike Frysinger <vapier@chromium.org>
Date:   Mon Jan 29 17:08:21 2018 -0500

    vt: change SGR 21 to follow the standards
    
    commit 65d9982d7e523a1a8e7c9af012da0d166f72fc56 upstream.
    
    ECMA-48 [1] (aka ISO 6429) has defined SGR 21 as "doubly underlined"
    since at least March 1984.  The Linux kernel has treated it as SGR 22
    "normal intensity" since it was added in Linux-0.96b in June 1992.
    Before that, it was simply ignored.  Other terminal emulators have
    either ignored it, or treat it as double underline now.  xterm for
    example added support in its 304 release (May 2014) [2] where it was
    previously ignoring it.
    
    Changing this behavior shouldn't be an issue:
    - It isn't a named capability in ncurses's terminfo database, so no
      script is using libtinfo/libcurses to look this up, or using tput
      to query & output the right sequence.
    - Any script assuming SGR 21 will reset intensity in all terminals
      already do not work correctly on non-Linux VTs (including running
      under screen/tmux/etc...).
    - If someone has written a script that only runs in the Linux VT, and
      they're using SGR 21 (instead of SGR 22), the output should still
      be readable.
    
    imo it's important to change this as the Linux VT's non-conformance
    is sometimes used as an argument for other terminal emulators to not
    implement SGR 21 at all, or do so incorrectly.
    
    [1]: https://www.ecma-international.org/publications/standards/Ecma-048.htm
    [2]: https://github.com/ThomasDickey/xterm-snapshots/commit/2fd29cb98d214cb536bcafbee00bc73b3f1eeb9d
    
    Signed-off-by: Mike Frysinger <vapier@chromium.org>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 48eaa5be295ca5daf20c8a8473e6cb8734b9029b
Author: Ondrej Zary <linux@rainbow-software.org>
Date:   Tue Apr 3 10:24:34 2018 -0700

    Input: i8042 - enable MUX on Sony VAIO VGN-CS series to fix touchpad
    
    commit 04bb1719c4de94700056241d4c0fe3c1413f5aff upstream.
    
    The touch sensor buttons on Sony VAIO VGN-CS series laptops (e.g.
    VGN-CS31S) are a separate PS/2 device. As the MUX is disabled for all
    VAIO machines by the nomux blacklist, the data from touch sensor
    buttons and touchpad are combined. The protocol used by the buttons is
    probably similar to the touchpad protocol (both are Synaptics) so both
    devices get enabled. The controller combines the data, creating a mess
    which results in random button clicks, touchpad stopping working and
    lost sync error messages:
    psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 4
    psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
    psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
    psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
    psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at byte 1
    psmouse serio1: issuing reconnect request
    
    Add a new i8042_dmi_forcemux_table whitelist with VGN-CS.
    With MUX enabled, touch sensor buttons are detected as separate device
    (and left disabled as there's currently no driver), fixing all touchpad
    problems.
    
    Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fd50992f99c2e11a5a6e3bab2a86b9f29eafa9d7
Author: Dennis Wassenberg <dennis.wassenberg@secunet.com>
Date:   Thu Mar 8 15:32:09 2018 -0800

    Input: i8042 - add Lenovo ThinkPad L460 to i8042 reset list
    
    commit b56af54ac78c54a519d82813836f305d7f76ef27 upstream.
    
    Reset i8042 before probing because of insufficient BIOS initialisation of
    the i8042 serial controller. This makes Synaptics touchpad detection
    possible. Without resetting the Synaptics touchpad is not detected because
    there are always NACK messages from AUX port.
    
    Signed-off-by: Dennis Wassenberg <dennis.wassenberg@secunet.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ec46704f08e8065e2a8a24a60613d9debe583b16
Author: Masaki Ota <masaki.ota@jp.alps.com>
Date:   Mon Jan 29 14:36:54 2018 -0800

    Input: ALPS - fix TrackStick detection on Thinkpad L570 and Latitude 7370
    
    commit 567b9b549cfa1cbc202762ae97b5385c29ade1e3 upstream.
    
    The primary interface for the touchpad device in Thinkpad L570 is SMBus,
    so ALPS overlooked PS2 interface Firmware setting of TrackStick, and
    shipped with TrackStick otp bit is disabled.
    
    The address 0xD7 contains device number information, so we can identify
    the device by checking this value, but to access it we need to enable
    Command mode, and then re-enable the device. Devices shipped in Thinkpad
    L570 report either 0x0C or 0x1D as device numbers, if we see them we assume
    that the devices are DualPoints.
    
    The same issue exists on Dell Latitude 7370.
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=196929
    Fixes: 646580f793 ("Input: ALPS - fix multi-touch decoding on SS4 plus touchpads")
    Signed-off-by: Masaki Ota <masaki.ota@jp.alps.com>
    Tested-by: Aaron Ma <aaron.ma@canonical.com>
    Tested-by: Jonathan Liu <net147@gmail.com>
    Tested-by: Jaak Ristioja <jaak@ristioja.ee>
    Cc: stable@vger.kernel.org
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9abdc666b79307533f34934d156c4072df723ff6
Author: Gaku Inami <gaku.inami.xh@renesas.com>
Date:   Tue Feb 13 11:06:40 2018 +0900

    Revert "base: arch_topology: fix section mismatch build warnings"
    
    commit 9de9a449482677a75f1edd2049268a7efc40fc96 upstream.
    
    This reverts commit 452562abb5b7 ("base: arch_topology: fix section
    mismatch build warnings"). It causes the notifier call hangs in some
    use-cases.
    
    In some cases with using maxcpus, some of cpus are booted first and
    then the remaining cpus are booted. As an example, some users who want
    to realize fast boot up often use the following procedure.
    
      1) Define all CPUs on device tree (CA57x4 + CA53x4)
      2) Add "maxcpus=4" in bootargs
      3) Kernel boot up with CA57x4
      4) After kernel boot up, CA53x4 is booted from user
    
    When kernel init was finished, CPUFREQ_POLICY_NOTIFIER was not still
    unregisterd. This means that "__init init_cpu_capacity_callback()"
    will be called after kernel init sequence. To avoid this problem,
    it needs to remove __init{,data} annotations by reverting this commit.
    
    Also, this commit was needed to fix kernel compile issue below.
    However, this issue was also fixed by another patch: commit 82d8ba717ccb
    ("arch_topology: Fix section miss match warning due to
    free_raw_capacity()") in v4.15 as well.
    Whereas commit 452562abb5b7 added all the missing __init annotations,
    commit 82d8ba717ccb removed it from free_raw_capacity().
    
    WARNING: vmlinux.o(.text+0x548f24): Section mismatch in reference
    from the function init_cpu_capacity_callback() to the variable
    .init.text:$x
    The function init_cpu_capacity_callback() references
    the variable __init $x.
    This is often because init_cpu_capacity_callback lacks a __init
    annotation or the annotation of $x is wrong.
    
    Fixes: 82d8ba717ccb ("arch_topology: Fix section miss match warning due to free_raw_capacity()")
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Gaku Inami <gaku.inami.xh@renesas.com>
    Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
    Tested-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
    Acked-by: Sudeep Holla <sudeep.holla@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f1fcba111d9e06fae23557551e312c9bb41236d5
Author: Frank Mori Hess <fmh6jj@gmail.com>
Date:   Thu Mar 15 10:25:44 2018 +0000

    staging: comedi: ni_mio_common: ack ai fifo error interrupts.
    
    commit e1d9fc04c41840a4688ef6ce90b6dcca157ea4d7 upstream.
    
    Ack ai fifo error interrupts in interrupt handler to clear interrupt
    after fifo overflow.  It should prevent lock-ups after the ai fifo
    overflows.
    
    Cc: <stable@vger.kernel.org> # v4.2+
    Signed-off-by: Frank Mori Hess <fmh6jj@gmail.com>
    Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 21f07630e75f28f77ac591d9d84e0a92d31bc1b6
Author: Liu Bo <bo.li.liu@oracle.com>
Date:   Wed Jan 31 17:09:13 2018 -0700

    Btrfs: fix unexpected cow in run_delalloc_nocow
    
    commit 5811375325420052fcadd944792a416a43072b7f upstream.
    
    Fstests generic/475 provides a way to fail metadata reads while
    checking if checksum exists for the inode inside run_delalloc_nocow(),
    and csum_exist_in_range() interprets error (-EIO) as inode having
    checksum and makes its caller enter the cow path.
    
    In case of free space inode, this ends up with a warning in
    cow_file_range().
    
    The same problem applies to btrfs_cross_ref_exist() since it may also
    read metadata in between.
    
    With this, run_delalloc_nocow() bails out when errors occur at the two
    places.
    
    cc: <stable@vger.kernel.org> v2.6.28+
    Fixes: 17d217fe970d ("Btrfs: fix nodatasum handling in balancing code")
    Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e847da275f046b0f17954f376e26e52cebf0cd4a
Author: Eric Biggers <ebiggers@google.com>
Date:   Mon Feb 19 23:48:12 2018 -0800

    crypto: x86/cast5-avx - fix ECB encryption when long sg follows short one
    
    commit 8f461b1e02ed546fbd0f11611138da67fd85a30f upstream.
    
    With ecb-cast5-avx, if a 128+ byte scatterlist element followed a
    shorter one, then the algorithm accidentally encrypted/decrypted only 8
    bytes instead of the expected 128 bytes.  Fix it by setting the
    encryption/decryption 'fn' correctly.
    
    Fixes: c12ab20b162c ("crypto: cast5/avx - avoid using temporary stack buffers")
    Cc: <stable@vger.kernel.org> # v3.8+
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 860783c283c85530a9ff02bb83b461cc2da1e806
Author: Leonard Crestez <leonard.crestez@nxp.com>
Date:   Tue Mar 13 22:17:23 2018 +0200

    crypto: arm,arm64 - Fix random regeneration of S_shipped
    
    commit 6aaf49b495b446ff6eec0ac983f781ca0dc56a73 upstream.
    
    The decision to rebuild .S_shipped is made based on the relative
    timestamps of .S_shipped and .pl files but git makes this essentially
    random. This means that the perl script might run anyway (usually at
    most once per checkout), defeating the whole purpose of _shipped.
    
    Fix by skipping the rule unless explicit make variables are provided:
    REGENERATE_ARM_CRYPTO or REGENERATE_ARM64_CRYPTO.
    
    This can produce nasty occasional build failures downstream, for example
    for toolchains with broken perl. The solution is minimally intrusive to
    make it easier to push into stable.
    
    Another report on a similar issue here: https://lkml.org/lkml/2018/3/8/1379
    
    Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
    Cc: <stable@vger.kernel.org>
    Reviewed-by: Masahiro Yamada <yamada.masahiro@socionext.com>
    Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 493601f76734e2478e774ce8e6df5c8768ddaced
Author: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
Date:   Sat Feb 24 17:03:21 2018 +0100

    crypto: ccp - return an actual key size from RSA max_size callback
    
    commit 0a9eb80e643064266868bd2fb2cd608e669309b0 upstream.
    
    rsa-pkcs1pad uses a value returned from a RSA implementation max_size
    callback as a size of an input buffer passed to the RSA implementation for
    encrypt and sign operations.
    
    CCP RSA implementation uses a hardware input buffer which size depends only
    on the current RSA key length, so it should return this key length in
    the max_size callback, too.
    This also matches what the kernel software RSA implementation does.
    
    Previously, the value returned from this callback was always the maximum
    RSA key size the CCP hardware supports.
    This resulted in this huge buffer being passed by rsa-pkcs1pad to CCP even
    for smaller key sizes and then in a buffer overflow when ccp_run_rsa_cmd()
    tried to copy this large input buffer into a RSA key length-sized hardware
    input buffer.
    
    Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
    Fixes: ceeec0afd684 ("crypto: ccp - Add support for RSA on the CCP")
    Cc: stable@vger.kernel.org
    Acked-by: Gary R Hook <gary.hook@amd.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7abca04ef3a0c0d3861a9ebc9739b52034a546ec
Author: Rui Miguel Silva <rui.silva@linaro.org>
Date:   Thu Feb 22 14:22:47 2018 +0000

    crypto: caam - Fix null dereference at error path
    
    commit b85149f6f5d5a9279f29a73b2e95342f4d465e73 upstream.
    
    caam_remove already removes the debugfs entry, so we need to remove the one
    immediately before calling caam_remove.
    
    This fix a NULL dereference at error paths is caam_probe fail.
    
    Fixes: 67c2315def06 ("crypto: caam - add Queue Interface (QI) backend support")
    
    Tested-by: Ryan Harkin <ryan.harkin@linaro.org>
    Cc: "Horia Geantă" <horia.geanta@nxp.com>
    Cc: Aymen Sghaier <aymen.sghaier@nxp.com>
    Cc: Fabio Estevam <fabio.estevam@nxp.com>
    Cc: Peng Fan <peng.fan@nxp.com>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: Lukas Auer <lukas.auer@aisec.fraunhofer.de>
    Cc: <stable@vger.kernel.org> # 4.12+
    Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
    Signed-off-by: Rui Miguel Silva <rui.silva@linaro.org>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 48b9d82caba884863f95ae603a967ef8467bac8f
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Mon Mar 26 08:53:25 2018 +0800

    crypto: ahash - Fix early termination in hash walk
    
    commit 900a081f6912a8985dc15380ec912752cb66025a upstream.
    
    When we have an unaligned SG list entry where there is no leftover
    aligned data, the hash walk code will incorrectly return zero as if
    the entire SG list has been processed.
    
    This patch fixes it by moving onto the next page instead.
    
    Reported-by: Eli Cooper <elicooper@gmx.com>
    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 4010d75d2eb4bdb011d213d469c52376e40ad034
Author: LEROY Christophe <christophe.leroy@c-s.fr>
Date:   Thu Mar 22 10:57:01 2018 +0100

    crypto: talitos - fix IPsec cipher in length
    
    commit 2b1227301a8e4729409694e323b72c064c47cb6b upstream.
    
    For SEC 2.x+, cipher in length must contain only the ciphertext length.
    In case of using hardware ICV checking, the ICV length is provided via
    the "extent" field of the descriptor pointer.
    
    Cc: <stable@vger.kernel.org> # 4.8+
    Fixes: 549bd8bc5987 ("crypto: talitos - Implement AEAD for SEC1 using HMAC_SNOOP_NO_AFEU")
    Reported-by: Horia Geantă <horia.geanta@nxp.com>
    Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
    Tested-by: Horia Geantă <horia.geanta@nxp.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 05c93fe33f949591123a690c39e1b26678685b45
Author: Conor McLoughlin <conor.mcloughlin@intel.com>
Date:   Tue Feb 13 08:29:56 2018 +0000

    crypto: testmgr - Fix incorrect values in PKCS#1 test vector
    
    commit 333e18c5cc74438f8940c7f3a8b3573748a371f9 upstream.
    
    The RSA private key for the first form should have
    version, prime1, prime2, exponent1, exponent2, coefficient
    values 0.
    With non-zero values for prime1,2, exponent 1,2 and coefficient
    the Intel QAT driver will assume that values are provided for the
    private key second form. This will result in signature verification
    failures for modules where QAT device is present and the modules
    are signed with rsa,sha256.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
    Signed-off-by: Conor McLoughlin <conor.mcloughlin@intel.com>
    Reviewed-by: Stephan Mueller <smueller@chronox.de>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c3c97a9f2f5201b55a0c0e315220a13399939bf9
Author: Gregory CLEMENT <gregory.clement@bootlin.com>
Date:   Tue Mar 13 17:48:40 2018 +0100

    crypto: inside-secure - fix clock management
    
    commit f962eb46e7a9b98a58d2483f5eb216e738fec732 upstream.
    
    In this driver the clock is got but never put when the driver is removed
    or if there is an error in the probe.
    
    Using the managed version of clk_get() allows to let the kernel take care
    of it.
    
    Fixes: 1b44c5a60c13 ("crypto: inside-secure - add SafeXcel EIP197 crypto
    engine driver")
    cc: stable@vger.kernel.org
    Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7bc247d1fd681c94b7dbdafddb4df9c16963e319
Author: LEROY Christophe <christophe.leroy@c-s.fr>
Date:   Mon Feb 26 17:40:04 2018 +0100

    crypto: talitos - don't persistently map req_ctx->hw_context and req_ctx->buf
    
    commit ad4cd51fb8375109edb377712b5f9c0c31ece33e upstream.
    
    Commit 49f9783b0cea ("crypto: talitos - do hw_context DMA mapping
    outside the requests") introduced a persistent dma mapping of
    req_ctx->hw_context
    Commit 37b5e8897eb5 ("crypto: talitos - chain in buffered data for ahash
    on SEC1") introduced a persistent dma mapping of req_ctx->buf
    
    As there is no destructor for req_ctx (the request context), the
    associated dma handlers where set in ctx (the tfm context). This is
    wrong as several hash operations can run with the same ctx.
    
    This patch removes this persistent mapping.
    
    Reported-by: Horia Geanta <horia.geanta@nxp.com>
    Cc: <stable@vger.kernel.org>
    Fixes: 49f9783b0cea ("crypto: talitos - do hw_context DMA mapping outside the requests")
    Fixes: 37b5e8897eb5 ("crypto: talitos - chain in buffered data for ahash on SEC1")
    Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
    Tested-by: Horia Geantă <horia.geanta@nxp.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 27036ade073244b20a8095ff7b6b0bc66da3932f
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Fri Mar 23 08:14:44 2018 +0800

    crypto: lrw - Free rctx->ext with kzfree
    
    commit 8c9bdab21289c211ca1ca6a5f9b7537b4a600a02 upstream.
    
    The buffer rctx->ext contains potentially sensitive data and should
    be freed with kzfree.
    
    Cc: <stable@vger.kernel.org>
    Fixes: 700cb3f5fe75 ("crypto: lrw - Convert to skcipher")
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5afddba2aaaee56bee9a81fad8705d03576ceaa9
Author: Alexander Gerasiov <gq@redlab-i.ru>
Date:   Sun Feb 4 02:50:22 2018 +0300

    parport_pc: Add support for WCH CH382L PCI-E single parallel port card.
    
    commit 823f7923833c6cc2b16e601546d607dcfb368004 upstream.
    
    WCH CH382L is a PCI-E adapter with 1 parallel port. It is similair to CH382
    but serial ports are not soldered on board. Detected as
    Serial controller: Device 1c00:3050 (rev 10) (prog-if 05 [16850])
    
    Signed-off-by: Alexander Gerasiov <gq@redlab-i.ru>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 39fd6d09439714516b75d4b7b07b677f8e7da48e
Author: Oliver Neukum <oneukum@suse.com>
Date:   Mon Jan 8 09:21:07 2018 -0500

    media: usbtv: prevent double free in error case
    
    commit 50e7044535537b2a54c7ab798cd34c7f6d900bd2 upstream.
    
    Quoting the original report:
    
    It looks like there is a double-free vulnerability in Linux usbtv driver
    on an error path of usbtv_probe function. When audio registration fails,
    usbtv_video_free function ends up freeing usbtv data structure, which
    gets freed the second time under usbtv_video_fail label.
    
    usbtv_audio_fail:
    
            usbtv_video_free(usbtv); =>
    
               v4l2_device_put(&usbtv->v4l2_dev);
    
                  => v4l2_device_put
    
                      => kref_put
    
                          => v4l2_device_release
    
      => usbtv_release (CALLBACK)
    
                                 => kfree(usbtv) (1st time)
    
    usbtv_video_fail:
    
            usb_set_intfdata(intf, NULL);
    
            usb_put_dev(usbtv->udev);
    
            kfree(usbtv); (2nd time)
    
    So, as we have refcounting, use it
    
    Reported-by: Yavuz, Tuba <tuba@ece.ufl.edu>
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    CC: stable@vger.kernel.org
    Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9b664c6a9f68e5e91fc5626d277c9fc97518c091
Author: Kees Cook <keescook@chromium.org>
Date:   Tue Mar 27 14:06:14 2018 -0700

    /dev/mem: Avoid overwriting "err" in read_mem()
    
    commit b5b38200ebe54879a7264cb6f33821f61c586a7e upstream.
    
    Successes in probe_kernel_read() would mask failures in copy_to_user()
    during read_mem().
    
    Reported-by: Brad Spengler <spender@grsecurity.net>
    Fixes: 22ec1a2aea73 ("/dev/mem: Add bounce buffer for copy-out")
    Cc: stable@vger.kernel.org
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3cde7e2ccec697b4b532438e3cbe997f93ed0bba
Author: Colin Ian King <colin.king@canonical.com>
Date:   Tue Feb 27 16:21:05 2018 +0000

    mei: remove dev_err message on an unsupported ioctl
    
    commit bb0829a741792b56c908d7745bc0b2b540293bcc upstream.
    
    Currently the driver spams the kernel log on unsupported ioctls which is
    unnecessary as the ioctl returns -ENOIOCTLCMD to indicate this anyway.
    I suspect this was originally for debugging purposes but it really is not
    required so remove it.
    
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 29361c2576314a9afbe104f6b312b874fa35980a
Author: Joel Stanley <joel@jms.id.au>
Date:   Mon Mar 5 22:17:38 2018 +1030

    serial: 8250: Add Nuvoton NPCM UART
    
    commit f597fbce38d230af95384f4a04e0a13a1d0ad45d upstream.
    
    The Nuvoton UART is almost compatible with the 8250 driver when probed
    via the 8250_of driver, however it requires some extra configuration
    at startup.
    
    Reviewed-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Joel Stanley <joel@jms.id.au>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ffed9ae46844e63209207c35d045fd3132b1acf1
Author: Johan Hovold <johan@kernel.org>
Date:   Tue Mar 6 09:32:43 2018 +0100

    USB: serial: cp210x: add ELDAT Easywave RX09 id
    
    commit 1f1e82f74c0947e40144688c9e36abe4b3999f49 upstream.
    
    Add device id for ELDAT Easywave RX09 tranceiver.
    
    Reported-by: Jan Jansen <nattelip@hotmail.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b8541b3dc59c6887ae56c103e5f0a18b88617758
Author: Clemens Werther <clemens.werther@gmail.com>
Date:   Fri Mar 16 10:20:46 2018 +0100

    USB: serial: ftdi_sio: add support for Harman FirmwareHubEmulator
    
    commit 6555ad13a01952c16485c82a52ad1f3e07e34b3a upstream.
    
    Add device id for Harman FirmwareHubEmulator to make the device
    auto-detectable by the driver.
    
    Signed-off-by: Clemens Werther <clemens.werther@gmail.com>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6693f178c9ab12245644f1d3edfa826157d32a1f
Author: Major Hayden <major@mhtx.net>
Date:   Fri Feb 23 14:29:54 2018 -0600

    USB: serial: ftdi_sio: add RT Systems VX-8 cable
    
    commit 9608e5c0f079390473b484ef92334dfd3431bb89 upstream.
    
    This patch adds a device ID for the RT Systems cable used to
    program Yaesu VX-8R/VX-8DR handheld radios. It uses the main
    FTDI VID instead of the common RT Systems VID.
    
    Signed-off-by: Major Hayden <major@mhtx.net>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b5abde6ca2d290030dc471bd255d9e7dae8e7b05
Author: Omar Sandoval <osandov@fb.com>
Date:   Mon Apr 2 15:58:31 2018 -0700

    bitmap: fix memset optimization on big-endian systems
    
    commit 21035965f60b0502fc6537b232839389bb4ce664 upstream.
    
    Commit 2a98dc028f91 ("include/linux/bitmap.h: turn bitmap_set and
    bitmap_clear into memset when possible") introduced an optimization to
    bitmap_{set,clear}() which uses memset() when the start and length are
    constants aligned to a byte.
    
    This is wrong on big-endian systems; our bitmaps are arrays of unsigned
    long, so bit n is not at byte n / 8 in memory.  This was caught by the
    Btrfs selftests, but the bitmap selftests also fail when run on a
    big-endian machine.
    
    We can still use memset if the start and length are aligned to an
    unsigned long, so do that on big-endian.  The same problem applies to
    the memcmp in bitmap_equal(), so fix it there, too.
    
    Fixes: 2a98dc028f91 ("include/linux/bitmap.h: turn bitmap_set and bitmap_clear into memset when possible")
    Fixes: 2c6deb01525a ("bitmap: use memcmp optimisation in more situations")
    Cc: stable@kernel.org
    Reported-by: "Erhard F." <erhard_f@mailbox.org>
    Cc: Matthew Wilcox <mawilcox@microsoft.com>
    Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Omar Sandoval <osandov@fb.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7b2dcf7cc45609dbfc2dde7d501d2694093928a9
Author: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Date:   Tue Mar 13 22:48:25 2018 -0700

    drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.
    
    commit b1e314462bba76660eec62760bb2e87f28f58866 upstream.
    
    If bios sets up an MST output and hardware state readout code sees this is
    an SST configuration, when disabling the encoder we end up calling
    ->post_disable_dp() hook instead of the MST version. Consequently, we write
    to the DP_SET_POWER dpcd to set it D3 state. Further along when we try
    enable the encoder in MST mode, POWER_UP_PHY transaction fails to power up
    the MST hub. This results in continuous link training failures which keep
    the system busy delaying boot. We could identify bios MST boot discrepancy
    and handle it accordingly but a simple way to solve this is to write to the
    DP_SET_POWER dpcd for MST too.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105470
    Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Cc: Jani Nikula <jani.nikula@intel.com>
    Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Reported-by: Laura Abbott <labbott@redhat.com>
    Cc: stable@vger.kernel.org
    Fixes: 5ea2355a100a ("drm/i915/mst: Use MST sideband message transactions for dpms control")
    Tested-by: Laura Abbott <labbott@redhat.com>
    Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20180314054825.1718-1-dhinakaran.pandiyan@intel.com
    (cherry picked from commit ad260ab32a4d94fa974f58262f8000472d34fd5b)
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 886125faf5d13c40923192d8c98eeca50cb835fa
Author: Szymon Janc <szymon.janc@codecoup.pl>
Date:   Mon Feb 26 15:41:53 2018 +0100

    Bluetooth: Fix missing encryption refresh on Security Request
    
    commit 64e759f58f128730b97a3c3a26d283c075ad7c86 upstream.
    
    If Security Request is received on connection that is already encrypted
    with sufficient security master should perform encryption key refresh
    procedure instead of just ignoring Slave Security Request
    (Core Spec 5.0 Vol 3 Part H 2.4.6).
    
    > ACL Data RX: Handle 3585 flags 0x02 dlen 6
          SMP: Security Request (0x0b) len 1
            Authentication requirement: Bonding, No MITM, SC, No Keypresses (0x09)
    < HCI Command: LE Start Encryption (0x08|0x0019) plen 28
            Handle: 3585
            Random number: 0x0000000000000000
            Encrypted diversifier: 0x0000
            Long term key: 44264272a5c426a9e868f034cf0e69f3
    > HCI Event: Command Status (0x0f) plen 4
          LE Start Encryption (0x08|0x0019) ncmd 1
            Status: Success (0x00)
    > HCI Event: Encryption Key Refresh Complete (0x30) plen 3
            Status: Success (0x00)
            Handle: 3585
    
    Signed-off-by: Szymon Janc <szymon.janc@codecoup.pl>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8f723a276a4d68128e2d0adc79001f0f193b6c5b
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Jan 10 17:35:43 2018 +0100

    phy: qcom-ufs: add MODULE_LICENSE tag
    
    commit 59fba0869acae06ff594dd7e9808ed673f53538a upstream.
    
    While the specific UFS PHY drivers (14nm and 20nm) have a module
    license, the common base module does not, leading to a Kbuild
    failure:
    
    WARNING: modpost: missing MODULE_LICENSE() in drivers/phy/qualcomm/phy-qcom-ufs.o
    FATAL: modpost: GPL-incompatible module phy-qcom-ufs.ko uses GPL-only symbol 'clk_enable'
    
    This adds a module description and license tag to fix the build.
    I added both Yaniv and Vivek as authors here, as Yaniv sent the initial
    submission, while Vivek did most of the work since.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a192706b71fa7ee126524da139f84ec982ff2d09
Author: Florian Westphal <fw@strlen.de>
Date:   Sat Mar 10 01:15:45 2018 +0100

    netfilter: x_tables: add and use xt_check_proc_name
    
    commit b1d0a5d0cba4597c0394997b2d5fced3e3841b4e upstream.
    
    recent and hashlimit both create /proc files, but only check that
    name is 0 terminated.
    
    This can trigger WARN() from procfs when name is "" or "/".
    Add helper for this and then use it for both.
    
    Cc: Eric Dumazet <eric.dumazet@gmail.com>
    Reported-by: Eric Dumazet <eric.dumazet@gmail.com>
    Reported-by: <syzbot+0502b00edac2a0680b61@syzkaller.appspotmail.com>
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7ab7e3e2a0d493a196a0a79aa6d6033c85245c38
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Thu Mar 22 11:08:50 2018 +0100

    netfilter: drop template ct when conntrack is skipped.
    
    commit aebfa52a925d701114afd6af0def35bab16d4f47 upstream.
    
    The ipv4 nf_ct code currently skips the nf_conntrak_in() call
    for fragmented packets. As a results later matches/target can end
    up manipulating template ct entry instead of 'real' ones.
    
    Exploiting the above, syzbot found a way to trigger the following
    splat:
    
    WARNING: CPU: 1 PID: 4242 at net/netfilter/xt_cluster.c:55
    xt_cluster_mt+0x6c1/0x840 net/netfilter/xt_cluster.c:127
    Kernel panic - not syncing: panic_on_warn set ...
    
    CPU: 1 PID: 4242 Comm: syzkaller027971 Not tainted 4.16.0-rc2+ #243
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
    Google 01/01/2011
    Call Trace:
      __dump_stack lib/dump_stack.c:17 [inline]
      dump_stack+0x194/0x24d lib/dump_stack.c:53
      panic+0x1e4/0x41c kernel/panic.c:183
      __warn+0x1dc/0x200 kernel/panic.c:547
      report_bug+0x211/0x2d0 lib/bug.c:184
      fixup_bug.part.11+0x37/0x80 arch/x86/kernel/traps.c:178
      fixup_bug arch/x86/kernel/traps.c:247 [inline]
      do_error_trap+0x2d7/0x3e0 arch/x86/kernel/traps.c:296
      do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
      invalid_op+0x58/0x80 arch/x86/entry/entry_64.S:957
    RIP: 0010:xt_cluster_hash net/netfilter/xt_cluster.c:55 [inline]
    RIP: 0010:xt_cluster_mt+0x6c1/0x840 net/netfilter/xt_cluster.c:127
    RSP: 0018:ffff8801d2f6f2d0 EFLAGS: 00010293
    RAX: ffff8801af700540 RBX: 0000000000000000 RCX: ffffffff84a2d1e1
    RDX: 0000000000000000 RSI: ffff8801d2f6f478 RDI: ffff8801cafd336a
    RBP: ffff8801d2f6f2e8 R08: 0000000000000000 R09: 0000000000000001
    R10: 0000000000000000 R11: 0000000000000000 R12: ffff8801b03b3d18
    R13: ffff8801cafd3300 R14: dffffc0000000000 R15: ffff8801d2f6f478
      ipt_do_table+0xa91/0x19b0 net/ipv4/netfilter/ip_tables.c:296
      iptable_filter_hook+0x65/0x80 net/ipv4/netfilter/iptable_filter.c:41
      nf_hook_entry_hookfn include/linux/netfilter.h:120 [inline]
      nf_hook_slow+0xba/0x1a0 net/netfilter/core.c:483
      nf_hook include/linux/netfilter.h:243 [inline]
      NF_HOOK include/linux/netfilter.h:286 [inline]
      raw_send_hdrinc.isra.17+0xf39/0x1880 net/ipv4/raw.c:432
      raw_sendmsg+0x14cd/0x26b0 net/ipv4/raw.c:669
      inet_sendmsg+0x11f/0x5e0 net/ipv4/af_inet.c:763
      sock_sendmsg_nosec net/socket.c:629 [inline]
      sock_sendmsg+0xca/0x110 net/socket.c:639
      SYSC_sendto+0x361/0x5c0 net/socket.c:1748
      SyS_sendto+0x40/0x50 net/socket.c:1716
      do_syscall_64+0x280/0x940 arch/x86/entry/common.c:287
      entry_SYSCALL_64_after_hwframe+0x42/0xb7
    RIP: 0033:0x441b49
    RSP: 002b:00007ffff5ca8b18 EFLAGS: 00000216 ORIG_RAX: 000000000000002c
    RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 0000000000441b49
    RDX: 0000000000000030 RSI: 0000000020ff7000 RDI: 0000000000000003
    RBP: 00000000006cc018 R08: 000000002066354c R09: 0000000000000010
    R10: 0000000000000000 R11: 0000000000000216 R12: 0000000000403470
    R13: 0000000000403500 R14: 0000000000000000 R15: 0000000000000000
    Dumping ftrace buffer:
        (ftrace buffer empty)
    Kernel Offset: disabled
    Rebooting in 86400 seconds..
    
    Instead of adding checks for template ct on every target/match
    manipulating skb->_nfct, simply drop the template ct when skipping
    nf_conntrack_in().
    
    Fixes: 7b4fdf77a450ec ("netfilter: don't track fragmented packets")
    Reported-and-tested-by: syzbot+0346441ae0545cfcea3a@syzkaller.appspotmail.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Acked-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c16c62bb4d9f98ca9d592148df147a7f9831b98c
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Mon Mar 12 14:54:24 2018 +0100

    l2tp: fix races with ipv4-mapped ipv6 addresses
    
    commit b954f94023dcc61388c8384f0f14eb8e42c863c5 upstream.
    
    The l2tp_tunnel_create() function checks for v4mapped ipv6
    sockets and cache that flag, so that l2tp core code can
    reusing it at xmit time.
    
    If the socket is provided by the userspace, the connection
    status of the tunnel sockets can change between the tunnel
    creation and the xmit call, so that syzbot is able to
    trigger the following splat:
    
    BUG: KASAN: use-after-free in ip6_dst_idev include/net/ip6_fib.h:192
    [inline]
    BUG: KASAN: use-after-free in ip6_xmit+0x1f76/0x2260
    net/ipv6/ip6_output.c:264
    Read of size 8 at addr ffff8801bd949318 by task syz-executor4/23448
    
    CPU: 0 PID: 23448 Comm: syz-executor4 Not tainted 4.16.0-rc4+ #65
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
    Google 01/01/2011
    Call Trace:
      __dump_stack lib/dump_stack.c:17 [inline]
      dump_stack+0x194/0x24d lib/dump_stack.c:53
      print_address_description+0x73/0x250 mm/kasan/report.c:256
      kasan_report_error mm/kasan/report.c:354 [inline]
      kasan_report+0x23c/0x360 mm/kasan/report.c:412
      __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
      ip6_dst_idev include/net/ip6_fib.h:192 [inline]
      ip6_xmit+0x1f76/0x2260 net/ipv6/ip6_output.c:264
      inet6_csk_xmit+0x2fc/0x580 net/ipv6/inet6_connection_sock.c:139
      l2tp_xmit_core net/l2tp/l2tp_core.c:1053 [inline]
      l2tp_xmit_skb+0x105f/0x1410 net/l2tp/l2tp_core.c:1148
      pppol2tp_sendmsg+0x470/0x670 net/l2tp/l2tp_ppp.c:341
      sock_sendmsg_nosec net/socket.c:630 [inline]
      sock_sendmsg+0xca/0x110 net/socket.c:640
      ___sys_sendmsg+0x767/0x8b0 net/socket.c:2046
      __sys_sendmsg+0xe5/0x210 net/socket.c:2080
      SYSC_sendmsg net/socket.c:2091 [inline]
      SyS_sendmsg+0x2d/0x50 net/socket.c:2087
      do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
      entry_SYSCALL_64_after_hwframe+0x42/0xb7
    RIP: 0033:0x453e69
    RSP: 002b:00007f819593cc68 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
    RAX: ffffffffffffffda RBX: 00007f819593d6d4 RCX: 0000000000453e69
    RDX: 0000000000000081 RSI: 000000002037ffc8 RDI: 0000000000000004
    RBP: 000000000072bea0 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
    R13: 00000000000004c3 R14: 00000000006f72e8 R15: 0000000000000000
    
    This change addresses the issues:
    * explicitly checking for TCP_ESTABLISHED for user space provided sockets
    * dropping the v4mapped flag usage - it can become outdated - and
      explicitly invoking ipv6_addr_v4mapped() instead
    
    The issue is apparently there since ancient times.
    
    v1 -> v2: (many thanks to Guillaume)
     - with csum issue introduced in v1
     - replace pr_err with pr_debug
     - fix build issue with IPV6 disabled
     - move l2tp_sk_is_v4mapped in l2tp_core.c
    
    v2 -> v3:
     - don't update inet_daddr for v4mapped address, unneeded
     - drop rendundant check at creation time
    
    Reported-and-tested-by: syzbot+92fa328176eb07e4ac1a@syzkaller.appspotmail.com
    Fixes: 3557baabf280 ("[L2TP]: PPP over L2TP driver core")
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dd19573992b595e49fbcbc70c230fcea9eac1300
Author: Florian Westphal <fw@strlen.de>
Date:   Fri Mar 9 14:27:31 2018 +0100

    netfilter: bridge: ebt_among: add more missing match size checks
    
    commit c8d70a700a5b486bfa8e5a7d33d805389f6e59f9 upstream.
    
    ebt_among is special, it has a dynamic match size and is exempt
    from the central size checks.
    
    commit c4585a2823edf ("bridge: ebt_among: add missing match size checks")
    added validation for pool size, but missed fact that the macros
    ebt_among_wh_src/dst can already return out-of-bound result because
    they do not check value of wh_src/dst_ofs (an offset) vs. the size
    of the match that userspace gave to us.
    
    v2:
    check that offset has correct alignment.
    Paolo Abeni points out that we should also check that src/dst
    wormhash arrays do not overlap, and src + length lines up with
    start of dst (or vice versa).
    v3: compact wormhash_sizes_valid() part
    
    NB: Fixes tag is intentionally wrong, this bug exists from day
    one when match was added for 2.6 kernel. Tag is there so stable
    maintainers will notice this one too.
    
    Tested with same rules from the earlier patch.
    
    Fixes: c4585a2823edf ("bridge: ebt_among: add missing match size checks")
    Reported-by: <syzbot+bdabab6f1983a03fc009@syzkaller.appspotmail.com>
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8f4ed22f6b5e9d699c05418e8efafe7c695605fd
Author: Michal Hocko <mhocko@kernel.org>
Date:   Tue Jan 30 11:30:11 2018 -0800

    netfilter: x_tables: make allocation less aggressive
    
    commit 0537250fdc6c876ed4cbbe874c739aebef493ee2 upstream.
    
    syzbot has noticed that xt_alloc_table_info can allocate a lot of memory.
    This is an admin only interface but an admin in a namespace is sufficient
    as well.  eacd86ca3b03 ("net/netfilter/x_tables.c: use kvmalloc() in
    xt_alloc_table_info()") has changed the opencoded kmalloc->vmalloc
    fallback into kvmalloc.  It has dropped __GFP_NORETRY on the way because
    vmalloc has simply never fully supported __GFP_NORETRY semantic.  This is
    still the case because e.g.  page tables backing the vmalloc area are
    hardcoded GFP_KERNEL.
    
    Revert back to __GFP_NORETRY as a poors man defence against excessively
    large allocation request here.  We will not rule out the OOM killer
    completely but __GFP_NORETRY should at least stop the large request in
    most cases.
    
    [akpm@linux-foundation.org: coding-style fixes]
    Fixes: eacd86ca3b03 ("net/netfilter/x_tables.c: use kvmalloc() in xt_alloc_tableLink: http://lkml.kernel.org/r/20180130140104.GE21609@dhcp22.suse.cz
    Signed-off-by: Michal Hocko <mhocko@suse.com>
    Acked-by: Florian Westphal <fw@strlen.de>
    Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
    Cc: David S. Miller <davem@davemloft.net>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5bb3f4acc8aa6c479f041c3449a03d38c349273a
Author: Dennis Zhou <dennisszhou@gmail.com>
Date:   Fri Feb 16 12:07:19 2018 -0600

    percpu: add __GFP_NORETRY semantics to the percpu balancing path
    
    commit 47504ee04b9241548ae2c28be7d0b01cff3b7aa6 upstream.
    
    Percpu memory using the vmalloc area based chunk allocator lazily
    populates chunks by first requesting the full virtual address space
    required for the chunk and subsequently adding pages as allocations come
    through. To ensure atomic allocations can succeed, a workqueue item is
    used to maintain a minimum number of empty pages. In certain scenarios,
    such as reported in [1], it is possible that physical memory becomes
    quite scarce which can result in either a rather long time spent trying
    to find free pages or worse, a kernel panic.
    
    This patch adds support for __GFP_NORETRY and __GFP_NOWARN passing them
    through to the underlying allocators. This should prevent any
    unnecessary panics potentially caused by the workqueue item. The passing
    of gfp around is as additional flags rather than a full set of flags.
    The next patch will change these to caller passed semantics.
    
    V2:
    Added const modifier to gfp flags in the balance path.
    Removed an extra whitespace.
    
    [1] https://lkml.org/lkml/2018/2/12/551
    
    Signed-off-by: Dennis Zhou <dennisszhou@gmail.com>
    Suggested-by: Daniel Borkmann <daniel@iogearbox.net>
    Reported-by: syzbot+adb03f3f0bb57ce3acda@syzkaller.appspotmail.com
    Acked-by: Christoph Lameter <cl@linux.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c7f2bd1850a8a6e37f4cd16713af33d1ca3e368c
Author: Steffen Klassert <steffen.klassert@secunet.com>
Date:   Thu Feb 1 08:49:23 2018 +0100

    xfrm: Refuse to insert 32 bit userspace socket policies on 64 bit systems
    
    commit 19d7df69fdb2636856dc8919de72fc1bf8f79598 upstream.
    
    We don't have a compat layer for xfrm, so userspace and kernel
    structures have different sizes in this case. This results in
    a broken configuration, so refuse to configure socket policies
    when trying to insert from 32 bit userspace as we do it already
    with policies inserted via netlink.
    
    Reported-and-tested-by: syzbot+e1a1577ca8bcb47b769a@syzkaller.appspotmail.com
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 94f84ba56f3d1a057fd1531ff3b75b7804fcdb4f
Author: Greg Hackmann <ghackmann@google.com>
Date:   Wed Mar 7 14:42:53 2018 -0800

    net: xfrm: use preempt-safe this_cpu_read() in ipcomp_alloc_tfms()
    
    commit 0dcd7876029b58770f769cbb7b484e88e4a305e5 upstream.
    
    f7c83bcbfaf5 ("net: xfrm: use __this_cpu_read per-cpu helper") added a
    __this_cpu_read() call inside ipcomp_alloc_tfms().
    
    At the time, __this_cpu_read() required the caller to either not care
    about races or to handle preemption/interrupt issues.  3.15 tightened
    the rules around some per-cpu operations, and now __this_cpu_read()
    should never be used in a preemptible context.  On 3.15 and later, we
    need to use this_cpu_read() instead.
    
    syzkaller reported this leading to the following kernel BUG while
    fuzzing sendmsg:
    
    BUG: using __this_cpu_read() in preemptible [00000000] code: repro/3101
    caller is ipcomp_init_state+0x185/0x990
    CPU: 3 PID: 3101 Comm: repro Not tainted 4.16.0-rc4-00123-g86f84779d8e9 #154
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
    Call Trace:
     dump_stack+0xb9/0x115
     check_preemption_disabled+0x1cb/0x1f0
     ipcomp_init_state+0x185/0x990
     ? __xfrm_init_state+0x876/0xc20
     ? lock_downgrade+0x5e0/0x5e0
     ipcomp4_init_state+0xaa/0x7c0
     __xfrm_init_state+0x3eb/0xc20
     xfrm_init_state+0x19/0x60
     pfkey_add+0x20df/0x36f0
     ? pfkey_broadcast+0x3dd/0x600
     ? pfkey_sock_destruct+0x340/0x340
     ? pfkey_seq_stop+0x80/0x80
     ? __skb_clone+0x236/0x750
     ? kmem_cache_alloc+0x1f6/0x260
     ? pfkey_sock_destruct+0x340/0x340
     ? pfkey_process+0x62a/0x6f0
     pfkey_process+0x62a/0x6f0
     ? pfkey_send_new_mapping+0x11c0/0x11c0
     ? mutex_lock_io_nested+0x1390/0x1390
     pfkey_sendmsg+0x383/0x750
     ? dump_sp+0x430/0x430
     sock_sendmsg+0xc0/0x100
     ___sys_sendmsg+0x6c8/0x8b0
     ? copy_msghdr_from_user+0x3b0/0x3b0
     ? pagevec_lru_move_fn+0x144/0x1f0
     ? find_held_lock+0x32/0x1c0
     ? do_huge_pmd_anonymous_page+0xc43/0x11e0
     ? lock_downgrade+0x5e0/0x5e0
     ? get_kernel_page+0xb0/0xb0
     ? _raw_spin_unlock+0x29/0x40
     ? do_huge_pmd_anonymous_page+0x400/0x11e0
     ? __handle_mm_fault+0x553/0x2460
     ? __fget_light+0x163/0x1f0
     ? __sys_sendmsg+0xc7/0x170
     __sys_sendmsg+0xc7/0x170
     ? SyS_shutdown+0x1a0/0x1a0
     ? __do_page_fault+0x5a0/0xca0
     ? lock_downgrade+0x5e0/0x5e0
     SyS_sendmsg+0x27/0x40
     ? __sys_sendmsg+0x170/0x170
     do_syscall_64+0x19f/0x640
     entry_SYSCALL_64_after_hwframe+0x42/0xb7
    RIP: 0033:0x7f0ee73dfb79
    RSP: 002b:00007ffe14fc15a8 EFLAGS: 00000207 ORIG_RAX: 000000000000002e
    RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0ee73dfb79
    RDX: 0000000000000000 RSI: 00000000208befc8 RDI: 0000000000000004
    RBP: 00007ffe14fc15b0 R08: 00007ffe14fc15c0 R09: 00007ffe14fc15c0
    R10: 0000000000000000 R11: 0000000000000207 R12: 0000000000400440
    R13: 00007ffe14fc16b0 R14: 0000000000000000 R15: 0000000000000000
    
    Signed-off-by: Greg Hackmann <ghackmann@google.com>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e13d781171fb7d2a4b424af4d81fec49f203e551
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Mar 23 07:56:58 2018 -0700

    ipv6: fix possible deadlock in rt6_age_examine_exception()
    
    commit 1bfa26ff8c4b7512f4e4efa6df211239223033d4 upstream.
    
    syzbot reported a LOCKDEP splat [1] in rt6_age_examine_exception()
    
    rt6_age_examine_exception() is called while rt6_exception_lock is held.
    This lock is the lower one in the lock hierarchy, thus we can not
    call dst_neigh_lookup() function, as it can fallback to neigh_create()
    
    We should instead do a pure RCU lookup. As a bonus we avoid
    a pair of atomic operations on neigh refcount.
    
    [1]
    
    WARNING: possible circular locking dependency detected
    4.16.0-rc4+ #277 Not tainted
    
    syz-executor7/4015 is trying to acquire lock:
     (&ndev->lock){++--}, at: [<00000000416dce19>] __ipv6_dev_mc_dec+0x45/0x350 net/ipv6/mcast.c:928
    
    but task is already holding lock:
     (&tbl->lock){++-.}, at: [<00000000b5cb1d65>] neigh_ifdown+0x3d/0x250 net/core/neighbour.c:292
    
    which lock already depends on the new lock.
    
    the existing dependency chain (in reverse order) is:
    
    -> #3 (&tbl->lock){++-.}:
           __raw_write_lock_bh include/linux/rwlock_api_smp.h:203 [inline]
           _raw_write_lock_bh+0x31/0x40 kernel/locking/spinlock.c:312
           __neigh_create+0x87e/0x1d90 net/core/neighbour.c:528
           neigh_create include/net/neighbour.h:315 [inline]
           ip6_neigh_lookup+0x9a7/0xba0 net/ipv6/route.c:228
           dst_neigh_lookup include/net/dst.h:405 [inline]
           rt6_age_examine_exception net/ipv6/route.c:1609 [inline]
           rt6_age_exceptions+0x381/0x660 net/ipv6/route.c:1645
           fib6_age+0xfb/0x140 net/ipv6/ip6_fib.c:2033
           fib6_clean_node+0x389/0x580 net/ipv6/ip6_fib.c:1919
           fib6_walk_continue+0x46c/0x8a0 net/ipv6/ip6_fib.c:1845
           fib6_walk+0x91/0xf0 net/ipv6/ip6_fib.c:1893
           fib6_clean_tree+0x1e6/0x340 net/ipv6/ip6_fib.c:1970
           __fib6_clean_all+0x1f4/0x3a0 net/ipv6/ip6_fib.c:1986
           fib6_clean_all net/ipv6/ip6_fib.c:1997 [inline]
           fib6_run_gc+0x16b/0x3c0 net/ipv6/ip6_fib.c:2053
           ndisc_netdev_event+0x3c2/0x4a0 net/ipv6/ndisc.c:1781
           notifier_call_chain+0x136/0x2c0 kernel/notifier.c:93
           __raw_notifier_call_chain kernel/notifier.c:394 [inline]
           raw_notifier_call_chain+0x2d/0x40 kernel/notifier.c:401
           call_netdevice_notifiers_info+0x32/0x70 net/core/dev.c:1707
           call_netdevice_notifiers net/core/dev.c:1725 [inline]
           __dev_notify_flags+0x262/0x430 net/core/dev.c:6960
           dev_change_flags+0xf5/0x140 net/core/dev.c:6994
           devinet_ioctl+0x126a/0x1ac0 net/ipv4/devinet.c:1080
           inet_ioctl+0x184/0x310 net/ipv4/af_inet.c:919
           sock_do_ioctl+0xef/0x390 net/socket.c:957
           sock_ioctl+0x36b/0x610 net/socket.c:1081
           vfs_ioctl fs/ioctl.c:46 [inline]
           do_vfs_ioctl+0x1b1/0x1520 fs/ioctl.c:686
           SYSC_ioctl fs/ioctl.c:701 [inline]
           SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
           do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
           entry_SYSCALL_64_after_hwframe+0x42/0xb7
    
    -> #2 (rt6_exception_lock){+.-.}:
           __raw_spin_lock_bh include/linux/spinlock_api_smp.h:135 [inline]
           _raw_spin_lock_bh+0x31/0x40 kernel/locking/spinlock.c:168
           spin_lock_bh include/linux/spinlock.h:315 [inline]
           rt6_flush_exceptions+0x21/0x210 net/ipv6/route.c:1367
           fib6_del_route net/ipv6/ip6_fib.c:1677 [inline]
           fib6_del+0x624/0x12c0 net/ipv6/ip6_fib.c:1761
           __ip6_del_rt+0xc7/0x120 net/ipv6/route.c:2980
           ip6_del_rt+0x132/0x1a0 net/ipv6/route.c:2993
           __ipv6_dev_ac_dec+0x3b1/0x600 net/ipv6/anycast.c:332
           ipv6_dev_ac_dec net/ipv6/anycast.c:345 [inline]
           ipv6_sock_ac_close+0x2b4/0x3e0 net/ipv6/anycast.c:200
           inet6_release+0x48/0x70 net/ipv6/af_inet6.c:433
           sock_release+0x8d/0x1e0 net/socket.c:594
           sock_close+0x16/0x20 net/socket.c:1149
           __fput+0x327/0x7e0 fs/file_table.c:209
           ____fput+0x15/0x20 fs/file_table.c:243
           task_work_run+0x199/0x270 kernel/task_work.c:113
           exit_task_work include/linux/task_work.h:22 [inline]
           do_exit+0x9bb/0x1ad0 kernel/exit.c:865
           do_group_exit+0x149/0x400 kernel/exit.c:968
           get_signal+0x73a/0x16d0 kernel/signal.c:2469
           do_signal+0x90/0x1e90 arch/x86/kernel/signal.c:809
           exit_to_usermode_loop+0x258/0x2f0 arch/x86/entry/common.c:162
           prepare_exit_to_usermode arch/x86/entry/common.c:196 [inline]
           syscall_return_slowpath arch/x86/entry/common.c:265 [inline]
           do_syscall_64+0x6ec/0x940 arch/x86/entry/common.c:292
           entry_SYSCALL_64_after_hwframe+0x42/0xb7
    
    -> #1 (&(&tb->tb6_lock)->rlock){+.-.}:
           __raw_spin_lock_bh include/linux/spinlock_api_smp.h:135 [inline]
           _raw_spin_lock_bh+0x31/0x40 kernel/locking/spinlock.c:168
           spin_lock_bh include/linux/spinlock.h:315 [inline]
           __ip6_ins_rt+0x56/0x90 net/ipv6/route.c:1007
           ip6_route_add+0x141/0x190 net/ipv6/route.c:2955
           addrconf_prefix_route+0x44f/0x620 net/ipv6/addrconf.c:2359
           fixup_permanent_addr net/ipv6/addrconf.c:3368 [inline]
           addrconf_permanent_addr net/ipv6/addrconf.c:3391 [inline]
           addrconf_notify+0x1ad2/0x2310 net/ipv6/addrconf.c:3460
           notifier_call_chain+0x136/0x2c0 kernel/notifier.c:93
           __raw_notifier_call_chain kernel/notifier.c:394 [inline]
           raw_notifier_call_chain+0x2d/0x40 kernel/notifier.c:401
           call_netdevice_notifiers_info+0x32/0x70 net/core/dev.c:1707
           call_netdevice_notifiers net/core/dev.c:1725 [inline]
           __dev_notify_flags+0x15d/0x430 net/core/dev.c:6958
           dev_change_flags+0xf5/0x140 net/core/dev.c:6994
           do_setlink+0xa22/0x3bb0 net/core/rtnetlink.c:2357
           rtnl_newlink+0xf37/0x1a50 net/core/rtnetlink.c:2965
           rtnetlink_rcv_msg+0x57f/0xb10 net/core/rtnetlink.c:4641
           netlink_rcv_skb+0x14b/0x380 net/netlink/af_netlink.c:2444
           rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:4659
           netlink_unicast_kernel net/netlink/af_netlink.c:1308 [inline]
           netlink_unicast+0x4c4/0x6b0 net/netlink/af_netlink.c:1334
           netlink_sendmsg+0xa4a/0xe60 net/netlink/af_netlink.c:1897
           sock_sendmsg_nosec net/socket.c:629 [inline]
           sock_sendmsg+0xca/0x110 net/socket.c:639
           ___sys_sendmsg+0x767/0x8b0 net/socket.c:2047
           __sys_sendmsg+0xe5/0x210 net/socket.c:2081
           SYSC_sendmsg net/socket.c:2092 [inline]
           SyS_sendmsg+0x2d/0x50 net/socket.c:2088
           do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
           entry_SYSCALL_64_after_hwframe+0x42/0xb7
    
    -> #0 (&ndev->lock){++--}:
           lock_acquire+0x1d5/0x580 kernel/locking/lockdep.c:3920
           __raw_write_lock_bh include/linux/rwlock_api_smp.h:203 [inline]
           _raw_write_lock_bh+0x31/0x40 kernel/locking/spinlock.c:312
           __ipv6_dev_mc_dec+0x45/0x350 net/ipv6/mcast.c:928
           ipv6_dev_mc_dec+0x110/0x1f0 net/ipv6/mcast.c:961
           pndisc_destructor+0x21a/0x340 net/ipv6/ndisc.c:392
           pneigh_ifdown net/core/neighbour.c:695 [inline]
           neigh_ifdown+0x149/0x250 net/core/neighbour.c:294
           rt6_disable_ip+0x537/0x700 net/ipv6/route.c:3874
           addrconf_ifdown+0x14b/0x14f0 net/ipv6/addrconf.c:3633
           addrconf_notify+0x5f8/0x2310 net/ipv6/addrconf.c:3557
           notifier_call_chain+0x136/0x2c0 kernel/notifier.c:93
           __raw_notifier_call_chain kernel/notifier.c:394 [inline]
           raw_notifier_call_chain+0x2d/0x40 kernel/notifier.c:401
           call_netdevice_notifiers_info+0x32/0x70 net/core/dev.c:1707
           call_netdevice_notifiers net/core/dev.c:1725 [inline]
           __dev_notify_flags+0x262/0x430 net/core/dev.c:6960
           dev_change_flags+0xf5/0x140 net/core/dev.c:6994
           devinet_ioctl+0x126a/0x1ac0 net/ipv4/devinet.c:1080
           inet_ioctl+0x184/0x310 net/ipv4/af_inet.c:919
           packet_ioctl+0x1ff/0x310 net/packet/af_packet.c:4066
           sock_do_ioctl+0xef/0x390 net/socket.c:957
           sock_ioctl+0x36b/0x610 net/socket.c:1081
           vfs_ioctl fs/ioctl.c:46 [inline]
           do_vfs_ioctl+0x1b1/0x1520 fs/ioctl.c:686
           SYSC_ioctl fs/ioctl.c:701 [inline]
           SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
           do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
           entry_SYSCALL_64_after_hwframe+0x42/0xb7
    
    other info that might help us debug this:
    
    Chain exists of:
      &ndev->lock --> rt6_exception_lock --> &tbl->lock
    
     Possible unsafe locking scenario:
    
           CPU0                    CPU1
           ----                    ----
      lock(&tbl->lock);
                                   lock(rt6_exception_lock);
                                   lock(&tbl->lock);
      lock(&ndev->lock);
    
     *** DEADLOCK ***
    
    2 locks held by syz-executor7/4015:
     #0:  (rtnl_mutex){+.+.}, at: [<00000000a2f16daa>] rtnl_lock+0x17/0x20 net/core/rtnetlink.c:74
     #1:  (&tbl->lock){++-.}, at: [<00000000b5cb1d65>] neigh_ifdown+0x3d/0x250 net/core/neighbour.c:292
    
    stack backtrace:
    CPU: 0 PID: 4015 Comm: syz-executor7 Not tainted 4.16.0-rc4+ #277
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    Call Trace:
     __dump_stack lib/dump_stack.c:17 [inline]
     dump_stack+0x194/0x24d lib/dump_stack.c:53
     print_circular_bug.isra.38+0x2cd/0x2dc kernel/locking/lockdep.c:1223
     check_prev_add kernel/locking/lockdep.c:1863 [inline]
     check_prevs_add kernel/locking/lockdep.c:1976 [inline]
     validate_chain kernel/locking/lockdep.c:2417 [inline]
     __lock_acquire+0x30a8/0x3e00 kernel/locking/lockdep.c:3431
     lock_acquire+0x1d5/0x580 kernel/locking/lockdep.c:3920
     __raw_write_lock_bh include/linux/rwlock_api_smp.h:203 [inline]
     _raw_write_lock_bh+0x31/0x40 kernel/locking/spinlock.c:312
     __ipv6_dev_mc_dec+0x45/0x350 net/ipv6/mcast.c:928
     ipv6_dev_mc_dec+0x110/0x1f0 net/ipv6/mcast.c:961
     pndisc_destructor+0x21a/0x340 net/ipv6/ndisc.c:392
     pneigh_ifdown net/core/neighbour.c:695 [inline]
     neigh_ifdown+0x149/0x250 net/core/neighbour.c:294
     rt6_disable_ip+0x537/0x700 net/ipv6/route.c:3874
     addrconf_ifdown+0x14b/0x14f0 net/ipv6/addrconf.c:3633
     addrconf_notify+0x5f8/0x2310 net/ipv6/addrconf.c:3557
     notifier_call_chain+0x136/0x2c0 kernel/notifier.c:93
     __raw_notifier_call_chain kernel/notifier.c:394 [inline]
     raw_notifier_call_chain+0x2d/0x40 kernel/notifier.c:401
     call_netdevice_notifiers_info+0x32/0x70 net/core/dev.c:1707
     call_netdevice_notifiers net/core/dev.c:1725 [inline]
     __dev_notify_flags+0x262/0x430 net/core/dev.c:6960
     dev_change_flags+0xf5/0x140 net/core/dev.c:6994
     devinet_ioctl+0x126a/0x1ac0 net/ipv4/devinet.c:1080
     inet_ioctl+0x184/0x310 net/ipv4/af_inet.c:919
     packet_ioctl+0x1ff/0x310 net/packet/af_packet.c:4066
     sock_do_ioctl+0xef/0x390 net/socket.c:957
     sock_ioctl+0x36b/0x610 net/socket.c:1081
     vfs_ioctl fs/ioctl.c:46 [inline]
     do_vfs_ioctl+0x1b1/0x1520 fs/ioctl.c:686
     SYSC_ioctl fs/ioctl.c:701 [inline]
     SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
     do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
     entry_SYSCALL_64_after_hwframe+0x42/0xb7
    
    Fixes: c757faa8bfa2 ("ipv6: prepare fib6_age() for exception table")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Wei Wang <weiwan@google.com>
    Cc: Martin KaFai Lau <kafai@fb.com>
    Acked-by: Wei Wang <weiwan@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b2bf2cb68880ce34965fe9a0147ad2eba47c8109
Author: Roland Dreier <roland@purestorage.com>
Date:   Wed Mar 28 11:27:22 2018 -0700

    RDMA/ucma: Introduce safer rdma_addr_size() variants
    
    commit 84652aefb347297aa08e91e283adf7b18f77c2d5 upstream.
    
    There are several places in the ucma ABI where userspace can pass in a
    sockaddr but set the address family to AF_IB.  When that happens,
    rdma_addr_size() will return a size bigger than sizeof struct sockaddr_in6,
    and the ucma kernel code might end up copying past the end of a buffer
    not sized for a struct sockaddr_ib.
    
    Fix this by introducing new variants
    
        int rdma_addr_size_in6(struct sockaddr_in6 *addr);
        int rdma_addr_size_kss(struct __kernel_sockaddr_storage *addr);
    
    that are type-safe for the types used in the ucma ABI and return 0 if the
    size computed is bigger than the size of the type passed in.  We can use
    these new variants to check what size userspace has passed in before
    copying any addresses.
    
    Reported-by: <syzbot+6800425d54ed3ed8135d@syzkaller.appspotmail.com>
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f55b41ce03a776484735abd73a388603290cc826
Author: Leon Romanovsky <leonro@mellanox.com>
Date:   Sun Mar 25 11:39:05 2018 +0300

    RDMA/ucma: Check that device exists prior to accessing it
    
    commit c8d3bcbfc5eab3f01cf373d039af725f3b488813 upstream.
    
    Ensure that device exists prior to accessing its properties.
    
    Reported-by: <syzbot+71655d44855ac3e76366@syzkaller.appspotmail.com>
    Fixes: 75216638572f ("RDMA/cma: Export rdma cm interface to userspace")
    Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
    Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c0cbbca14176431682fdc8ee059736cecd48262f
Author: Leon Romanovsky <leonro@mellanox.com>
Date:   Sun Mar 25 11:23:55 2018 +0300

    RDMA/ucma: Check that device is connected prior to access it
    
    commit 4b658d1bbc16605330694bb3ef2570c465ef383d upstream.
    
    Add missing check that device is connected prior to access it.
    
    [   55.358652] BUG: KASAN: null-ptr-deref in rdma_init_qp_attr+0x4a/0x2c0
    [   55.359389] Read of size 8 at addr 00000000000000b0 by task qp/618
    [   55.360255]
    [   55.360432] CPU: 1 PID: 618 Comm: qp Not tainted 4.16.0-rc1-00071-gcaf61b1b8b88 #91
    [   55.361693] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.0-0-g63451fca13-prebuilt.qemu-project.org 04/01/2014
    [   55.363264] Call Trace:
    [   55.363833]  dump_stack+0x5c/0x77
    [   55.364215]  kasan_report+0x163/0x380
    [   55.364610]  ? rdma_init_qp_attr+0x4a/0x2c0
    [   55.365238]  rdma_init_qp_attr+0x4a/0x2c0
    [   55.366410]  ucma_init_qp_attr+0x111/0x200
    [   55.366846]  ? ucma_notify+0xf0/0xf0
    [   55.367405]  ? _get_random_bytes+0xea/0x1b0
    [   55.367846]  ? urandom_read+0x2f0/0x2f0
    [   55.368436]  ? kmem_cache_alloc_trace+0xd2/0x1e0
    [   55.369104]  ? refcount_inc_not_zero+0x9/0x60
    [   55.369583]  ? refcount_inc+0x5/0x30
    [   55.370155]  ? rdma_create_id+0x215/0x240
    [   55.370937]  ? _copy_to_user+0x4f/0x60
    [   55.371620]  ? mem_cgroup_commit_charge+0x1f5/0x290
    [   55.372127]  ? _copy_from_user+0x5e/0x90
    [   55.372720]  ucma_write+0x174/0x1f0
    [   55.373090]  ? ucma_close_id+0x40/0x40
    [   55.373805]  ? __lru_cache_add+0xa8/0xd0
    [   55.374403]  __vfs_write+0xc4/0x350
    [   55.374774]  ? kernel_read+0xa0/0xa0
    [   55.375173]  ? fsnotify+0x899/0x8f0
    [   55.375544]  ? fsnotify_unmount_inodes+0x170/0x170
    [   55.376689]  ? __fsnotify_update_child_dentry_flags+0x30/0x30
    [   55.377522]  ? handle_mm_fault+0x174/0x320
    [   55.378169]  vfs_write+0xf7/0x280
    [   55.378864]  SyS_write+0xa1/0x120
    [   55.379270]  ? SyS_read+0x120/0x120
    [   55.379643]  ? mm_fault_error+0x180/0x180
    [   55.380071]  ? task_work_run+0x7d/0xd0
    [   55.380910]  ? __task_pid_nr_ns+0x120/0x140
    [   55.381366]  ? SyS_read+0x120/0x120
    [   55.381739]  do_syscall_64+0xeb/0x250
    [   55.382143]  entry_SYSCALL_64_after_hwframe+0x21/0x86
    [   55.382841] RIP: 0033:0x7fc2ef803e99
    [   55.383227] RSP: 002b:00007fffcc5f3be8 EFLAGS: 00000217 ORIG_RAX: 0000000000000001
    [   55.384173] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fc2ef803e99
    [   55.386145] RDX: 0000000000000057 RSI: 0000000020000080 RDI: 0000000000000003
    [   55.388418] RBP: 00007fffcc5f3c00 R08: 0000000000000000 R09: 0000000000000000
    [   55.390542] R10: 0000000000000000 R11: 0000000000000217 R12: 0000000000400480
    [   55.392916] R13: 00007fffcc5f3cf0 R14: 0000000000000000 R15: 0000000000000000
    [   55.521088] Code: e5 4d 1e ff 48 89 df 44 0f b6 b3 b8 01 00 00 e8 65 50 1e ff 4c 8b 2b 49
    8d bd b0 00 00 00 e8 56 50 1e ff 41 0f b6 c6 48 c1 e0 04 <49> 03 85 b0 00 00 00 48 8d 78 08
    48 89 04 24 e8 3a 4f 1e ff 48
    [   55.525980] RIP: rdma_init_qp_attr+0x52/0x2c0 RSP: ffff8801e2c2f9d8
    [   55.532648] CR2: 00000000000000b0
    [   55.534396] ---[ end trace 70cee64090251c0b ]---
    
    Fixes: 75216638572f ("RDMA/cma: Export rdma cm interface to userspace")
    Fixes: d541e45500bd ("IB/core: Convert ah_attr from OPA to IB when copying to user")
    Reported-by: <syzbot+7b62c837c2516f8f38c8@syzkaller.appspotmail.com>
    Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
    Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c88aaa5ab28a9ac2ec70535cc3ecb343c680ff40
Author: Jason Gunthorpe <jgg@mellanox.com>
Date:   Thu Mar 22 14:04:23 2018 -0600

    RDMA/rdma_cm: Fix use after free race with process_one_req
    
    commit 9137108cc3d64ade13e753108ec611a0daed16a0 upstream.
    
    process_one_req() can race with rdma_addr_cancel():
    
               CPU0                                 CPU1
               ====                                 ====
     process_one_work()
      debug_work_deactivate(work);
      process_one_req()
                                            rdma_addr_cancel()
                                              mutex_lock(&lock);
                                               set_timeout(&req->work,..);
                                                  __queue_work()
                                                   debug_work_activate(work);
                                              mutex_unlock(&lock);
    
       mutex_lock(&lock);
    [..]
            list_del(&req->list);
       mutex_unlock(&lock);
    [..]
    
       // ODEBUG explodes since the work is still queued.
       kfree(req);
    
    Causing ODEBUG to detect the use after free:
    
    ODEBUG: free active (active state 0) object type: work_struct hint: process_one_req+0x0/0x6c0 include/net/dst.h:165
    WARNING: CPU: 0 PID: 79 at lib/debugobjects.c:291 debug_print_object+0x166/0x220 lib/debugobjects.c:288
    kvm: emulating exchange as write
    Kernel panic - not syncing: panic_on_warn set ...
    
    CPU: 0 PID: 79 Comm: kworker/u4:3 Not tainted 4.16.0-rc6+ #361
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    Workqueue: ib_addr process_one_req
    Call Trace:
     __dump_stack lib/dump_stack.c:17 [inline]
     dump_stack+0x194/0x24d lib/dump_stack.c:53
     panic+0x1e4/0x41c kernel/panic.c:183
     __warn+0x1dc/0x200 kernel/panic.c:547
     report_bug+0x1f4/0x2b0 lib/bug.c:186
     fixup_bug.part.11+0x37/0x80 arch/x86/kernel/traps.c:178
     fixup_bug arch/x86/kernel/traps.c:247 [inline]
     do_error_trap+0x2d7/0x3e0 arch/x86/kernel/traps.c:296
     do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
     invalid_op+0x1b/0x40 arch/x86/entry/entry_64.S:986
    RIP: 0010:debug_print_object+0x166/0x220 lib/debugobjects.c:288
    RSP: 0000:ffff8801d966f210 EFLAGS: 00010086
    RAX: dffffc0000000008 RBX: 0000000000000003 RCX: ffffffff815acd6e
    RDX: 0000000000000000 RSI: 1ffff1003b2cddf2 RDI: 0000000000000000
    RBP: ffff8801d966f250 R08: 0000000000000000 R09: 1ffff1003b2cddc8
    R10: ffffed003b2cde71 R11: ffffffff86f39a98 R12: 0000000000000001
    R13: ffffffff86f15540 R14: ffffffff86408700 R15: ffffffff8147c0a0
     __debug_check_no_obj_freed lib/debugobjects.c:745 [inline]
     debug_check_no_obj_freed+0x662/0xf1f lib/debugobjects.c:774
     kfree+0xc7/0x260 mm/slab.c:3799
     process_one_req+0x2e7/0x6c0 drivers/infiniband/core/addr.c:592
     process_one_work+0xc47/0x1bb0 kernel/workqueue.c:2113
     worker_thread+0x223/0x1990 kernel/workqueue.c:2247
     kthread+0x33c/0x400 kernel/kthread.c:238
     ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:406
    
    Fixes: 5fff41e1f89d ("IB/core: Fix race condition in resolving IP to MAC")
    Reported-by: <syzbot+3b4acab09b6463472d0a@syzkaller.appspotmail.com>
    Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5eb56dd0ba03968daca2dd5cf3aa01f3c2d8a15a
Author: Leon Romanovsky <leonro@mellanox.com>
Date:   Tue Mar 20 17:05:13 2018 +0200

    RDMA/ucma: Ensure that CM_ID exists prior to access it
    
    commit e8980d67d6017c8eee8f9c35f782c4bd68e004c9 upstream.
    
    Prior to access UCMA commands, the context should be initialized
    and connected to CM_ID with ucma_create_id(). In case user skips
    this step, he can provide non-valid ctx without CM_ID and cause
    to multiple NULL dereferences.
    
    Also there are situations where the create_id can be raced with
    other user access, ensure that the context is only shared to
    other threads once it is fully initialized to avoid the races.
    
    [  109.088108] BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
    [  109.090315] IP: ucma_connect+0x138/0x1d0
    [  109.092595] PGD 80000001dc02d067 P4D 80000001dc02d067 PUD 1da9ef067 PMD 0
    [  109.095384] Oops: 0000 [#1] SMP KASAN PTI
    [  109.097834] CPU: 0 PID: 663 Comm: uclose Tainted: G    B 4.16.0-rc1-00062-g2975d5de6428 #45
    [  109.100816] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.0-0-g63451fca13-prebuilt.qemu-project.org 04/01/2014
    [  109.105943] RIP: 0010:ucma_connect+0x138/0x1d0
    [  109.108850] RSP: 0018:ffff8801c8567a80 EFLAGS: 00010246
    [  109.111484] RAX: 0000000000000000 RBX: 1ffff100390acf50 RCX: ffffffff9d7812e2
    [  109.114496] RDX: 1ffffffff3f507a5 RSI: 0000000000000297 RDI: 0000000000000297
    [  109.117490] RBP: ffff8801daa15600 R08: 0000000000000000 R09: ffffed00390aceeb
    [  109.120429] R10: 0000000000000001 R11: ffffed00390aceea R12: 0000000000000000
    [  109.123318] R13: 0000000000000120 R14: ffff8801de6459c0 R15: 0000000000000118
    [  109.126221] FS:  00007fabb68d6700(0000) GS:ffff8801e5c00000(0000) knlGS:0000000000000000
    [  109.129468] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  109.132523] CR2: 0000000000000020 CR3: 00000001d45d8003 CR4: 00000000003606b0
    [  109.135573] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [  109.138716] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [  109.142057] Call Trace:
    [  109.144160]  ? ucma_listen+0x110/0x110
    [  109.146386]  ? wake_up_q+0x59/0x90
    [  109.148853]  ? futex_wake+0x10b/0x2a0
    [  109.151297]  ? save_stack+0x89/0xb0
    [  109.153489]  ? _copy_from_user+0x5e/0x90
    [  109.155500]  ucma_write+0x174/0x1f0
    [  109.157933]  ? ucma_resolve_route+0xf0/0xf0
    [  109.160389]  ? __mod_node_page_state+0x1d/0x80
    [  109.162706]  __vfs_write+0xc4/0x350
    [  109.164911]  ? kernel_read+0xa0/0xa0
    [  109.167121]  ? path_openat+0x1b10/0x1b10
    [  109.169355]  ? fsnotify+0x899/0x8f0
    [  109.171567]  ? fsnotify_unmount_inodes+0x170/0x170
    [  109.174145]  ? __fget+0xa8/0xf0
    [  109.177110]  vfs_write+0xf7/0x280
    [  109.179532]  SyS_write+0xa1/0x120
    [  109.181885]  ? SyS_read+0x120/0x120
    [  109.184482]  ? compat_start_thread+0x60/0x60
    [  109.187124]  ? SyS_read+0x120/0x120
    [  109.189548]  do_syscall_64+0xeb/0x250
    [  109.192178]  entry_SYSCALL_64_after_hwframe+0x21/0x86
    [  109.194725] RIP: 0033:0x7fabb61ebe99
    [  109.197040] RSP: 002b:00007fabb68d5e98 EFLAGS: 00000202 ORIG_RAX: 0000000000000001
    [  109.200294] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fabb61ebe99
    [  109.203399] RDX: 0000000000000120 RSI: 00000000200001c0 RDI: 0000000000000004
    [  109.206548] RBP: 00007fabb68d5ec0 R08: 0000000000000000 R09: 0000000000000000
    [  109.209902] R10: 0000000000000000 R11: 0000000000000202 R12: 00007fabb68d5fc0
    [  109.213327] R13: 0000000000000000 R14: 00007fff40ab2430 R15: 00007fabb68d69c0
    [  109.216613] Code: 88 44 24 2c 0f b6 84 24 6e 01 00 00 88 44 24 2d 0f
    b6 84 24 69 01 00 00 88 44 24 2e 8b 44 24 60 89 44 24 30 e8 da f6 06 ff
    31 c0 <66> 41 83 7c 24 20 1b 75 04 8b 44 24 64 48 8d 74 24 20 4c 89 e7
    [  109.223602] RIP: ucma_connect+0x138/0x1d0 RSP: ffff8801c8567a80
    [  109.226256] CR2: 0000000000000020
    
    Fixes: 75216638572f ("RDMA/cma: Export rdma cm interface to userspace")
    Reported-by: <syzbot+36712f50b0552615bf59@syzkaller.appspotmail.com>
    Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
    Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0b17ac3f080da021b759043ae9ab8dd8bbc5e852
Author: Leon Romanovsky <leonro@mellanox.com>
Date:   Mon Mar 19 14:20:15 2018 +0200

    RDMA/ucma: Fix use-after-free access in ucma_close
    
    commit ed65a4dc22083e73bac599ded6a262318cad7baf upstream.
    
    The error in ucma_create_id() left ctx in the list of contexts belong
    to ucma file descriptor. The attempt to close this file descriptor causes
    to use-after-free accesses while iterating over such list.
    
    Fixes: 75216638572f ("RDMA/cma: Export rdma cm interface to userspace")
    Reported-by: <syzbot+dcfd344365a56fbebd0f@syzkaller.appspotmail.com>
    Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
    Reviewed-by: Sean Hefty <sean.hefty@intel.com>
    Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a6474d6ef156d3d0ffeac4a30315b0ba1a8c663c
Author: Leon Romanovsky <leonro@mellanox.com>
Date:   Thu Mar 15 15:33:02 2018 +0200

    RDMA/ucma: Check AF family prior resolving address
    
    commit 2975d5de6428ff6d9317e9948f0968f7d42e5d74 upstream.
    
    Garbage supplied by user will cause to UCMA module provide zero
    memory size for memcpy(), because it wasn't checked, it will
    produce unpredictable results in rdma_resolve_addr().
    
    [   42.873814] BUG: KASAN: null-ptr-deref in rdma_resolve_addr+0xc8/0xfb0
    [   42.874816] Write of size 28 at addr 00000000000000a0 by task resaddr/1044
    [   42.876765]
    [   42.876960] CPU: 1 PID: 1044 Comm: resaddr Not tainted 4.16.0-rc1-00057-gaa56a5293d7e #34
    [   42.877840] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.0-0-g63451fca13-prebuilt.qemu-project.org 04/01/2014
    [   42.879691] Call Trace:
    [   42.880236]  dump_stack+0x5c/0x77
    [   42.880664]  kasan_report+0x163/0x380
    [   42.881354]  ? rdma_resolve_addr+0xc8/0xfb0
    [   42.881864]  memcpy+0x34/0x50
    [   42.882692]  rdma_resolve_addr+0xc8/0xfb0
    [   42.883366]  ? deref_stack_reg+0x88/0xd0
    [   42.883856]  ? vsnprintf+0x31a/0x770
    [   42.884686]  ? rdma_bind_addr+0xc40/0xc40
    [   42.885327]  ? num_to_str+0x130/0x130
    [   42.885773]  ? deref_stack_reg+0x88/0xd0
    [   42.886217]  ? __read_once_size_nocheck.constprop.6+0x10/0x10
    [   42.887698]  ? unwind_get_return_address_ptr+0x50/0x50
    [   42.888302]  ? replace_slot+0x147/0x170
    [   42.889176]  ? delete_node+0x12c/0x340
    [   42.890223]  ? __radix_tree_lookup+0xa9/0x160
    [   42.891196]  ? ucma_resolve_ip+0xb7/0x110
    [   42.891917]  ucma_resolve_ip+0xb7/0x110
    [   42.893003]  ? ucma_resolve_addr+0x190/0x190
    [   42.893531]  ? _copy_from_user+0x5e/0x90
    [   42.894204]  ucma_write+0x174/0x1f0
    [   42.895162]  ? ucma_resolve_route+0xf0/0xf0
    [   42.896309]  ? dequeue_task_fair+0x67e/0xd90
    [   42.897192]  ? put_prev_entity+0x7d/0x170
    [   42.897870]  ? ring_buffer_record_is_on+0xd/0x20
    [   42.898439]  ? tracing_record_taskinfo_skip+0x20/0x50
    [   42.899686]  __vfs_write+0xc4/0x350
    [   42.900142]  ? kernel_read+0xa0/0xa0
    [   42.900602]  ? firmware_map_remove+0xdf/0xdf
    [   42.901135]  ? do_task_dead+0x5d/0x60
    [   42.901598]  ? do_exit+0xcc6/0x1220
    [   42.902789]  ? __fget+0xa8/0xf0
    [   42.903190]  vfs_write+0xf7/0x280
    [   42.903600]  SyS_write+0xa1/0x120
    [   42.904206]  ? SyS_read+0x120/0x120
    [   42.905710]  ? compat_start_thread+0x60/0x60
    [   42.906423]  ? SyS_read+0x120/0x120
    [   42.908716]  do_syscall_64+0xeb/0x250
    [   42.910760]  entry_SYSCALL_64_after_hwframe+0x21/0x86
    [   42.912735] RIP: 0033:0x7f138b0afe99
    [   42.914734] RSP: 002b:00007f138b799e98 EFLAGS: 00000287 ORIG_RAX: 0000000000000001
    [   42.917134] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f138b0afe99
    [   42.919487] RDX: 000000000000002e RSI: 0000000020000c40 RDI: 0000000000000004
    [   42.922393] RBP: 00007f138b799ec0 R08: 00007f138b79a700 R09: 0000000000000000
    [   42.925266] R10: 00007f138b79a700 R11: 0000000000000287 R12: 00007f138b799fc0
    [   42.927570] R13: 0000000000000000 R14: 00007ffdbae757c0 R15: 00007f138b79a9c0
    [   42.930047]
    [   42.932681] Disabling lock debugging due to kernel taint
    [   42.934795] BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0
    [   42.936939] IP: memcpy_erms+0x6/0x10
    [   42.938864] PGD 80000001bea92067 P4D 80000001bea92067 PUD 1bea96067 PMD 0
    [   42.941576] Oops: 0002 [#1] SMP KASAN PTI
    [   42.943952] CPU: 1 PID: 1044 Comm: resaddr Tainted: G    B 4.16.0-rc1-00057-gaa56a5293d7e #34
    [   42.946964] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.0-0-g63451fca13-prebuilt.qemu-project.org 04/01/2014
    [   42.952336] RIP: 0010:memcpy_erms+0x6/0x10
    [   42.954707] RSP: 0018:ffff8801c8b479c8 EFLAGS: 00010286
    [   42.957227] RAX: 00000000000000a0 RBX: ffff8801c8b47ba0 RCX: 000000000000001c
    [   42.960543] RDX: 000000000000001c RSI: ffff8801c8b47bbc RDI: 00000000000000a0
    [   42.963867] RBP: ffff8801c8b47b60 R08: 0000000000000000 R09: ffffed0039168ed1
    [   42.967303] R10: 0000000000000001 R11: ffffed0039168ed0 R12: ffff8801c8b47bbc
    [   42.970685] R13: 00000000000000a0 R14: 1ffff10039168f4a R15: 0000000000000000
    [   42.973631] FS:  00007f138b79a700(0000) GS:ffff8801e5d00000(0000) knlGS:0000000000000000
    [   42.976831] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [   42.979239] CR2: 00000000000000a0 CR3: 00000001be908002 CR4: 00000000003606a0
    [   42.982060] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [   42.984877] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    [   42.988033] Call Trace:
    [   42.990487]  rdma_resolve_addr+0xc8/0xfb0
    [   42.993202]  ? deref_stack_reg+0x88/0xd0
    [   42.996055]  ? vsnprintf+0x31a/0x770
    [   42.998707]  ? rdma_bind_addr+0xc40/0xc40
    [   43.000985]  ? num_to_str+0x130/0x130
    [   43.003410]  ? deref_stack_reg+0x88/0xd0
    [   43.006302]  ? __read_once_size_nocheck.constprop.6+0x10/0x10
    [   43.008780]  ? unwind_get_return_address_ptr+0x50/0x50
    [   43.011178]  ? replace_slot+0x147/0x170
    [   43.013517]  ? delete_node+0x12c/0x340
    [   43.016019]  ? __radix_tree_lookup+0xa9/0x160
    [   43.018755]  ? ucma_resolve_ip+0xb7/0x110
    [   43.021270]  ucma_resolve_ip+0xb7/0x110
    [   43.023968]  ? ucma_resolve_addr+0x190/0x190
    [   43.026312]  ? _copy_from_user+0x5e/0x90
    [   43.029384]  ucma_write+0x174/0x1f0
    [   43.031861]  ? ucma_resolve_route+0xf0/0xf0
    [   43.034782]  ? dequeue_task_fair+0x67e/0xd90
    [   43.037483]  ? put_prev_entity+0x7d/0x170
    [   43.040215]  ? ring_buffer_record_is_on+0xd/0x20
    [   43.042990]  ? tracing_record_taskinfo_skip+0x20/0x50
    [   43.045595]  __vfs_write+0xc4/0x350
    [   43.048624]  ? kernel_read+0xa0/0xa0
    [   43.051604]  ? firmware_map_remove+0xdf/0xdf
    [   43.055379]  ? do_task_dead+0x5d/0x60
    [   43.058000]  ? do_exit+0xcc6/0x1220
    [   43.060783]  ? __fget+0xa8/0xf0
    [   43.063133]  vfs_write+0xf7/0x280
    [   43.065677]  SyS_write+0xa1/0x120
    [   43.068647]  ? SyS_read+0x120/0x120
    [   43.071179]  ? compat_start_thread+0x60/0x60
    [   43.074025]  ? SyS_read+0x120/0x120
    [   43.076705]  do_syscall_64+0xeb/0x250
    [   43.079006]  entry_SYSCALL_64_after_hwframe+0x21/0x86
    [   43.081606] RIP: 0033:0x7f138b0afe99
    [   43.083679] RSP: 002b:00007f138b799e98 EFLAGS: 00000287 ORIG_RAX: 0000000000000001
    [   43.086802] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f138b0afe99
    [   43.089989] RDX: 000000000000002e RSI: 0000000020000c40 RDI: 0000000000000004
    [   43.092866] RBP: 00007f138b799ec0 R08: 00007f138b79a700 R09: 0000000000000000
    [   43.096233] R10: 00007f138b79a700 R11: 0000000000000287 R12: 00007f138b799fc0
    [   43.098913] R13: 0000000000000000 R14: 00007ffdbae757c0 R15: 00007f138b79a9c0
    [   43.101809] Code: 90 90 90 90 90 eb 1e 0f 1f 00 48 89 f8 48 89 d1 48
    c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48
    89 d1 <f3> a4 c3 0f 1f 80 00 00 00 00 48 89 f8 48 83 fa 20 72 7e 40 38
    [   43.107950] RIP: memcpy_erms+0x6/0x10 RSP: ffff8801c8b479c8
    
    Reported-by: <syzbot+1d8c43206853b369d00c@syzkaller.appspotmail.com>
    Fixes: 75216638572f ("RDMA/cma: Export rdma cm interface to userspace")
    Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
    Reviewed-by: Sean Hefty <sean.hefty@intel.com>
    Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7df65ad1d45ad7cdf68cd6b88c0d19f9ddcd1855
Author: Florian Westphal <fw@strlen.de>
Date:   Mon Feb 12 14:42:01 2018 +0100

    xfrm_user: uncoditionally validate esn replay attribute struct
    
    commit d97ca5d714a5334aecadadf696875da40f1fbf3e upstream.
    
    The sanity test added in ecd7918745234 can be bypassed, validation
    only occurs if XFRM_STATE_ESN flag is set, but rest of code doesn't care
    and just checks if the attribute itself is present.
    
    So always validate.  Alternative is to reject if we have the attribute
    without the flag but that would change abi.
    
    Reported-by: syzbot+0ab777c27d2bb7588f73@syzkaller.appspotmail.com
    Cc: Mathias Krause <minipli@googlemail.com>
    Fixes: ecd7918745234 ("xfrm_user: ensure user supplied esn replay window is valid")
    Fixes: d8647b79c3b7e ("xfrm: Add user interface for esn and big anti-replay windows")
    Signed-off-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit abb971a27ed5c3890791e503f7acd832c75b50ca
Author: Richard Narron <comet.berkeley@gmail.com>
Date:   Wed Jan 10 09:12:16 2018 -0700

    partitions/msdos: Unable to mount UFS 44bsd partitions
    
    commit 5f15684bd5e5ef39d4337988864fec8012471dda upstream.
    
    UFS partitions from newer versions of FreeBSD 10 and 11 use relative
    addressing for their subpartitions. But older versions of FreeBSD still
    use absolute addressing just like OpenBSD and NetBSD.
    
    Instead of simply testing for a FreeBSD partition, the code needs to
    also test if the starting offset of the C subpartition is zero.
    
    https://bugzilla.kernel.org/show_bug.cgi?id=197733
    
    Signed-off-by: Richard Narron <comet.berkeley@gmail.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cc842a34bfb21e18ecfb802bb021cabd9f2ce58c
Author: Nicholas Piggin <npiggin@gmail.com>
Date:   Fri Mar 23 15:53:38 2018 +1000

    powerpc/64s: Fix i-side SLB miss bad address handler saving nonvolatile GPRs
    
    commit 52396500f97c53860164debc7d4f759077853423 upstream.
    
    The SLB bad address handler's trap number fixup does not preserve the
    low bit that indicates nonvolatile GPRs have not been saved. This
    leads save_nvgprs to skip saving them, and subsequent functions and
    return from interrupt will think they are saved.
    
    This causes kernel branch-to-garbage debugging to not have correct
    registers, can also cause userspace to have its registers clobbered
    after a segfault.
    
    Fixes: f0f558b131db ("powerpc/mm: Preserve CFAR value on SLB miss caused by access to bogus address")
    Cc: stable@vger.kernel.org # v4.9+
    Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f8e68e8f8db5d89eb82aa79df5e66c4d08d527ad
Author: Nicholas Piggin <npiggin@gmail.com>
Date:   Wed Mar 21 12:22:28 2018 +1000

    powerpc/64s: Fix lost pending interrupt due to race causing lost update to irq_happened
    
    commit ff6781fd1bb404d8a551c02c35c70cec1da17ff1 upstream.
    
    force_external_irq_replay() can be called in the do_IRQ path with
    interrupts hard enabled and soft disabled if may_hard_irq_enable() set
    MSR[EE]=1. It updates local_paca->irq_happened with a load, modify,
    store sequence. If a maskable interrupt hits during this sequence, it
    will go to the masked handler to be marked pending in irq_happened.
    This update will be lost when the interrupt returns and the store
    instruction executes. This can result in unpredictable latencies,
    timeouts, lockups, etc.
    
    Fix this by ensuring hard interrupts are disabled before modifying
    irq_happened.
    
    This could cause any maskable asynchronous interrupt to get lost, but
    it was noticed on P9 SMP system doing RDMA NVMe target over 100GbE,
    so very high external interrupt rate and high IPI rate. The hang was
    bisected down to enabling doorbell interrupts for IPIs. These provided
    an interrupt type that could run at high rates in the do_IRQ path,
    stressing the race.
    
    Fixes: 1d607bb3bd60 ("powerpc/irq: Add mechanism to force a replay of interrupts")
    Cc: stable@vger.kernel.org # v4.8+
    Reported-by: Carol L. Soto <clsoto@us.ibm.com>
    Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5c0b4a907396a8c6d485d07c951db2ee9e4f9383
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date:   Fri Mar 23 09:29:06 2018 +1100

    powerpc/mm: Workaround Nest MMU bug with TLB invalidations
    
    commit 80a4ae202f2d319eced8bbf612a4e8b0f11c21f5 upstream.
    
    On POWER9 the Nest MMU may fail to invalidate some translations when
    doing a tlbie "by PID" or "by LPID" that is targeted at the TLB only
    and not the page walk cache.
    
    This works around it by forcing such invalidations to escalate to
    RIC=2 (full invalidation of TLB *and* PWC) when a coprocessor is in
    use for the context.
    
    Fixes: 03b8abedf4f4 ("cxl: Enable global TLBIs for cxl contexts")
    Cc: stable@vger.kernel.org # v4.15+
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Balbir Singh <bsingharora@gmail.com>
    [balbirs: fixed spelling and coding style to quiesce checkpatch.pl]
    Tested-by: Balbir Singh <bsingharora@gmail.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d657375f3616757c123cb2507ae8b4abf80432a1
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date:   Fri Mar 23 09:29:05 2018 +1100

    powerpc/mm: Add tracking of the number of coprocessors using a context
    
    commit aff6f8cb3e2170b9e58b0932bce7bfb492775e23 upstream.
    
    Currently, when using coprocessors (which use the Nest MMU), we
    simply increment the active_cpu count to force all TLB invalidations
    to be come broadcast.
    
    Unfortunately, due to an errata in POWER9, we will need to know
    more specifically that coprocessors are in use.
    
    This maintains a separate copros counter in the MMU context for
    that purpose.
    
    NB. The commit mentioned in the fixes tag below is not at fault for
    the bug we're fixing in this commit and the next, but this fix applies
    on top the infrastructure it introduced.
    
    Fixes: 03b8abedf4f4 ("cxl: Enable global TLBIs for cxl contexts")
    Cc: stable@vger.kernel.org # v4.15+
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Tested-by: Balbir Singh <bsingharora@gmail.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b61312ebb1c9db164cf1a72eb5dcac4464330665
Author: Pierre-Yves MORDRET <pierre-yves.mordret@st.com>
Date:   Wed Mar 21 17:48:40 2018 +0100

    i2c: i2c-stm32f7: fix no check on returned setup
    
    commit 771b7bf05339081019d22452ebcab6929372e13e upstream.
    
    Before assigning returned setup structure check if not null
    
    Fixes: 463a9215f3ca7600b5ff ("i2c: stm32f7: fix setup structure")
    Signed-off-by: Pierre-Yves MORDRET <pierre-yves.mordret@st.com>
    Acked-by: Alexandre TORGUE <alexandre.torgue@st.com>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 19254443adf9f2c7df55d88754eb397d24022f08
Author: Mike Kravetz <mike.kravetz@oracle.com>
Date:   Wed Mar 28 16:01:01 2018 -0700

    ipc/shm.c: add split function to shm_vm_ops
    
    commit 3d942ee079b917b24e2a0c5f18d35ac8ec9fee48 upstream.
    
    If System V shmget/shmat operations are used to create a hugetlbfs
    backed mapping, it is possible to munmap part of the mapping and split
    the underlying vma such that it is not huge page aligned.  This will
    untimately result in the following BUG:
    
      kernel BUG at /build/linux-jWa1Fv/linux-4.15.0/mm/hugetlb.c:3310!
      Oops: Exception in kernel mode, sig: 5 [#1]
      LE SMP NR_CPUS=2048 NUMA PowerNV
      Modules linked in: kcm nfc af_alg caif_socket caif phonet fcrypt
      CPU: 18 PID: 43243 Comm: trinity-subchil Tainted: G         C  E 4.15.0-10-generic #11-Ubuntu
      NIP:  c00000000036e764 LR: c00000000036ee48 CTR: 0000000000000009
      REGS: c000003fbcdcf810 TRAP: 0700   Tainted: G         C  E (4.15.0-10-generic)
      MSR:  9000000000029033 <SF,HV,EE,ME,IR,DR,RI,LE>  CR: 24002222  XER: 20040000
      CFAR: c00000000036ee44 SOFTE: 1
      NIP __unmap_hugepage_range+0xa4/0x760
      LR __unmap_hugepage_range_final+0x28/0x50
      Call Trace:
        0x7115e4e00000 (unreliable)
        __unmap_hugepage_range_final+0x28/0x50
        unmap_single_vma+0x11c/0x190
        unmap_vmas+0x94/0x140
        exit_mmap+0x9c/0x1d0
        mmput+0xa8/0x1d0
        do_exit+0x360/0xc80
        do_group_exit+0x60/0x100
        SyS_exit_group+0x24/0x30
        system_call+0x58/0x6c
      ---[ end trace ee88f958a1c62605 ]---
    
    This bug was introduced by commit 31383c6865a5 ("mm, hugetlbfs:
    introduce ->split() to vm_operations_struct").  A split function was
    added to vm_operations_struct to determine if a mapping can be split.
    This was mostly for device-dax and hugetlbfs mappings which have
    specific alignment constraints.
    
    Mappings initiated via shmget/shmat have their original vm_ops
    overwritten with shm_vm_ops.  shm_vm_ops functions will call back to the
    original vm_ops if needed.  Add such a split function to shm_vm_ops.
    
    Link: http://lkml.kernel.org/r/20180321161314.7711-1-mike.kravetz@oracle.com
    Fixes: 31383c6865a5 ("mm, hugetlbfs: introduce ->split() to vm_operations_struct")
    Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
    Reported-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
    Reviewed-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
    Tested-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
    Reviewed-by: Dan Williams <dan.j.williams@intel.com>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Cc: Davidlohr Bueso <dave@stgolabs.net>
    Cc: Manfred Spraul <manfred@colorfullife.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 f2fb59601631b275a66f70508a1e7254e2c15563
Author: Yan, Zheng <zyan@redhat.com>
Date:   Fri Mar 16 11:22:29 2018 +0800

    ceph: only dirty ITER_IOVEC pages for direct read
    
    commit 85784f9395987a422fa04263e7c0fb13da11eb5c upstream.
    
    If a page is already locked, attempting to dirty it leads to a deadlock
    in lock_page().  This is what currently happens to ITER_BVEC pages when
    a dio-enabled loop device is backed by ceph:
    
      $ losetup --direct-io /dev/loop0 /mnt/cephfs/img
      $ xfs_io -c 'pread 0 4k' /dev/loop0
    
    Follow other file systems and only dirty ITER_IOVEC pages.
    
    Cc: stable@kernel.org
    Signed-off-by: "Yan, Zheng" <zyan@redhat.com>
    Reviewed-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9b5b7c382e11be732ab63bdc872876e7c886de65
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Mon Mar 26 15:39:07 2018 -1000

    perf/hwbp: Simplify the perf-hwbp code, fix documentation
    
    commit f67b15037a7a50c57f72e69a6d59941ad90a0f0f upstream.
    
    Annoyingly, modify_user_hw_breakpoint() unnecessarily complicates the
    modification of a breakpoint - simplify it and remove the pointless
    local variables.
    
    Also update the stale Docbook while at it.
    
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Acked-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: <stable@vger.kernel.org>
    Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Frederic Weisbecker <fweisbec@gmail.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Stephane Eranian <eranian@google.com>
    Cc: Vince Weaver <vincent.weaver@maine.edu>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a408b211f57906dac53e4c03576e1090ef120a5e
Author: Andrew Banman <abanman@hpe.com>
Date:   Tue Mar 27 17:09:06 2018 -0500

    x86/platform/uv/BAU: Add APIC idt entry
    
    commit 151ad17fbe5e56afa59709f41980508672c777ce upstream.
    
    BAU uses the old alloc_initr_gate90 method to setup its interrupt. This
    fails silently as the BAU vector is in the range of APIC vectors that are
    registered to the spurious interrupt handler. As a consequence BAU
    broadcasts are not handled, and the broadcast source CPU hangs.
    
    Update BAU to use new idt structure.
    
    Fixes: dc20b2d52653 ("x86/idt: Move interrupt gate initialization to IDT code")
    Signed-off-by: Andrew Banman <abanman@hpe.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Acked-by: Mike Travis <mike.travis@hpe.com>
    Cc: Dimitri Sivanich <sivanich@hpe.com>
    Cc: Russ Anderson <rja@hpe.com>
    Cc: stable@vger.kernel.org
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Link: https://lkml.kernel.org/r/1522188546-196177-1-git-send-email-abanman@hpe.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 740aa15795262589b9ee59b0d632f8146db7bc5c
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue Mar 27 16:07:52 2018 +0300

    ALSA: pcm: potential uninitialized return values
    
    commit 5607dddbfca774fb38bffadcb077fe03aa4ac5c6 upstream.
    
    Smatch complains that "tmp" can be uninitialized if we do a zero size
    write.
    
    Fixes: 02a5d6925cd3 ("ALSA: pcm: Avoid potential races between OSS ioctls and read/write")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4321a749661b458254588b83f41e4e91d81c738f
Author: Stefan Roese <sr@denx.de>
Date:   Mon Mar 26 16:10:21 2018 +0200

    ALSA: pcm: Use dma_bytes as size parameter in dma_mmap_coherent()
    
    commit 9066ae7ff5d89c0b5daa271e2d573540097a94fa upstream.
    
    When trying to use the driver (e.g. aplay *.wav), the 4MiB DMA buffer
    will get mmapp'ed in 16KiB chunks. But this fails with the 2nd 16KiB
    area, as the page offset is outside of the VMA range (size), which is
    currently used as size parameter in snd_pcm_lib_default_mmap(). By
    using the DMA buffer size (dma_bytes) instead, the complete DMA buffer
    can be mmapp'ed and the issue is fixed.
    
    This issue was detected on an ARM platform (TI AM57xx) using the RME
    HDSP MADI PCIe soundcard.
    
    Fixes: 657b1989dacf ("ALSA: pcm - Use dma_mmap_coherent() if available")
    Signed-off-by: Stefan Roese <sr@denx.de>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5891c83b01ad797bd6f05599bc060ea2932e5b42
Author: Nobutaka Okabe <nob77413@gmail.com>
Date:   Fri Mar 23 19:49:44 2018 +0900

    ALSA: usb-audio: Add native DSD support for TEAC UD-301
    
    commit b00214865d65100163574ba250008f182cf90869 upstream.
    
    Add native DSD support quirk for TEAC UD-301 DAC,
    by adding the PID/VID 0644:804a.
    
    Signed-off-by: Nobutaka Okabe <nob77413@gmail.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6aa2e5ddc3cdfed13aff5268d461a2629a8880a0
Author: Boris Brezillon <boris.brezillon@bootlin.com>
Date:   Tue Mar 27 19:01:58 2018 +0200

    mtd: nand: atmel: Fix get_sectorsize() function
    
    commit 2b1b1b4ac716fd929a2d221bd4ade62263bed915 upstream.
    
    get_sectorsize() was not using the appropriate macro to extract the
    ECC sector size from the config cache, which led to buggy ECC when
    using 1024 byte sectors.
    
    Fixes: f88fc122cc34 ("mtd: nand: Cleanup/rework the atmel_nand driver")
    Cc: <stable@vger.kernel.org>
    Reported-by: Olivier Schonken <olivier.schonken@gmail.com>
    Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
    Reviewed-by: Richard Weinberger <richard@nod.at>
    Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
    Tested-by: Olivier Schonken <olivier.schonken@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e80deb59802c1de82a9ce7932f88936cf2ec3d76
Author: Linus Walleij <linus.walleij@linaro.org>
Date:   Sat Mar 3 23:29:03 2018 +0100

    mtd: jedec_probe: Fix crash in jedec_read_mfr()
    
    commit 87a73eb5b56fd6e07c8e499fe8608ef2d8912b82 upstream.
    
    It turns out that the loop where we read manufacturer
    jedec_read_mfd() can under some circumstances get a
    CFI_MFR_CONTINUATION repeatedly, making the loop go
    over all banks and eventually hit the end of the
    map and crash because of an access violation:
    
    Unable to handle kernel paging request at virtual address c4980000
    pgd = (ptrval)
    [c4980000] *pgd=03808811, *pte=00000000, *ppte=00000000
    Internal error: Oops: 7 [#1] PREEMPT ARM
    CPU: 0 PID: 1 Comm: swapper Not tainted 4.16.0-rc1+ #150
    Hardware name: Gemini (Device Tree)
    PC is at jedec_probe_chip+0x6ec/0xcd0
    LR is at 0x4
    pc : [<c03a2bf4>]    lr : [<00000004>]    psr: 60000013
    sp : c382dd18  ip : 0000ffff  fp : 00000000
    r10: c0626388  r9 : 00020000  r8 : c0626340
    r7 : 00000000  r6 : 00000001  r5 : c3a71afc  r4 : c382dd70
    r3 : 00000001  r2 : c4900000  r1 : 00000002  r0 : 00080000
    Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
    Control: 0000397f  Table: 00004000  DAC: 00000053
    Process swapper (pid: 1, stack limit = 0x(ptrval))
    
    Fix this by breaking the loop with a return 0 if
    the offset exceeds the map size.
    
    Fixes: 5c9c11e1c47c ("[MTD] [NOR] Add support for flash chips with ID in bank other than 0")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 26692e9a0aafa4b5aff420f2fadb4568af576628
Author: Philipp Rossak <embed3d@gmail.com>
Date:   Wed Feb 14 15:10:25 2018 +0100

    ARM: dts: sun6i: a31s: bpi-m2: add missing regulators
    
    commit 70b8d21496758dd7ff600ec9de0ee3812fac7a40 upstream.
    
    This patch fixes a bootproblem with the Bananapi M2 board. Since there
    are some regulators missing we add them right now. Those values come
    from the schematic, below you can find a small overview:
    
    * reg_aldo1:  3,3V, powers the wifi
    * reg_aldo2:  2,5V, powers the IO of the RTL8211E
    * reg_aldo3:  3,3V, powers the audio
    
    * reg_dldo1:  3,0V, powers the RTL8211E
    * reg_dldo2:  2,8V, powers the analog part of the csi
    * reg_dldo3:  3,3V, powers misc
    * reg_eldo1:  1,8V, powers the csi
    * reg_ldo_io1:1,8V, powers the gpio
    
    * reg_dc5ldo: needs to be always on
    
    This patch updates also the vmmc-supply properties on the mmc0 and mmc2
    node to use the allready existent regulators.
    We can now remove the sunxi-common-regulators.dtsi include since we
    don't need it anymore.
    
    Fixes: 7daa21370075 ("ARM: dts: sunxi: Add regulators for Sinovoip BPI-M2")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Philipp Rossak <embed3d@gmail.com>
    Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit acc7f0201fc3553b913ac9fdefffcf253b16d536
Author: Philipp Rossak <embed3d@gmail.com>
Date:   Wed Feb 14 15:10:24 2018 +0100

    ARM: dts: sun6i: a31s: bpi-m2: improve pmic properties
    
    commit b23af6ad8d2f708c4c3f92dd8f82c233247ba8bf upstream.
    
    The eldoin is supplied from the dcdc1 regulator. The N_VBUSEN pin is
    connected to an external power regulator (SY6280AAC).
    With this commit we update the pmic binding properties to support
    those features.
    
    Fixes: 7daa21370075 ("ARM: dts: sunxi: Add regulators for Sinovoip BPI-M2")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Philipp Rossak <embed3d@gmail.com>
    Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 955901702381e39eb2c3e28d605c88eea3d91ef6
Author: Fabio Estevam <festevam@gmail.com>
Date:   Mon Jan 22 12:20:26 2018 +0100

    ARM: 8746/1: vfp: Go back to clearing vfp_current_hw_state[]
    
    commit 1328f02005bbbaed15b9d5b7f3ab5ec9d4d5268a upstream.
    
    Commit 384b38b66947 ("ARM: 7873/1: vfp: clear vfp_current_hw_state
    for dying cpu") fixed the cpu dying notifier by clearing
    vfp_current_hw_state[]. However commit e5b61bafe704 ("arm: Convert VFP
    hotplug notifiers to state machine") incorrectly used the original
    vfp_force_reload() function in the cpu dying notifier.
    
    Fix it by going back to clearing vfp_current_hw_state[].
    
    Fixes: e5b61bafe704 ("arm: Convert VFP hotplug notifiers to state machine")
    Cc: linux-stable <stable@vger.kernel.org>
    Reported-by: Kohji Okuno <okuno.kohji@jp.panasonic.com>
    Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 37496fe93169216f56d8de3e6b15c59712374915
Author: Tony Lindgren <tony@atomide.com>
Date:   Wed Mar 21 08:16:29 2018 -0700

    ARM: OMAP: Fix SRAM W+X mapping
    
    commit eb85a355c3afd9379f5953cfe2df73632d14c884 upstream.
    
    We are still using custom SRAM code for some SoCs and are not marking
    the PM code mapped to SRAM as read-only and executable after we're
    done. With CONFIG_DEBUG_WX=y, we will get "Found insecure W+X mapping
    at address" warning.
    
    Let's fix this issue the same way as commit 728bbe75c82f ("misc: sram:
    Introduce support code for protect-exec sram type") is doing for
    drivers/misc/sram-exec.c.
    
    On omap3, we need to restore SRAM when returning from off mode after
    idle, so init time configuration is not enough.
    
    And as we no longer have users for omap_sram_push_address() we can
    make it static while at it.
    
    Note that eventually we should be using sram-exec.c for all SoCs.
    
    Cc: stable@vger.kernel.org      # v4.12+
    Cc: Dave Gerlach <d-gerlach@ti.com>
    Reported-by: Pavel Machek <pavel@ucw.cz>
    Signed-off-by: Tony Lindgren <tony@atomide.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
