commit c806e0856941597f058b4a527d77dbc0000c513c
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Jun 26 08:08:09 2018 +0800

    Linux 4.9.110

commit f3e7234932eb6a459963b13899241357306fae32
Author: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Date:   Thu Jun 7 17:11:01 2018 -0700

    fs/binfmt_misc.c: do not allow offset overflow
    
    commit 5cc41e099504b77014358b58567c5ea6293dd220 upstream.
    
    WHen registering a new binfmt_misc handler, it is possible to overflow
    the offset to get a negative value, which might crash the system, or
    possibly leak kernel data.
    
    Here is a crash log when 2500000000 was used as an offset:
    
      BUG: unable to handle kernel paging request at ffff989cfd6edca0
      IP: load_misc_binary+0x22b/0x470 [binfmt_misc]
      PGD 1ef3e067 P4D 1ef3e067 PUD 0
      Oops: 0000 [#1] SMP NOPTI
      Modules linked in: binfmt_misc kvm_intel ppdev kvm irqbypass joydev input_leds serio_raw mac_hid parport_pc qemu_fw_cfg parpy
      CPU: 0 PID: 2499 Comm: bash Not tainted 4.15.0-22-generic #24-Ubuntu
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.1-1 04/01/2014
      RIP: 0010:load_misc_binary+0x22b/0x470 [binfmt_misc]
      Call Trace:
        search_binary_handler+0x97/0x1d0
        do_execveat_common.isra.34+0x667/0x810
        SyS_execve+0x31/0x40
        do_syscall_64+0x73/0x130
        entry_SYSCALL_64_after_hwframe+0x3d/0xa2
    
    Use kstrtoint instead of simple_strtoul.  It will work as the code
    already set the delimiter byte to '\0' and we only do it when the field
    is not empty.
    
    Tested with offsets -1, 2500000000, UINT_MAX and INT_MAX.  Also tested
    with examples documented at Documentation/admin-guide/binfmt-misc.rst
    and other registrations from packages on Ubuntu.
    
    Link: http://lkml.kernel.org/r/20180529135648.14254-1-cascardo@canonical.com
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
    Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
    Cc: Alexander Viro <viro@zeniv.linux.org.uk>
    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 9681c3bdb098f6c87a0422b6b63912c1b90ad197
Author: Michael S. Tsirkin <mst@redhat.com>
Date:   Sat May 12 00:33:10 2018 +0300

    vhost: fix info leak due to uninitialized memory
    
    commit 670ae9caaca467ea1bfd325cb2a5c98ba87f94ad upstream.
    
    struct vhost_msg within struct vhost_msg_node is copied to userspace.
    Unfortunately it turns out on 64 bit systems vhost_msg has padding after
    type which gcc doesn't initialize, leaking 4 uninitialized bytes to
    userspace.
    
    This padding also unfortunately means 32 bit users of this interface are
    broken on a 64 bit kernel which will need to be fixed separately.
    
    Fixes: CVE-2018-1118
    Cc: stable@vger.kernel.org
    Reported-by: Kevin Easton <kevin@guarana.org>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Reported-by: syzbot+87cfa083e727a224754b@syzkaller.appspotmail.com
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a875bc1c9ec116b7b2b2f15f8edc2a2ac3c51f99
Author: Even Xu <even.xu@intel.com>
Date:   Fri Feb 12 04:11:34 2016 +0800

    HID: intel_ish-hid: ipc: register more pm callbacks to support hibernation
    
    commit ebeaa367548e9e92dd9374b9464ff6e7d157117b upstream.
    
    Current ISH driver only registers suspend/resume PM callbacks which don't
    support hibernation (suspend to disk). Basically after hiberation, the ISH
    can't resume properly and user may not see sensor events (for example: screen
                    rotation may not work).
    
    User will not see a crash or panic or anything except the following message
    in log:
    
            hid-sensor-hub 001F:8086:22D8.0001: timeout waiting for response from ISHTP device
    
    So this patch adds support for S4/hiberbation to ISH by using the
    SIMPLE_DEV_PM_OPS() MACRO instead of struct dev_pm_ops directly. The suspend
    and resume functions will now be used for both suspend to RAM and hibernation.
    
    If power management is disabled, SIMPLE_DEV_PM_OPS will do nothing, the suspend
    and resume related functions won't be used, so mark them as __maybe_unused to
    clarify that this is the intended behavior, and remove #ifdefs for power
    management.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Even Xu <even.xu@intel.com>
    Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 88f36d1b4f0b8163a6b9155e75d9be7d0074d834
Author: Martin Brandenburg <martin@omnibond.com>
Date:   Thu May 31 16:36:58 2018 +0000

    orangefs: set i_size on new symlink
    
    commit f6a4b4c9d07dda90c7c29dae96d6119ac6425dca upstream.
    
    As long as a symlink inode remains in-core, the destination (and
    therefore size) will not be re-fetched from the server, as it cannot
    change.  The original implementation of the attribute cache assumed that
    setting the expiry time in the past was sufficient to cause a re-fetch
    of all attributes on the next getattr.  That does not work in this case.
    
    The bug manifested itself as follows.  When the command sequence
    
    touch foo; ln -s foo bar; ls -l bar
    
    is run, the output was
    
    lrwxrwxrwx. 1 fedora fedora 4906 Apr 24 19:10 bar -> foo
    
    However, after a re-mount, ls -l bar produces
    
    lrwxrwxrwx. 1 fedora fedora    3 Apr 24 19:10 bar -> foo
    
    After this commit, even before a re-mount, the output is
    
    lrwxrwxrwx. 1 fedora fedora    3 Apr 24 19:10 bar -> foo
    
    Reported-by: Becky Ligon <ligon@clemson.edu>
    Signed-off-by: Martin Brandenburg <martin@omnibond.com>
    Fixes: 71680c18c8f2 ("orangefs: Cache getattr results.")
    Cc: stable@vger.kernel.org
    Cc: hubcap@omnibond.com
    Signed-off-by: Mike Marshall <hubcap@omnibond.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aec3dd5ef1f0fb570027fe3a42bbc1d3d1f1828f
Author: Stefan Potyra <Stefan.Potyra@elektrobit.com>
Date:   Wed May 2 10:55:31 2018 +0200

    w1: mxc_w1: Enable clock before calling clk_get_rate() on it
    
    commit 955bc61328dc0a297fb3baccd84e9d3aee501ed8 upstream.
    
    According to the API, you may only call clk_get_rate() after actually
    enabling it.
    
    Found by Linux Driver Verification project (linuxtesting.org).
    
    Fixes: a5fd9139f74c ("w1: add 1-wire master driver for i.MX27 / i.MX31")
    Signed-off-by: Stefan Potyra <Stefan.Potyra@elektrobit.com>
    Acked-by: Evgeniy Polyakov <zbr@ioremap.net>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 139cd53baf08d80db81eb32a72dc24501cb8f296
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Thu May 31 13:21:07 2018 +0200

    libata: Drop SanDisk SD7UB3Q*G1001 NOLPM quirk
    
    commit 2cfce3a86b64b53f0a70e92a6a659c720c319b45 upstream.
    
    Commit 184add2ca23c ("libata: Apply NOLPM quirk for SanDisk
    SD7UB3Q*G1001 SSDs") disabled LPM for SanDisk SD7UB3Q*G1001 SSDs.
    
    This has lead to several reports of users of that SSD where LPM
    was working fine and who know have a significantly increased idle
    power consumption on their laptops.
    
    Likely there is another problem on the T450s from the original
    reporter which gets exposed by the uncore reaching deeper sleep
    states (higher PC-states) due to LPM being enabled. The problem as
    reported, a hardfreeze about once a day, already did not sound like
    it would be caused by LPM and the reports of the SSD working fine
    confirm this. The original reporter is ok with dropping the quirk.
    
    A X250 user has reported the same hard freeze problem and for him
    the problem went away after unrelated updates, I suspect some GPU
    driver stack changes fixed things.
    
    TL;DR: The original reporters problem were triggered by LPM but not
    an LPM issue, so drop the quirk for the SSD in question.
    
    BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1583207
    Cc: stable@vger.kernel.org
    Cc: Richard W.M. Jones <rjones@redhat.com>
    Cc: Lorenzo Dalrio <lorenzo.dalrio@gmail.com>
    Reported-by: Lorenzo Dalrio <lorenzo.dalrio@gmail.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Acked-by: "Richard W.M. Jones" <rjones@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0e9806ec7376e1a285d7b9ee634a782f10155540
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Tue May 29 12:13:24 2018 +0300

    libata: zpodd: small read overflow in eject_tray()
    
    commit 18c9a99bce2a57dfd7e881658703b5d7469cc7b9 upstream.
    
    We read from the cdb[] buffer in ata_exec_internal_sg().  It has to be
    ATAPI_CDB_LEN (16) bytes long, but this buffer is only 12 bytes.
    
    Fixes: 213342053db5 ("libata: handle power transition of ODD")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 21e6919834360389b6f3db6a04603b6aba0c6219
Author: Colin Ian King <colin.king@canonical.com>
Date:   Wed Sep 6 09:56:29 2017 +0100

    libata: zpodd: make arrays cdb static, reduces object code size
    
    commit 795ef788145ed2fa023efdf11e8d5d7bedc21462 upstream.
    
    Don't populate the arrays cdb on the stack, instead make them static.
    Makes the object code smaller by 230 bytes:
    
    Before:
       text    data     bss     dec     hex filename
       3797     240       0    4037     fc5 drivers/ata/libata-zpodd.o
    
    After:
       text    data     bss     dec     hex filename
       3407     400       0    3807     edf drivers/ata/libata-zpodd.o
    
    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5930589d3f85484611a9084169c8e86a8c183284
Author: Tao Wang <kevin.wangtao@hisilicon.com>
Date:   Sat May 26 15:16:48 2018 +0800

    cpufreq: Fix new policy initialization during limits updates via sysfs
    
    commit c7d1f119c48f64bebf0fa1e326af577c6152fe30 upstream.
    
    If the policy limits are updated via cpufreq_update_policy() and
    subsequently via sysfs, the limits stored in user_policy may be
    set incorrectly.
    
    For example, if both min and max are set via sysfs to the maximum
    available frequency, user_policy.min and user_policy.max will also
    be the maximum.  If a policy notifier triggered by
    cpufreq_update_policy() lowers both the min and the max at this
    point, that change is not reflected by the user_policy limits, so
    if the max is updated again via sysfs to the same lower value,
    then user_policy.max will be lower than user_policy.min which
    shouldn't happen.  In particular, if one of the policy CPUs is
    then taken offline and back online, cpufreq_set_policy() will
    fail for it due to a failing limits check.
    
    To prevent that from happening, initialize the min and max fields
    of the new_policy object to the ones stored in user_policy that
    were previously set via sysfs.
    
    Signed-off-by: Kevin Wangtao <kevin.wangtao@hisilicon.com>
    Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
    [ rjw: Subject & changelog ]
    Cc: All applicable <stable@vger.kernel.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a6c9a62e0f9f0153ea5f0a2a8d4879b3bafe096a
Author: Steve French <stfrench@microsoft.com>
Date:   Thu May 31 15:19:25 2018 -0500

    smb3: on reconnect set PreviousSessionId field
    
    commit b2adf22fdfba85a6701c481faccdbbb3a418ccfc upstream.
    
    The server detects reconnect by the (non-zero) value in PreviousSessionId
    of SMB2/SMB3 SessionSetup request, but this behavior regressed due
    to commit 166cea4dc3a4f66f020cfb9286225ecd228ab61d
    ("SMB2: Separate RawNTLMSSP authentication from SMB2_sess_setup")
    
    CC: Stable <stable@vger.kernel.org>
    CC: Sachin Prabhu <sprabhu@redhat.com>
    Signed-off-by: Steve French <smfrench@gmail.com>
    Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2c6707ce9a0daba6609d87a714f866d4f1db8937
Author: Dennis Wassenberg <dennis.wassenberg@secunet.com>
Date:   Tue Jun 12 07:11:11 2018 +0200

    ALSA: hda: add dock and led support for HP ProBook 640 G4
    
    commit 7eef32c1ef895a3a96463f9cbd04203007cd5555 upstream.
    
    This patch adds missing initialisation for HP 2013 UltraSlim Dock
    Line-In/Out PINs and activates keyboard mute/micmute leds
    for HP ProBook 640 G4
    
    Signed-off-by: Dennis Wassenberg <dennis.wassenberg@secunet.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 594790ef9fb264a4294ceb04602762225a8eda63
Author: Dennis Wassenberg <dennis.wassenberg@secunet.com>
Date:   Tue Jun 12 07:10:59 2018 +0200

    ALSA: hda: add dock and led support for HP EliteBook 830 G5
    
    commit 2861751f67b91e1d24e68010ced96614fb3140f4 upstream.
    
    This patch adds missing initialisation for HP 2013 UltraSlim Dock
    Line-In/Out PINs and activates keyboard mute/micmute leds
    for HP EliteBook 830 G5
    
    Signed-off-by: Dennis Wassenberg <dennis.wassenberg@secunet.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5514389fb21c9d52c636411ce1cd5c5b83905434
Author: Bo Chen <chenbo@pdx.edu>
Date:   Thu May 31 15:35:18 2018 -0700

    ALSA: hda - Handle kzalloc() failure in snd_hda_attach_pcm_stream()
    
    commit a3aa60d511746bd6c0d0366d4eb90a7998bcde8b upstream.
    
    When 'kzalloc()' fails in 'snd_hda_attach_pcm_stream()', a new pcm instance is
    created without setting its operators via 'snd_pcm_set_ops()'. Following
    operations on the new pcm instance can trigger kernel null pointer dereferences
    and cause kernel oops.
    
    This bug was found with my work on building a gray-box fault-injection tool for
    linux-kernel-module binaries. A kernel null pointer dereference was confirmed
    from line 'substream->ops->open()' in function 'snd_pcm_open_substream()' in
    file 'sound/core/pcm_native.c'.
    
    This patch fixes the bug by calling 'snd_device_free()' in the error handling
    path of 'kzalloc()', which removes the new pcm instance from the snd card before
    returns with an error code.
    
    Signed-off-by: Bo Chen <chenbo@pdx.edu>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2102637c85a37f2420751a1cc817c01189a61970
Author: Qu Wenruo <wqu@suse.com>
Date:   Tue Jun 5 12:36:56 2018 +0800

    btrfs: scrub: Don't use inode pages for device replace
    
    commit ac0b4145d662a3b9e34085dea460fb06ede9b69b upstream.
    
    [BUG]
    Btrfs can create compressed extent without checksum (even though it
    shouldn't), and if we then try to replace device containing such extent,
    the result device will contain all the uncompressed data instead of the
    compressed one.
    
    Test case already submitted to fstests:
    https://patchwork.kernel.org/patch/10442353/
    
    [CAUSE]
    When handling compressed extent without checksum, device replace will
    goe into copy_nocow_pages() function.
    
    In that function, btrfs will get all inodes referring to this data
    extents and then use find_or_create_page() to get pages direct from that
    inode.
    
    The problem here is, pages directly from inode are always uncompressed.
    And for compressed data extent, they mismatch with on-disk data.
    Thus this leads to corrupted compressed data extent written to replace
    device.
    
    [FIX]
    In this attempt, we could just remove the "optimization" branch, and let
    unified scrub_pages() to handle it.
    
    Although scrub_pages() won't bother reusing page cache, it will be a
    little slower, but it does the correct csum checking and won't cause
    such data corruption caused by "optimization".
    
    Note about the fix: this is the minimal fix that can be backported to
    older stable trees without conflicts. The whole callchain from
    copy_nocow_pages() can be deleted, and will be in followup patches.
    
    Fixes: ff023aac3119 ("Btrfs: add code to scrub to copy read data to another disk")
    CC: stable@vger.kernel.org # 4.4+
    Reported-by: James Harvey <jamespharvey20@gmail.com>
    Reviewed-by: James Harvey <jamespharvey20@gmail.com>
    Signed-off-by: Qu Wenruo <wqu@suse.com>
    [ remove code removal, add note why ]
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9bb94d81206b4980f5c547c07dfdf7a912b73f7b
Author: Omar Sandoval <osandov@fb.com>
Date:   Tue May 22 15:44:01 2018 -0700

    Btrfs: fix memory and mount leak in btrfs_ioctl_rm_dev_v2()
    
    commit fd4e994bd1f9dc9628e168a7f619bf69f6984635 upstream.
    
    If we have invalid flags set, when we error out we must drop our writer
    counter and free the buffer we allocated for the arguments. This bug is
    trivially reproduced with the following program on 4.7+:
    
            #include <fcntl.h>
            #include <stdint.h>
            #include <stdio.h>
            #include <stdlib.h>
            #include <unistd.h>
            #include <sys/ioctl.h>
            #include <sys/stat.h>
            #include <sys/types.h>
            #include <linux/btrfs.h>
            #include <linux/btrfs_tree.h>
    
            int main(int argc, char **argv)
            {
                    struct btrfs_ioctl_vol_args_v2 vol_args = {
                            .flags = UINT64_MAX,
                    };
                    int ret;
                    int fd;
    
                    if (argc != 2) {
                            fprintf(stderr, "usage: %s PATH\n", argv[0]);
                            return EXIT_FAILURE;
                    }
    
                    fd = open(argv[1], O_WRONLY);
                    if (fd == -1) {
                            perror("open");
                            return EXIT_FAILURE;
                    }
    
                    ret = ioctl(fd, BTRFS_IOC_RM_DEV_V2, &vol_args);
                    if (ret == -1)
                            perror("ioctl");
    
                    close(fd);
                    return EXIT_SUCCESS;
            }
    
    When unmounting the filesystem, we'll hit the
    WARN_ON(mnt_get_writers(mnt)) in cleanup_mnt() and also may prevent the
    filesystem to be remounted read-only as the writer count will stay
    lifted.
    
    Fixes: 6b526ed70cf1 ("btrfs: introduce device delete by devid")
    CC: stable@vger.kernel.org # 4.9+
    Signed-off-by: Omar Sandoval <osandov@fb.com>
    Reviewed-by: Su Yue <suy.fnst@cn.fujitsu.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 52ea25b2b88587302a03b2ae8f2dd9b546337cc5
Author: Omar Sandoval <osandov@fb.com>
Date:   Tue May 22 15:02:12 2018 -0700

    Btrfs: fix clone vs chattr NODATASUM race
    
    commit b5c40d598f5408bd0ca22dfffa82f03cd9433f23 upstream.
    
    In btrfs_clone_files(), we must check the NODATASUM flag while the
    inodes are locked. Otherwise, it's possible that btrfs_ioctl_setflags()
    will change the flags after we check and we can end up with a party
    checksummed file.
    
    The race window is only a few instructions in size, between the if and
    the locks which is:
    
    3834         if (S_ISDIR(src->i_mode) || S_ISDIR(inode->i_mode))
    3835                 return -EISDIR;
    
    where the setflags must be run and toggle the NODATASUM flag (provided
    the file size is 0).  The clone will block on the inode lock, segflags
    takes the inode lock, changes flags, releases log and clone continues.
    
    Not impossible but still needs a lot of bad luck to hit unintentionally.
    
    Fixes: 0e7b824c4ef9 ("Btrfs: don't make a file partly checksummed through file clone")
    CC: stable@vger.kernel.org # 4.4+
    Signed-off-by: Omar Sandoval <osandov@fb.com>
    Reviewed-by: Nikolay Borisov <nborisov@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    [ update changelog ]
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4f65ebcffa53ae01ffded87f83d92fd0caaafc5d
Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date:   Mon May 7 19:10:31 2018 +0900

    driver core: Don't ignore class_dir_create_and_add() failure.
    
    commit 84d0c27d6233a9ba0578b20f5a09701eb66cee42 upstream.
    
    syzbot is hitting WARN() at kernfs_add_one() [1].
    This is because kernfs_create_link() is confused by previous device_add()
    call which continued without setting dev->kobj.parent field when
    get_device_parent() failed by memory allocation fault injection.
    Fix this by propagating the error from class_dir_create_and_add() to
    the calllers of get_device_parent().
    
    [1] https://syzkaller.appspot.com/bug?id=fae0fb607989ea744526d1c082a5b8de6529116f
    
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Reported-by: syzbot <syzbot+df47f81c226b31d89fb1@syzkaller.appspotmail.com>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e45ab2d6a89f9c31647efcb368a9c4378f2d76a9
Author: Jan Kara <jack@suse.cz>
Date:   Fri May 25 12:51:25 2018 -0400

    ext4: fix fencepost error in check for inode count overflow during resize
    
    commit 4f2f76f751433908364ccff82f437a57d0e6e9b7 upstream.
    
    ext4_resize_fs() has an off-by-one bug when checking whether growing of
    a filesystem will not overflow inode count. As a result it allows a
    filesystem with 8192 inodes per group to grow to 64TB which overflows
    inode count to 0 and makes filesystem unusable. Fix it.
    
    Cc: stable@vger.kernel.org
    Fixes: 3f8a6411fbada1fa482276591e037f3b1adcf55b
    Reported-by: Jaco Kroon <jaco@uls.co.za>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Reviewed-by: Andreas Dilger <adilger@dilger.ca>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ade6e140df5c380dbb95605534e400fe27dbc5c0
Author: Lukas Czerner <lczerner@redhat.com>
Date:   Sun May 13 19:28:35 2018 -0400

    ext4: update mtime in ext4_punch_hole even if no blocks are released
    
    commit eee597ac931305eff3d3fd1d61d6aae553bc0984 upstream.
    
    Currently in ext4_punch_hole we're going to skip the mtime update if
    there are no actual blocks to release. However we've actually modified
    the file by zeroing the partial block so the mtime should be updated.
    
    Moreover the sync and datasync handling is skipped as well, which is
    also wrong. Fix it.
    
    Signed-off-by: Lukas Czerner <lczerner@redhat.com>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Reported-by: Joe Habermann <joe.habermann@quantum.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 42cc42eabafb6bd4e5ea4cbde72f7fb4d24cc7bd
Author: Jan Kara <jack@suse.cz>
Date:   Sat May 12 19:55:00 2018 -0400

    ext4: fix hole length detection in ext4_ind_map_blocks()
    
    commit 2ee3ee06a8fd792765fa3267ddf928997797eec5 upstream.
    
    When ext4_ind_map_blocks() computes a length of a hole, it doesn't count
    with the fact that mapped offset may be somewhere in the middle of the
    completely empty subtree. In such case it will return too large length
    of the hole which then results in lseek(SEEK_DATA) to end up returning
    an incorrect offset beyond the end of the hole.
    
    Fix the problem by correctly taking offset within a subtree into account
    when computing a length of a hole.
    
    Fixes: facab4d9711e7aa3532cb82643803e8f1b9518e8
    CC: stable@vger.kernel.org
    Reported-by: Jeff Mahoney <jeffm@suse.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2435d6b11057c8b02d6a8932501cb980c23e2d05
Author: Kailang Yang <kailang@realtek.com>
Date:   Tue Dec 5 15:38:24 2017 +0800

    ALSA: hda/realtek - New codec support for ALC257
    
    commit f429e7e494afaded76e62c6f98211a635aa03098 upstream.
    
    Add new support for ALC257 codec.
    
    [ It's supposed to be almost equivalent with other ALC25x variants,
      just adding another type and id -- tiwai ]
    
    Signed-off-by: Kailang Yang <kailang@realtek.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Tested-by: Pali Rohár <pali.rohar@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6caca347e4b007a645aa6b8bb950fa27b5e221d5
Author: Frank van der Linden <fllinden@amazon.com>
Date:   Tue Jun 12 23:09:37 2018 +0000

    tcp: verify the checksum of the first data segment in a new connection
    
    [ Upstream commit 4fd44a98ffe0d048246efef67ed640fdf2098a62 ]
    
    commit 079096f103fa ("tcp/dccp: install syn_recv requests into ehash
    table") introduced an optimization for the handling of child sockets
    created for a new TCP connection.
    
    But this optimization passes any data associated with the last ACK of the
    connection handshake up the stack without verifying its checksum, because it
    calls tcp_child_process(), which in turn calls tcp_rcv_state_process()
    directly.  These lower-level processing functions do not do any checksum
    verification.
    
    Insert a tcp_checksum_complete call in the TCP_NEW_SYN_RECEIVE path to
    fix this.
    
    Fixes: 079096f103fa ("tcp/dccp: install syn_recv requests into ehash table")
    Signed-off-by: Frank van der Linden <fllinden@amazon.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Tested-by: Balbir Singh <bsingharora@gmail.com>
    Reviewed-by: Balbir Singh <bsingharora@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2d34743a2c90361efc91ce626eda2af91f96727d
Author: Davide Caratti <dcaratti@redhat.com>
Date:   Fri Jun 8 05:02:31 2018 +0200

    net/sched: act_simple: fix parsing of TCA_DEF_DATA
    
    [ Upstream commit 8d499533e0bc02d44283dbdab03142b599b8ba16 ]
    
    use nla_strlcpy() to avoid copying data beyond the length of TCA_DEF_DATA
    netlink attribute, in case it is less than SIMP_MAX_DATA and it does not
    end with '\0' character.
    
    v2: fix errors in the commit message, thanks Hangbin Liu
    
    Fixes: fa1b1cff3d06 ("net_cls_act: Make act_simple use of netlink policy.")
    Signed-off-by: Davide Caratti <dcaratti@redhat.com>
    Reviewed-by: Simon Horman <simon.horman@netronome.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c66919125757e2d336de0ac467f8358aca0c1c5b
Author: Julian Anastasov <ja@ssi.bg>
Date:   Mon Jun 11 02:02:54 2018 +0300

    ipv6: allow PMTU exceptions to local routes
    
    [ Upstream commit 0975764684487bf3f7a47eef009e750ea41bd514 ]
    
    IPVS setups with local client and remote tunnel server need
    to create exception for the local virtual IP. What we do is to
    change PMTU from 64KB (on "lo") to 1460 in the common case.
    
    Suggested-by: Martin KaFai Lau <kafai@fb.com>
    Fixes: 45e4fd26683c ("ipv6: Only create RTF_CACHE routes after encountering pmtu exception")
    Fixes: 7343ff31ebf0 ("ipv6: Don't create clones of host routes.")
    Signed-off-by: Julian Anastasov <ja@ssi.bg>
    Acked-by: David Ahern <dsahern@gmail.com>
    Acked-by: Martin KaFai Lau <kafai@fb.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 780617b249e469750a49d38d0cdc845ba7398ea1
Author: Xiangning Yu <yuxiangning@gmail.com>
Date:   Thu Jun 7 13:39:59 2018 +0800

    bonding: re-evaluate force_primary when the primary slave name changes
    
    [ Upstream commit eb55bbf865d9979098c6a7a17cbdb41237ece951 ]
    
    There is a timing issue under active-standy mode, when bond_enslave() is
    called, bond->params.primary might not be initialized yet.
    
    Any time the primary slave string changes, bond->force_primary should be
    set to true to make sure the primary becomes the active slave.
    
    Signed-off-by: Xiangning Yu <yuxiangning@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c4f24a093f02bc43a602c08550d828ce34477380
Author: Daniel Glöckner <dg@emlix.com>
Date:   Mon May 14 09:40:05 2018 -0500

    usb: musb: fix remote wakeup racing with suspend
    
    [ Upstream commit ebc3dd688cd988754a304147753b13e58de1b5a1 ]
    
    It has been observed that writing 0xF2 to the power register while it
    reads as 0xF4 results in the register having the value 0xF0, i.e. clearing
    RESUME and setting SUSPENDM in one go does not work. It might also violate
    the USB spec to transition directly from resume to suspend, especially
    when not taking T_DRSMDN into account. But this is what happens when a
    remote wakeup occurs between SetPortFeature USB_PORT_FEAT_SUSPEND on the
    root hub and musb_bus_suspend being called.
    
    This commit returns -EBUSY when musb_bus_suspend is called while remote
    wakeup is signalled and thus avoids to reset the RESUME bit. Ignoring
    this error when musb_port_suspend is called from musb_hub_control is ok.
    
    Signed-off-by: Daniel Glöckner <dg@emlix.com>
    Signed-off-by: Bin Liu <b-liu@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 42ff36e9cb95662ff8a0a0ac1aea54f386068fa4
Author: Liu Bo <bo.li.liu@oracle.com>
Date:   Fri Jun 15 02:39:14 2018 +0000

    Btrfs: make raid6 rebuild retry more
    
    [ Upstream commit 8810f7517a3bc4ca2d41d022446d3f5fd6b77c09 ]
    
    There is a scenario that can end up with rebuild process failing to
    return good content, i.e.
    suppose that all disks can be read without problems and if the content
    that was read out doesn't match its checksum, currently for raid6
    btrfs at most retries twice,
    
    - the 1st retry is to rebuild with all other stripes, it'll eventually
      be a raid5 xor rebuild,
    - if the 1st fails, the 2nd retry will deliberately fail parity p so
      that it will do raid6 style rebuild,
    
    however, the chances are that another non-parity stripe content also
    has something corrupted, so that the above retries are not able to
    return correct content, and users will think of this as data loss.
    More seriouly, if the loss happens on some important internal btree
    roots, it could refuse to mount.
    
    This extends btrfs to do more retries and each retry fails only one
    stripe.  Since raid6 can tolerate 2 disk failures, if there is one
    more failure besides the failure on which we're recovering, this can
    always work.
    
    The worst case is to retry as many times as the number of raid6 disks,
    but given the fact that such a scenario is really rare in practice,
    it's still acceptable.
    
    Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4e43b6a8b40fcb4a1773857f4610796cf4aa207c
Author: Eric Dumazet <edumazet@google.com>
Date:   Sun Dec 10 17:55:02 2017 -0800

    tcp: do not overshoot window_clamp in tcp_rcv_space_adjust()
    
    commit 02db55718d53f9d426cee504c27fb768e9ed4ffe upstream.
    
    While rcvbuf is properly clamped by tcp_rmem[2], rcvwin
    is left to a potentially too big value.
    
    It has no serious effect, since :
    1) tcp_grow_window() has very strict checks.
    2) window_clamp can be mangled by user space to any value anyway.
    
    tcp_init_buffer_space() and companions use tcp_full_space(),
    we use tcp_win_from_space() to avoid reloading sk->sk_rcvbuf
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
    Acked-by: Wei Wang <weiwan@google.com>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Cc: Benjamin Gilbert <benjamin.gilbert@coreos.com>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1fab25ce8db367f0d6a22baba96bbe49e68ba5c7
Author: Sasha Levin <Alexander.Levin@microsoft.com>
Date:   Fri Jun 15 02:39:13 2018 +0000

    Revert "Btrfs: fix scrub to repair raid6 corruption"
    
    This reverts commit 186a6519dc94964a4c5c68fca482f20f71551f26.
    
    This commit used an incorrect log message.
    
    Reported-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 60649dacb3da3a757a99c9a7e6dd42867e1eb825
Author: Damien Thébault <damien.thebault@vitec.com>
Date:   Thu May 31 07:04:01 2018 +0000

    net: dsa: b53: Add BCM5389 support
    
    [ Upstream commit a95691bc54af1ac4b12c354f91e9cabf1cb068df ]
    
    This patch adds support for the BCM5389 switch connected through MDIO.
    
    Signed-off-by: Damien Thébault <damien.thebault@vitec.com>
    Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1249ccd806e04a4029d1f3b37143131bfe4850ec
Author: Finn Thain <fthain@telegraphics.com.au>
Date:   Wed May 30 13:03:51 2018 +1000

    net/sonic: Use dma_mapping_error()
    
    [ Upstream commit 26de0b76d9ba3200f09c6cb9d9618bda338be5f7 ]
    
    With CONFIG_DMA_API_DEBUG=y, calling sonic_open() produces the
    message, "DMA-API: device driver failed to check map error".
    Add the missing dma_mapping_error() call.
    
    Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
    Acked-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2fe56703ee8463b0922734a1c94a475790de40aa
Author: João Paulo Rechi Vita <jprvita@gmail.com>
Date:   Tue May 22 14:30:15 2018 -0700

    platform/x86: asus-wmi: Fix NULL pointer dereference
    
    [ Upstream commit 32ffd6e8d1f6cef94bedca15dfcdebdeb590499d ]
    
    Do not perform the rfkill cleanup routine when
    (asus->driver->wlan_ctrl_by_user && ashs_present()) is true, since
    nothing is registered with the rfkill subsystem in that case. Doing so
    leads to the following kernel NULL pointer dereference:
    
      BUG: unable to handle kernel NULL pointer dereference at           (null)
      IP: [<ffffffff816c7348>] __mutex_lock_slowpath+0x98/0x120
      PGD 1a3aa8067
      PUD 1a3b3d067
      PMD 0
    
      Oops: 0002 [#1] PREEMPT SMP
      Modules linked in: bnep ccm binfmt_misc uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core hid_a4tech videodev x86_pkg_temp_thermal intel_powerclamp coretemp ath3k btusb btrtl btintel bluetooth kvm_intel snd_hda_codec_hdmi kvm snd_hda_codec_realtek snd_hda_codec_generic irqbypass crc32c_intel arc4 i915 snd_hda_intel snd_hda_codec ath9k ath9k_common ath9k_hw ath i2c_algo_bit snd_hwdep mac80211 ghash_clmulni_intel snd_hda_core snd_pcm snd_timer cfg80211 ehci_pci xhci_pci drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm xhci_hcd ehci_hcd asus_nb_wmi(-) asus_wmi sparse_keymap r8169 rfkill mxm_wmi serio_raw snd mii mei_me lpc_ich i2c_i801 video soundcore mei i2c_smbus wmi i2c_core mfd_core
      CPU: 3 PID: 3275 Comm: modprobe Not tainted 4.9.34-gentoo #34
      Hardware name: ASUSTeK COMPUTER INC. K56CM/K56CM, BIOS K56CM.206 08/21/2012
      task: ffff8801a639ba00 task.stack: ffffc900014cc000
      RIP: 0010:[<ffffffff816c7348>]  [<ffffffff816c7348>] __mutex_lock_slowpath+0x98/0x120
      RSP: 0018:ffffc900014cfce0  EFLAGS: 00010282
      RAX: 0000000000000000 RBX: ffff8801a54315b0 RCX: 00000000c0000100
      RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff8801a54315b4
      RBP: ffffc900014cfd30 R08: 0000000000000000 R09: 0000000000000002
      R10: 0000000000000000 R11: 0000000000000000 R12: ffff8801a54315b4
      R13: ffff8801a639ba00 R14: 00000000ffffffff R15: ffff8801a54315b8
      FS:  00007faa254fb700(0000) GS:ffff8801aef80000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000000000 CR3: 00000001a3b1b000 CR4: 00000000001406e0
      Stack:
       ffff8801a54315b8 0000000000000000 ffffffff814733ae ffffc900014cfd28
       ffffffff8146a28c ffff8801a54315b0 0000000000000000 ffff8801a54315b0
       ffff8801a66f3820 0000000000000000 ffffc900014cfd48 ffffffff816c73e7
      Call Trace:
       [<ffffffff814733ae>] ? acpi_ut_release_mutex+0x5d/0x61
       [<ffffffff8146a28c>] ? acpi_ns_get_node+0x49/0x52
       [<ffffffff816c73e7>] mutex_lock+0x17/0x30
       [<ffffffffa00a3bb4>] asus_rfkill_hotplug+0x24/0x1a0 [asus_wmi]
       [<ffffffffa00a4421>] asus_wmi_rfkill_exit+0x61/0x150 [asus_wmi]
       [<ffffffffa00a49f1>] asus_wmi_remove+0x61/0xb0 [asus_wmi]
       [<ffffffff814a5128>] platform_drv_remove+0x28/0x40
       [<ffffffff814a2901>] __device_release_driver+0xa1/0x160
       [<ffffffff814a29e3>] device_release_driver+0x23/0x30
       [<ffffffff814a1ffd>] bus_remove_device+0xfd/0x170
       [<ffffffff8149e5a9>] device_del+0x139/0x270
       [<ffffffff814a5028>] platform_device_del+0x28/0x90
       [<ffffffff814a50a2>] platform_device_unregister+0x12/0x30
       [<ffffffffa00a4209>] asus_wmi_unregister_driver+0x19/0x30 [asus_wmi]
       [<ffffffffa00da0ea>] asus_nb_wmi_exit+0x10/0xf26 [asus_nb_wmi]
       [<ffffffff8110c692>] SyS_delete_module+0x192/0x270
       [<ffffffff810022b2>] ? exit_to_usermode_loop+0x92/0xa0
       [<ffffffff816ca560>] entry_SYSCALL_64_fastpath+0x13/0x94
      Code: e8 5e 30 00 00 8b 03 83 f8 01 0f 84 93 00 00 00 48 8b 43 10 4c 8d 7b 08 48 89 63 10 41 be ff ff ff ff 4c 89 3c 24 48 89 44 24 08 <48> 89 20 4c 89 6c 24 10 eb 1d 4c 89 e7 49 c7 45 08 02 00 00 00
      RIP  [<ffffffff816c7348>] __mutex_lock_slowpath+0x98/0x120
       RSP <ffffc900014cfce0>
      CR2: 0000000000000000
      ---[ end trace 8d484233fa7cb512 ]---
      note: modprobe[3275] exited with preempt_count 2
    
    https://bugzilla.kernel.org/show_bug.cgi?id=196467
    
    Reported-by: red.f0xyz@gmail.com
    Signed-off-by: João Paulo Rechi Vita <jprvita@endlessm.com>
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit baa3a68614a24bd3e92ad87b6ac31c0a135d342f
Author: Josh Hill <josh@joshuajhill.com>
Date:   Sun May 27 20:10:41 2018 -0400

    net: qmi_wwan: Add Netgear Aircard 779S
    
    [ Upstream commit 2415f3bd059fe050eb98aedf93664d000ceb4e92 ]
    
    Add support for Netgear Aircard 779S
    
    Signed-off-by: Josh Hill <josh@joshuajhill.com>
    Acked-by: Bjørn Mork <bjorn@mork.no>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5dbffe420164137f8b6b733de3d801019d777fa4
Author: Ivan Bornyakov <brnkv.i1@gmail.com>
Date:   Fri May 25 20:49:52 2018 +0300

    atm: zatm: fix memcmp casting
    
    [ Upstream commit f9c6442a8f0b1dde9e755eb4ff6fa22bcce4eabc ]
    
    memcmp() returns int, but eprom_try_esi() cast it to unsigned char. One
    can lose significant bits and get 0 from non-0 value returned by the
    memcmp().
    
    Signed-off-by: Ivan Bornyakov <brnkv.i1@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 46bada0a9367ad54eda95669bec8efc078ecce51
Author: Hao Wei Tee <angelsl@in04.sg>
Date:   Tue May 29 10:25:17 2018 +0300

    iwlwifi: pcie: compare with number of IRQs requested for, not number of CPUs
    
    [ Upstream commit ab1068d6866e28bf6427ceaea681a381e5870a4a ]
    
    When there are 16 or more logical CPUs, we request for
    `IWL_MAX_RX_HW_QUEUES` (16) IRQs only as we limit to that number of
    IRQs, but later on we compare the number of IRQs returned to
    nr_online_cpus+2 instead of max_irqs, the latter being what we
    actually asked for. This ends up setting num_rx_queues to 17 which
    causes lots of out-of-bounds array accesses later on.
    
    Compare to max_irqs instead, and also add an assertion in case
    num_rx_queues > IWM_MAX_RX_HW_QUEUES.
    
    This fixes https://bugzilla.kernel.org/show_bug.cgi?id=199551
    
    Fixes: 2e5d4a8f61dc ("iwlwifi: pcie: Add new configuration to enable MSIX")
    Signed-off-by: Hao Wei Tee <angelsl@in04.sg>
    Tested-by: Sara Sharon <sara.sharon@intel.com>
    Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0063faaa86ddd392c7e870da911d1065a25be423
Author: Julian Anastasov <ja@ssi.bg>
Date:   Sat May 19 18:22:35 2018 +0300

    ipvs: fix buffer overflow with sync daemon and service
    
    [ Upstream commit 52f96757905bbf0edef47f3ee6c7c784e7f8ff8a ]
    
    syzkaller reports for buffer overflow for interface name
    when starting sync daemons [1]
    
    What we do is that we copy user structure into larger stack
    buffer but later we search NUL past the stack buffer.
    The same happens for sched_name when adding/editing virtual server.
    
    We are restricted by IP_VS_SCHEDNAME_MAXLEN and IP_VS_IFNAME_MAXLEN
    being used as size in include/uapi/linux/ip_vs.h, so they
    include the space for NUL.
    
    As using strlcpy is wrong for unsafe source, replace it with
    strscpy and add checks to return EINVAL if source string is not
    NUL-terminated. The incomplete strlcpy fix comes from 2.6.13.
    
    For the netlink interface reduce the len parameter for
    IPVS_DAEMON_ATTR_MCAST_IFN and IPVS_SVC_ATTR_SCHED_NAME,
    so that we get proper EINVAL.
    
    [1]
    kernel BUG at lib/string.c:1052!
    invalid opcode: 0000 [#1] SMP KASAN
    Dumping ftrace buffer:
        (ftrace buffer empty)
    Modules linked in:
    CPU: 1 PID: 373 Comm: syz-executor936 Not tainted 4.17.0-rc4+ #45
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
    Google 01/01/2011
    RIP: 0010:fortify_panic+0x13/0x20 lib/string.c:1051
    RSP: 0018:ffff8801c976f800 EFLAGS: 00010282
    RAX: 0000000000000022 RBX: 0000000000000040 RCX: 0000000000000000
    RDX: 0000000000000022 RSI: ffffffff8160f6f1 RDI: ffffed00392edef6
    RBP: ffff8801c976f800 R08: ffff8801cf4c62c0 R09: ffffed003b5e4fb0
    R10: ffffed003b5e4fb0 R11: ffff8801daf27d87 R12: ffff8801c976fa20
    R13: ffff8801c976fae4 R14: ffff8801c976fae0 R15: 000000000000048b
    FS:  00007fd99f75e700(0000) GS:ffff8801daf00000(0000)
    knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00000000200001c0 CR3: 00000001d6843000 CR4: 00000000001406e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
      strlen include/linux/string.h:270 [inline]
      strlcpy include/linux/string.h:293 [inline]
      do_ip_vs_set_ctl+0x31c/0x1d00 net/netfilter/ipvs/ip_vs_ctl.c:2388
      nf_sockopt net/netfilter/nf_sockopt.c:106 [inline]
      nf_setsockopt+0x7d/0xd0 net/netfilter/nf_sockopt.c:115
      ip_setsockopt+0xd8/0xf0 net/ipv4/ip_sockglue.c:1253
      udp_setsockopt+0x62/0xa0 net/ipv4/udp.c:2487
      ipv6_setsockopt+0x149/0x170 net/ipv6/ipv6_sockglue.c:917
      tcp_setsockopt+0x93/0xe0 net/ipv4/tcp.c:3057
      sock_common_setsockopt+0x9a/0xe0 net/core/sock.c:3046
      __sys_setsockopt+0x1bd/0x390 net/socket.c:1903
      __do_sys_setsockopt net/socket.c:1914 [inline]
      __se_sys_setsockopt net/socket.c:1911 [inline]
      __x64_sys_setsockopt+0xbe/0x150 net/socket.c:1911
      do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
      entry_SYSCALL_64_after_hwframe+0x49/0xbe
    RIP: 0033:0x447369
    RSP: 002b:00007fd99f75dda8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
    RAX: ffffffffffffffda RBX: 00000000006e39e4 RCX: 0000000000447369
    RDX: 000000000000048b RSI: 0000000000000000 RDI: 0000000000000003
    RBP: 0000000000000000 R08: 0000000000000018 R09: 0000000000000000
    R10: 00000000200001c0 R11: 0000000000000246 R12: 00000000006e39e0
    R13: 75a1ff93f0896195 R14: 6f745f3168746576 R15: 0000000000000001
    Code: 08 5b 41 5c 41 5d 41 5e 41 5f 5d c3 0f 0b 48 89 df e8 d2 8f 48 fa eb
    de 55 48 89 fe 48 c7 c7 60 65 64 88 48 89 e5 e8 91 dd f3 f9 <0f> 0b 90 90
    90 90 90 90 90 90 90 90 90 55 48 89 e5 41 57 41 56
    RIP: fortify_panic+0x13/0x20 lib/string.c:1051 RSP: ffff8801c976f800
    
    Reported-and-tested-by: syzbot+aac887f77319868646df@syzkaller.appspotmail.com
    Fixes: e4ff67513096 ("ipvs: add sync_maxlen parameter for the sync daemon")
    Fixes: 4da62fc70d7c ("[IPVS]: Fix for overflows")
    Signed-off-by: Julian Anastasov <ja@ssi.bg>
    Acked-by: Simon Horman <horms+renesas@verge.net.au>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8268afc568de4f84e2ea29640ea7229b32b47639
Author: Paolo Abeni <pabeni@redhat.com>
Date:   Fri Apr 27 10:45:31 2018 +0200

    netfilter: ebtables: handle string from userspace with care
    
    [ Upstream commit 94c752f99954797da583a84c4907ff19e92550a4 ]
    
    strlcpy() can't be safely used on a user-space provided string,
    as it can try to read beyond the buffer's end, if the latter is
    not NULL terminated.
    
    Leveraging the above, syzbot has been able to trigger the following
    splat:
    
    BUG: KASAN: stack-out-of-bounds in strlcpy include/linux/string.h:300
    [inline]
    BUG: KASAN: stack-out-of-bounds in compat_mtw_from_user
    net/bridge/netfilter/ebtables.c:1957 [inline]
    BUG: KASAN: stack-out-of-bounds in ebt_size_mwt
    net/bridge/netfilter/ebtables.c:2059 [inline]
    BUG: KASAN: stack-out-of-bounds in size_entry_mwt
    net/bridge/netfilter/ebtables.c:2155 [inline]
    BUG: KASAN: stack-out-of-bounds in compat_copy_entries+0x96c/0x14a0
    net/bridge/netfilter/ebtables.c:2194
    Write of size 33 at addr ffff8801b0abf888 by task syz-executor0/4504
    
    CPU: 0 PID: 4504 Comm: syz-executor0 Not tainted 4.17.0-rc2+ #40
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
    Google 01/01/2011
    Call Trace:
      __dump_stack lib/dump_stack.c:77 [inline]
      dump_stack+0x1b9/0x294 lib/dump_stack.c:113
      print_address_description+0x6c/0x20b mm/kasan/report.c:256
      kasan_report_error mm/kasan/report.c:354 [inline]
      kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
      check_memory_region_inline mm/kasan/kasan.c:260 [inline]
      check_memory_region+0x13e/0x1b0 mm/kasan/kasan.c:267
      memcpy+0x37/0x50 mm/kasan/kasan.c:303
      strlcpy include/linux/string.h:300 [inline]
      compat_mtw_from_user net/bridge/netfilter/ebtables.c:1957 [inline]
      ebt_size_mwt net/bridge/netfilter/ebtables.c:2059 [inline]
      size_entry_mwt net/bridge/netfilter/ebtables.c:2155 [inline]
      compat_copy_entries+0x96c/0x14a0 net/bridge/netfilter/ebtables.c:2194
      compat_do_replace+0x483/0x900 net/bridge/netfilter/ebtables.c:2285
      compat_do_ebt_set_ctl+0x2ac/0x324 net/bridge/netfilter/ebtables.c:2367
      compat_nf_sockopt net/netfilter/nf_sockopt.c:144 [inline]
      compat_nf_setsockopt+0x9b/0x140 net/netfilter/nf_sockopt.c:156
      compat_ip_setsockopt+0xff/0x140 net/ipv4/ip_sockglue.c:1279
      inet_csk_compat_setsockopt+0x97/0x120 net/ipv4/inet_connection_sock.c:1041
      compat_tcp_setsockopt+0x49/0x80 net/ipv4/tcp.c:2901
      compat_sock_common_setsockopt+0xb4/0x150 net/core/sock.c:3050
      __compat_sys_setsockopt+0x1ab/0x7c0 net/compat.c:403
      __do_compat_sys_setsockopt net/compat.c:416 [inline]
      __se_compat_sys_setsockopt net/compat.c:413 [inline]
      __ia32_compat_sys_setsockopt+0xbd/0x150 net/compat.c:413
      do_syscall_32_irqs_on arch/x86/entry/common.c:323 [inline]
      do_fast_syscall_32+0x345/0xf9b arch/x86/entry/common.c:394
      entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139
    RIP: 0023:0xf7fb3cb9
    RSP: 002b:00000000fff0c26c EFLAGS: 00000282 ORIG_RAX: 000000000000016e
    RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000000000
    RDX: 0000000000000080 RSI: 0000000020000300 RDI: 00000000000005f4
    RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
    R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
    
    The buggy address belongs to the page:
    page:ffffea0006c2afc0 count:0 mapcount:0 mapping:0000000000000000 index:0x0
    flags: 0x2fffc0000000000()
    raw: 02fffc0000000000 0000000000000000 0000000000000000 00000000ffffffff
    raw: 0000000000000000 ffffea0006c20101 0000000000000000 0000000000000000
    page dumped because: kasan: bad access detected
    
    Fix the issue replacing the unsafe function with strscpy() and
    taking care of possible errors.
    
    Fixes: 81e675c227ec ("netfilter: ebtables: add CONFIG_COMPAT support")
    Reported-and-tested-by: syzbot+4e42a04e0bc33cb6c087@syzkaller.appspotmail.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c8197f96bcbe89bb108c0741ce5864bb7734486e
Author: Eric Dumazet <edumazet@google.com>
Date:   Sat May 12 02:49:30 2018 -0700

    xfrm6: avoid potential infinite loop in _decode_session6()
    
    [ Upstream commit d9f92772e8ec388d070752ee8f187ef8fa18621f ]
    
    syzbot found a way to trigger an infinitie loop by overflowing
    @offset variable that has been forced to use u16 for some very
    obscure reason in the past.
    
    We probably want to look at NEXTHDR_FRAGMENT handling which looks
    wrong, in a separate patch.
    
    In net-next, we shall try to use skb_header_pointer() instead of
    pskb_may_pull().
    
    watchdog: BUG: soft lockup - CPU#1 stuck for 134s! [syz-executor738:4553]
    Modules linked in:
    irq event stamp: 13885653
    hardirqs last  enabled at (13885652): [<ffffffff878009d5>] restore_regs_and_return_to_kernel+0x0/0x2b
    hardirqs last disabled at (13885653): [<ffffffff87800905>] interrupt_entry+0xb5/0xf0 arch/x86/entry/entry_64.S:625
    softirqs last  enabled at (13614028): [<ffffffff84df0809>] tun_napi_alloc_frags drivers/net/tun.c:1478 [inline]
    softirqs last  enabled at (13614028): [<ffffffff84df0809>] tun_get_user+0x1dd9/0x4290 drivers/net/tun.c:1825
    softirqs last disabled at (13614032): [<ffffffff84df1b6f>] tun_get_user+0x313f/0x4290 drivers/net/tun.c:1942
    CPU: 1 PID: 4553 Comm: syz-executor738 Not tainted 4.17.0-rc3+ #40
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    RIP: 0010:check_kcov_mode kernel/kcov.c:67 [inline]
    RIP: 0010:__sanitizer_cov_trace_pc+0x20/0x50 kernel/kcov.c:101
    RSP: 0018:ffff8801d8cfe250 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13
    RAX: ffff8801d88a8080 RBX: ffff8801d7389e40 RCX: 0000000000000006
    RDX: 0000000000000000 RSI: ffffffff868da4ad RDI: ffff8801c8a53277
    RBP: ffff8801d8cfe250 R08: ffff8801d88a8080 R09: ffff8801d8cfe3e8
    R10: ffffed003b19fc87 R11: ffff8801d8cfe43f R12: ffff8801c8a5327f
    R13: 0000000000000000 R14: ffff8801c8a4e5fe R15: ffff8801d8cfe3e8
    FS:  0000000000d88940(0000) GS:ffff8801daf00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: ffffffffff600400 CR3: 00000001acab3000 CR4: 00000000001406e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     _decode_session6+0xc1d/0x14f0 net/ipv6/xfrm6_policy.c:150
     __xfrm_decode_session+0x71/0x140 net/xfrm/xfrm_policy.c:2368
     xfrm_decode_session_reverse include/net/xfrm.h:1213 [inline]
     icmpv6_route_lookup+0x395/0x6e0 net/ipv6/icmp.c:372
     icmp6_send+0x1982/0x2da0 net/ipv6/icmp.c:551
     icmpv6_send+0x17a/0x300 net/ipv6/ip6_icmp.c:43
     ip6_input_finish+0x14e1/0x1a30 net/ipv6/ip6_input.c:305
     NF_HOOK include/linux/netfilter.h:288 [inline]
     ip6_input+0xe1/0x5e0 net/ipv6/ip6_input.c:327
     dst_input include/net/dst.h:450 [inline]
     ip6_rcv_finish+0x29c/0xa10 net/ipv6/ip6_input.c:71
     NF_HOOK include/linux/netfilter.h:288 [inline]
     ipv6_rcv+0xeb8/0x2040 net/ipv6/ip6_input.c:208
     __netif_receive_skb_core+0x2468/0x3650 net/core/dev.c:4646
     __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:4711
     netif_receive_skb_internal+0x126/0x7b0 net/core/dev.c:4785
     napi_frags_finish net/core/dev.c:5226 [inline]
     napi_gro_frags+0x631/0xc40 net/core/dev.c:5299
     tun_get_user+0x3168/0x4290 drivers/net/tun.c:1951
     tun_chr_write_iter+0xb9/0x154 drivers/net/tun.c:1996
     call_write_iter include/linux/fs.h:1784 [inline]
     do_iter_readv_writev+0x859/0xa50 fs/read_write.c:680
     do_iter_write+0x185/0x5f0 fs/read_write.c:959
     vfs_writev+0x1c7/0x330 fs/read_write.c:1004
     do_writev+0x112/0x2f0 fs/read_write.c:1039
     __do_sys_writev fs/read_write.c:1112 [inline]
     __se_sys_writev fs/read_write.c:1109 [inline]
     __x64_sys_writev+0x75/0xb0 fs/read_write.c:1109
     do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
     entry_SYSCALL_64_after_hwframe+0x49/0xbe
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Steffen Klassert <steffen.klassert@secunet.com>
    Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Reported-by: syzbot+0053c8...@syzkaller.appspotmail.com
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ccd19d3a38032cdc0f83006f95236b6dfb06a951
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat Jun 16 11:27:56 2018 +0200

    objtool: update .gitignore file
    
    With the recent sync with objtool from 4.14.y, the objtool .gitignore
    file was forgotten.  Fix that up now to properly handle the change in
    where the autogenerated files live.
    
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>