commit 702c0ce9a7c7ad1b22883aa82d8c29eaa6e65aab
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Feb 14 15:23:09 2017 -0800

    Linux 4.4.49

commit 5b0465dd4ad41705e55fdc2dbe0c8c1e9f88e656
Author: Andrey Ryabinin <aryabinin@virtuozzo.com>
Date:   Thu Jan 26 17:32:11 2017 +0300

    drm/i915: fix use-after-free in page_flip_completed()
    
    commit 5351fbb1bf1413f6024892093528280769ca852f upstream.
    
    page_flip_completed() dereferences 'work' variable after executing
    queue_work(). This is not safe as the 'work' item might be already freed
    by queued work:
    
        BUG: KASAN: use-after-free in page_flip_completed+0x3ff/0x490 at addr ffff8803dc010f90
        Call Trace:
         __asan_report_load8_noabort+0x59/0x80
         page_flip_completed+0x3ff/0x490
         intel_finish_page_flip_mmio+0xe3/0x130
         intel_pipe_handle_vblank+0x2d/0x40
         gen8_irq_handler+0x4a7/0xed0
         __handle_irq_event_percpu+0xf6/0x860
         handle_irq_event_percpu+0x6b/0x160
         handle_irq_event+0xc7/0x1b0
         handle_edge_irq+0x1f4/0xa50
         handle_irq+0x41/0x70
         do_IRQ+0x9a/0x200
         common_interrupt+0x89/0x89
    
        Freed:
         kfree+0x113/0x4d0
         intel_unpin_work_fn+0x29a/0x3b0
         process_one_work+0x79e/0x1b70
         worker_thread+0x611/0x1460
         kthread+0x241/0x3a0
         ret_from_fork+0x27/0x40
    
    Move queue_work() after trace_i915_flip_complete() to fix this.
    
    Fixes: e5510fac98a7 ("drm/i915: add tracepoints for flip requests & completions")
    Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Link: http://patchwork.freedesktop.org/patch/msgid/20170126143211.24013-1-aryabinin@virtuozzo.com
    (cherry picked from commit 05c41f926fcc7ef838c80a6a99d84f67b4e0b824)
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a44ca389a7363b2160b2dd9b81f0175eab78e858
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Feb 6 15:09:48 2017 +0100

    ALSA: seq: Don't handle loop timeout at snd_seq_pool_done()
    
    commit 37a7ea4a9b81f6a864c10a7cb0b96458df5310a3 upstream.
    
    snd_seq_pool_done() syncs with closing of all opened threads, but it
    aborts the wait loop with a timeout, and proceeds to the release
    resource even if not all threads have been closed.  The timeout was 5
    seconds, and if you run a crazy stuff, it can exceed easily, and may
    result in the access of the invalid memory address -- this is what
    syzkaller detected in a bug report.
    
    As a fix, let the code graduate from naiveness, simply remove the loop
    timeout.
    
    BugLink: http://lkml.kernel.org/r/CACT4Y+YdhDV2H5LLzDTJDVF-qiYHUHhtRaW4rbb4gUhTCQB81w@mail.gmail.com
    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e5f20a3fd6dbdc3db409aa786899e60754562e1a
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Feb 8 12:35:39 2017 +0100

    ALSA: seq: Fix race at creating a queue
    
    commit 4842e98f26dd80be3623c4714a244ba52ea096a8 upstream.
    
    When a sequencer queue is created in snd_seq_queue_alloc(),it adds the
    new queue element to the public list before referencing it.  Thus the
    queue might be deleted before the call of snd_seq_queue_use(), and it
    results in the use-after-free error, as spotted by syzkaller.
    
    The fix is to reference the queue object at the right time.
    
    Reported-by: Dmitry Vyukov <dvyukov@google.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 010ada0cfcb9743f141ee7d7a22df063786129da
Author: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Date:   Mon Jan 30 12:45:46 2017 -0500

    xen-netfront: Delete rx_refill_timer in xennet_disconnect_backend()
    
    commit 74470954857c264168d2b5a113904cf0cfd27d18 upstream.
    
    rx_refill_timer should be deleted as soon as we disconnect from the
    backend since otherwise it is possible for the timer to go off before
    we get to xennet_destroy_queues(). If this happens we may dereference
    queue->rx.sring which is set to NULL in xennet_disconnect_backend().
    
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Reviewed-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1c0da0ac217bb4d8efc7a59326c9d4cc48ddb08a
Author: ojab <ojab@ojab.ru>
Date:   Wed Dec 28 11:05:24 2016 +0000

    scsi: mpt3sas: disable ASPM for MPI2 controllers
    
    commit ffdadd68af5a397b8a52289ab39d62e1acb39e63 upstream.
    
    MPI2 controllers sometimes got lost (i.e. disappear from
    /sys/bus/pci/devices) if ASMP is enabled.
    
    Signed-off-by: Slava Kardakov <ojab@ojab.ru>
    Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=60644
    Acked-by: Sreekanth Reddy <Sreekanth.Reddy@broadcom.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4d6bdf7c73e7e92ca143bc07b78681749f643ac4
Author: Dave Carroll <david.carroll@microsemi.com>
Date:   Thu Feb 9 11:04:47 2017 -0700

    scsi: aacraid: Fix INTx/MSI-x issue with older controllers
    
    commit 8af8e1c22f9994bb1849c01d66c24fe23f9bc9a0 upstream.
    
    commit 78cbccd3bd68 ("aacraid: Fix for KDUMP driver hang")
    
    caused a problem on older controllers which do not support MSI-x (namely
    ASR3405,ASR3805). This patch conditionalizes the previous patch to
    controllers which support MSI-x
    
    Fixes: 78cbccd3bd68 ("aacraid: Fix for KDUMP driver hang")
    Reported-by: Arkadiusz Miskiewicz <a.miskiewicz@gmail.com>
    Signed-off-by: Dave Carroll <david.carroll@microsemi.com>
    Reviewed-by: Raghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 52e02d6bf304c73d000f7b3f1448d50c08b0befc
Author: Steffen Maier <maier@linux.vnet.ibm.com>
Date:   Wed Feb 8 15:34:22 2017 +0100

    scsi: zfcp: fix use-after-free by not tracing WKA port open/close on failed send
    
    commit 2dfa6688aafdc3f74efeb1cf05fb871465d67f79 upstream.
    
    Dan Carpenter kindly reported:
    <quote>
    The patch d27a7cb91960: "zfcp: trace on request for open and close of
    WKA port" from Aug 10, 2016, leads to the following static checker
    warning:
    
            drivers/s390/scsi/zfcp_fsf.c:1615 zfcp_fsf_open_wka_port()
            warn: 'req' was already freed.
    
    drivers/s390/scsi/zfcp_fsf.c
      1609          zfcp_fsf_start_timer(req, ZFCP_FSF_REQUEST_TIMEOUT);
      1610          retval = zfcp_fsf_req_send(req);
      1611          if (retval)
      1612                  zfcp_fsf_req_free(req);
                                              ^^^
    Freed.
    
      1613  out:
      1614          spin_unlock_irq(&qdio->req_q_lock);
      1615          if (req && !IS_ERR(req))
      1616                  zfcp_dbf_rec_run_wka("fsowp_1", wka_port, req->req_id);
                                                                      ^^^^^^^^^^^
    Use after free.
    
      1617          return retval;
      1618  }
    
    Same thing for zfcp_fsf_close_wka_port() as well.
    </quote>
    
    Rather than relying on req being NULL (or ERR_PTR) for all cases where
    we don't want to trace or should not trace,
    simply check retval which is unconditionally initialized with -EIO != 0
    and it can only become 0 on successful retval = zfcp_fsf_req_send(req).
    With that we can also remove the then again unnecessary unconditional
    initialization of req which was introduced with that earlier commit.
    
    Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
    Suggested-by: Benjamin Block <bblock@linux.vnet.ibm.com>
    Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
    Fixes: d27a7cb91960 ("zfcp: trace on request for open and close of WKA port")
    Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
    Reviewed-by: Jens Remus <jremus@linux.vnet.ibm.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f2d256a2d49f535dcd9e1aad09f96ef0add706d2
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Thu Feb 9 19:37:35 2017 +0000

    netvsc: Set maximum GSO size in the right place
    
    Commit a50af86dd49e "netvsc: reduce maximum GSO size" was wrongly
    backported to 4.4-stable.  The maximum size needs to be set before the
    net device is registered, in netvsc_probe().
    
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Cc: Stephen Hemminger <sthemmin@microsoft.com>
    Cc: "David S. Miller" <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b9c29d45f980260b387749c7029453b9ee16b07f
Author: Thorsten Horstmann <thorsten@defutech.de>
Date:   Fri Feb 3 14:38:29 2017 +0100

    mac80211: Fix adding of mesh vendor IEs
    
    commit da7061c82e4a1bc6a5e134ef362c86261906c860 upstream.
    
    The function ieee80211_ie_split_vendor doesn't return 0 on errors. Instead
    it returns any offset < ielen when WLAN_EID_VENDOR_SPECIFIC is found. The
    return value in mesh_add_vendor_ies must therefore be checked against
    ifmsh->ie_len and not 0. Otherwise all ifmsh->ie starting with
    WLAN_EID_VENDOR_SPECIFIC will be rejected.
    
    Fixes: 082ebb0c258d ("mac80211: fix mesh beacon format")
    Signed-off-by: Thorsten Horstmann <thorsten@defutech.de>
    Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fit.fraunhofer.de>
    Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
    [sven@narfation.org: Add commit message]
    Signed-off-by: Sven Eckelmann <sven@narfation.org>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2f46791849be84e5a7c2fe13b5e4ab37e663fd55
Author: Alexander Sverdlin <alexander.sverdlin@gmail.com>
Date:   Tue Jan 17 21:10:11 2017 +0100

    ARM: 8642/1: LPAE: catch pending imprecise abort on unmask
    
    commit 97a98ae5b8acf08d07d972c087b2def060bc9b73 upstream.
    
    Asynchronous external abort is coded differently in DFSR with LPAE enabled.
    
    Fixes: 9254970c "ARM: 8447/1: catch pending imprecise abort on unmask".
    Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>
    Cc: Russell King <linux@armlinux.org.uk>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: linux-arm-kernel@lists.infradead.org
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 04ed4a9e21f524978e113754b0b6d374f2aef16f
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Mon Feb 6 14:28:09 2017 -0800

    target: Fix COMPARE_AND_WRITE ref leak for non GOOD status
    
    commit 9b2792c3da1e80f2d460167d319302a24c9ca2b7 upstream.
    
    This patch addresses a long standing bug where the commit phase
    of COMPARE_AND_WRITE would result in a se_cmd->cmd_kref reference
    leak if se_cmd->scsi_status returned non SAM_STAT_GOOD.
    
    This would manifest first as a lost SCSI response, and eventual
    hung task during fabric driver logout or re-login, as existing
    shutdown logic waited for the COMPARE_AND_WRITE se_cmd->cmd_kref
    to reach zero.
    
    To address this bug, compare_and_write_post() has been changed
    to drop the incorrect !cmd->scsi_status conditional that was
    preventing *post_ret = 1 for being set during non SAM_STAT_GOOD
    status.
    
    This patch has been tested with SAM_STAT_CHECK_CONDITION status
    from normal target_complete_cmd() callback path, as well as the
    incoming __target_execute_cmd() submission failure path when
    se_cmd->execute_cmd() returns non zero status.
    
    Reported-by: Donald White <dew@datera.io>
    Cc: Donald White <dew@datera.io>
    Tested-by: Gary Guo <ghg@datera.io>
    Cc: Gary Guo <ghg@datera.io>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0c863accadb065229e957fbc74eb7c236497d43f
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Tue Dec 6 22:45:46 2016 -0800

    target: Fix early transport_generic_handle_tmr abort scenario
    
    commit c54eeffbe9338fa982dc853d816fda9202a13b5a upstream.
    
    This patch fixes a bug where incoming task management requests
    can be explicitly aborted during an active LUN_RESET, but who's
    struct work_struct are canceled in-flight before execution.
    
    This occurs when core_tmr_drain_tmr_list() invokes cancel_work_sync()
    for the incoming se_tmr_req->task_cmd->work, resulting in cmd->work
    for target_tmr_work() never getting invoked and the aborted TMR
    waiting indefinately within transport_wait_for_tasks().
    
    To address this case, perform a CMD_T_ABORTED check early in
    transport_generic_handle_tmr(), and invoke the normal path via
    transport_cmd_check_stop_to_fabric() to complete any TMR kthreads
    blocked waiting for CMD_T_STOP in transport_wait_for_tasks().
    
    Also, move the TRANSPORT_ISTATE_PROCESSING assignment earlier
    into transport_generic_handle_tmr() so the existing check in
    core_tmr_drain_tmr_list() avoids attempting abort the incoming
    se_tmr_req->task_cmd->work if it has already been queued into
    se_device->tmr_wq.
    
    Reported-by: Rob Millner <rlm@daterainc.com>
    Tested-by: Rob Millner <rlm@daterainc.com>
    Cc: Rob Millner <rlm@daterainc.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ee44e73832c22d91303ac575e6d14823c378f40f
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Mon Oct 31 00:54:40 2016 -0700

    target: Use correct SCSI status during EXTENDED_COPY exception
    
    commit 0583c261e6325f392c1f7a1b9112e31298e1a4bd upstream.
    
    This patch adds the missing target_complete_cmd() SCSI status
    parameter change in target_xcopy_do_work(), that was originally
    missing in commit 926317de33.
    
    It correctly propigates up the correct SCSI status during
    EXTENDED_COPY exception cases, instead of always using the
    hardcoded SAM_STAT_CHECK_CONDITION from original code.
    
    This is required for ESX host environments that expect to
    hit SAM_STAT_RESERVATION_CONFLICT for certain scenarios,
    and SAM_STAT_CHECK_CONDITION results in non-retriable
    status for these cases.
    
    Reported-by: Nixon Vincent <nixon.vincent@calsoftinc.com>
    Tested-by: Nixon Vincent <nixon.vincent@calsoftinc.com>
    Cc: Nixon Vincent <nixon.vincent@calsoftinc.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 44d03b9280edcaa1bbb28116c3972e1cf144a24e
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date:   Sun Oct 23 14:28:15 2016 -0700

    target: Don't BUG_ON during NodeACL dynamic -> explicit conversion
    
    commit 391e2a6de9781e4906dd7e0b1cc097050bf43e11 upstream.
    
    After the v4.2+ RCU conversion to se_node_acl->lun_entry_hlist,
    a BUG_ON() was added in core_enable_device_list_for_node() to
    detect when the located orig->se_lun_acl contains an existing
    se_lun_acl pointer reference.
    
    However, this scenario can happen when a dynamically generated
    NodeACL is being converted to an explicit NodeACL, when the
    explicit NodeACL contains a different LUN mapping than the
    default provided by the WWN endpoint.
    
    So instead of triggering BUG_ON(), go ahead and fail instead
    following the original pre RCU conversion logic.
    
    Reported-by: Benjamin ESTRABAUD <ben.estrabaud@mpstor.com>
    Cc: Benjamin ESTRABAUD <ben.estrabaud@mpstor.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fcc038db59597e05030a757c4df8e58d2d8919ab
Author: Dave Martin <Dave.Martin@arm.com>
Date:   Wed Jan 18 17:11:56 2017 +0100

    ARM: 8643/3: arm/ptrace: Preserve previous registers for short regset write
    
    commit 228dbbfb5d77f8e047b2a1d78da14b7158433027 upstream.
    
    Ensure that if userspace supplies insufficient data to
    PTRACE_SETREGSET to fill all the registers, the thread's old
    registers are preserved.
    
    Fixes: 5be6f62b0059 ("ARM: 6883/1: ptrace: Migrate to regsets framework")
    Signed-off-by: Dave Martin <Dave.Martin@arm.com>
    Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cc187c6200f8316cc211d77fc35f269e7135fab4
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Fri Feb 3 17:35:46 2017 +0100

    hns: avoid stack overflow with CONFIG_KASAN
    
    commit b3f2d07f4649adcf6905953a10d217b5683e4077 upstream.
    
    The use of ACCESS_ONCE() looks like a micro-optimization to force gcc to use
    an indexed load for the register address, but it has an absolutely detrimental
    effect on builds with gcc-5 and CONFIG_KASAN=y, leading to a very likely
    kernel stack overflow aside from very complex object code:
    
    hisilicon/hns/hns_dsaf_gmac.c: In function 'hns_gmac_update_stats':
    hisilicon/hns/hns_dsaf_gmac.c:419:1: error: the frame size of 2912 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
    hisilicon/hns/hns_dsaf_ppe.c: In function 'hns_ppe_reset_common':
    hisilicon/hns/hns_dsaf_ppe.c:390:1: error: the frame size of 1184 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
    hisilicon/hns/hns_dsaf_ppe.c: In function 'hns_ppe_get_regs':
    hisilicon/hns/hns_dsaf_ppe.c:621:1: error: the frame size of 3632 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
    hisilicon/hns/hns_dsaf_rcb.c: In function 'hns_rcb_get_common_regs':
    hisilicon/hns/hns_dsaf_rcb.c:970:1: error: the frame size of 2784 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
    hisilicon/hns/hns_dsaf_gmac.c: In function 'hns_gmac_get_regs':
    hisilicon/hns/hns_dsaf_gmac.c:641:1: error: the frame size of 5728 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
    hisilicon/hns/hns_dsaf_rcb.c: In function 'hns_rcb_get_ring_regs':
    hisilicon/hns/hns_dsaf_rcb.c:1021:1: error: the frame size of 2208 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
    hisilicon/hns/hns_dsaf_main.c: In function 'hns_dsaf_comm_init':
    hisilicon/hns/hns_dsaf_main.c:1209:1: error: the frame size of 1904 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
    hisilicon/hns/hns_dsaf_xgmac.c: In function 'hns_xgmac_get_regs':
    hisilicon/hns/hns_dsaf_xgmac.c:748:1: error: the frame size of 4704 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
    hisilicon/hns/hns_dsaf_main.c: In function 'hns_dsaf_update_stats':
    hisilicon/hns/hns_dsaf_main.c:2420:1: error: the frame size of 1088 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
    hisilicon/hns/hns_dsaf_main.c: In function 'hns_dsaf_get_regs':
    hisilicon/hns/hns_dsaf_main.c:2753:1: error: the frame size of 10768 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
    
    This does not seem to happen any more with gcc-7, but removing the ACCESS_ONCE
    seems safe anyway and it avoids a serious issue for some people. I have verified
    that with gcc-5.3.1, the object code we get is better in the new version
    both with and without CONFIG_KASAN, as we no longer allocate a 1344 byte
    stack frame for hns_dsaf_get_regs() but otherwise have practically identical
    object code.
    
    With gcc-7.0.0, removing ACCESS_ONCE has no effect, the object code is already
    good either way.
    
    This patch is probably not urgent to get into 4.11 as only KASAN=y builds
    with certain compilers are affected, but I still think it makes sense to
    backport into older kernels.
    
    Fixes: 511e6bc ("net: add Hisilicon Network Subsystem DSAF support")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3b7ff5ed114fdb65517ee564a717b9c5fa374c94
Author: Tejun Heo <tj@kernel.org>
Date:   Wed Feb 8 14:30:56 2017 -0800

    cpumask: use nr_cpumask_bits for parsing functions
    
    commit 4d59b6ccf000862beed6fc0765d3209f98a8d8a2 upstream.
    
    Commit 513e3d2d11c9 ("cpumask: always use nr_cpu_ids in formatting and
    parsing functions") converted both cpumask printing and parsing
    functions to use nr_cpu_ids instead of nr_cpumask_bits.  While this was
    okay for the printing functions as it just picked one of the two output
    formats that we were alternating between depending on a kernel config,
    doing the same for parsing wasn't okay.
    
    nr_cpumask_bits can be either nr_cpu_ids or NR_CPUS.  We can always use
    nr_cpu_ids but that is a variable while NR_CPUS is a constant, so it can
    be more efficient to use NR_CPUS when we can get away with it.
    Converting the printing functions to nr_cpu_ids makes sense because it
    affects how the masks get presented to userspace and doesn't break
    anything; however, using nr_cpu_ids for parsing functions can
    incorrectly leave the higher bits uninitialized while reading in these
    masks from userland.  As all testing and comparison functions use
    nr_cpumask_bits which can be larger than nr_cpu_ids, the parsed cpumasks
    can erroneously yield false negative results.
    
    This made the taskstats interface incorrectly return -EINVAL even when
    the inputs were correct.
    
    Fix it by restoring the parse functions to use nr_cpumask_bits instead
    of nr_cpu_ids.
    
    Link: http://lkml.kernel.org/r/20170206182442.GB31078@htj.duckdns.org
    Fixes: 513e3d2d11c9 ("cpumask: always use nr_cpu_ids in formatting and parsing functions")
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reported-by: Martin Steigerwald <martin.steigerwald@teamix.de>
    Debugged-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    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 fd96835e205de1babf3a97957a8e66653d025dd0
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Wed Feb 8 18:08:29 2017 -0800

    Revert "x86/ioapic: Restore IO-APIC irq_chip retrigger callback"
    
    commit d966564fcdc19e13eb6ba1fbe6b8101070339c3d upstream.
    
    This reverts commit 020eb3daaba2857b32c4cf4c82f503d6a00a67de.
    
    Gabriel C reports that it causes his machine to not boot, and we haven't
    tracked down the reason for it yet.  Since the bug it fixes has been
    around for a longish time, we're better off reverting the fix for now.
    
    Gabriel says:
     "It hangs early and freezes with a lot RCU warnings.
    
      I bisected it down to :
    
      > Ruslan Ruslichenko (1):
      >       x86/ioapic: Restore IO-APIC irq_chip retrigger callback
    
      Reverting this one fixes the problem for me..
    
      The box is a PRIMERGY TX200 S5 , 2 socket , 2 x E5520 CPU(s) installed"
    
    and Ruslan and Thomas are currently stumped.
    
    Reported-and-bisected-by: Gabriel C <nix.or.die@gmail.com>
    Cc: Ruslan Ruslichenko <rruslich@cisco.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e72c13d93e9ed2b131ceb9a290ab056ce0dd41ab
Author: Stephen Smalley <sds@tycho.nsa.gov>
Date:   Tue Jan 31 11:54:04 2017 -0500

    selinux: fix off-by-one in setprocattr
    
    commit 0c461cb727d146c9ef2d3e86214f498b78b7d125 upstream.
    
    SELinux tries to support setting/clearing of /proc/pid/attr attributes
    from the shell by ignoring terminating newlines and treating an
    attribute value that begins with a NUL or newline as an attempt to
    clear the attribute.  However, the test for clearing attributes has
    always been wrong; it has an off-by-one error, and this could further
    lead to reading past the end of the allocated buffer since commit
    bb646cdb12e75d82258c2f2e7746d5952d3e321a ("proc_pid_attr_write():
    switch to memdup_user()").  Fix the off-by-one error.
    
    Even with this fix, setting and clearing /proc/pid/attr attributes
    from the shell is not straightforward since the interface does not
    support multiple write() calls (so shells that write the value and
    newline separately will set and then immediately clear the attribute,
    requiring use of echo -n to set the attribute), whereas trying to use
    echo -n "" to clear the attribute causes the shell to skip the
    write() call altogether since POSIX says that a zero-length write
    causes no side effects. Thus, one must use echo -n to set and echo
    without -n to clear, as in the following example:
    $ echo -n unconfined_u:object_r:user_home_t:s0 > /proc/$$/attr/fscreate
    $ cat /proc/$$/attr/fscreate
    unconfined_u:object_r:user_home_t:s0
    $ echo "" > /proc/$$/attr/fscreate
    $ cat /proc/$$/attr/fscreate
    
    Note the use of /proc/$$ rather than /proc/self, as otherwise
    the cat command will read its own attribute value, not that of the shell.
    
    There are no users of this facility to my knowledge; possibly we
    should just get rid of it.
    
    UPDATE: Upon further investigation it appears that a local process
    with the process:setfscreate permission can cause a kernel panic as a
    result of this bug.  This patch fixes CVE-2017-2618.
    
    Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
    [PM: added the update about CVE-2017-2618 to the commit description]
    Signed-off-by: Paul Moore <paul@paul-moore.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    
    Signed-off-by: James Morris <james.l.morris@oracle.com>

commit e871ea6bcf99097731fceff3e8e1c5ed05b04ae2
Author: Vineet Gupta <Vineet.Gupta1@synopsys.com>
Date:   Tue Feb 7 09:44:58 2017 -0800

    ARC: [arcompact] brown paper bag bug in unaligned access delay slot fixup
    
    commit a524c218bc94c705886a0e0fedeee45d1931da32 upstream.
    
    Reported-by: Jo-Philipp Wich <jo@mein.io>
    Fixes: 9aed02feae57bf7 ("ARC: [arcompact] handle unaligned access delay slot")
    Cc: linux-kernel@vger.kernel.org
    Cc: linux-snps-arc@lists.infradead.org
    Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
