1. 14 Feb, 2017 7 commits
    • Nicholas Bellinger's avatar
      target: Don't BUG_ON during NodeACL dynamic -> explicit conversion · 44d03b92
      Nicholas Bellinger authored
      commit 391e2a6d 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: default avatarBenjamin ESTRABAUD <ben.estrabaud@mpstor.com>
      Cc: Benjamin ESTRABAUD <ben.estrabaud@mpstor.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      44d03b92
    • Dave Martin's avatar
      ARM: 8643/3: arm/ptrace: Preserve previous registers for short regset write · fcc038db
      Dave Martin authored
      commit 228dbbfb upstream.
      
      Ensure that if userspace supplies insufficient data to
      PTRACE_SETREGSET to fill all the registers, the thread's old
      registers are preserved.
      
      Fixes: 5be6f62b ("ARM: 6883/1: ptrace: Migrate to regsets framework")
      Signed-off-by: default avatarDave Martin <Dave.Martin@arm.com>
      Acked-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fcc038db
    • Arnd Bergmann's avatar
      hns: avoid stack overflow with CONFIG_KASAN · cc187c62
      Arnd Bergmann authored
      commit b3f2d07f 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: 511e6bc0 ("net: add Hisilicon Network Subsystem DSAF support")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cc187c62
    • Tejun Heo's avatar
      cpumask: use nr_cpumask_bits for parsing functions · 3b7ff5ed
      Tejun Heo authored
      commit 4d59b6cc upstream.
      
      Commit 513e3d2d ("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: 513e3d2d ("cpumask: always use nr_cpu_ids in formatting and parsing functions")
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Reported-by: default avatarMartin Steigerwald <martin.steigerwald@teamix.de>
      Debugged-by: default avatarBen Hutchings <ben.hutchings@codethink.co.uk>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3b7ff5ed
    • Linus Torvalds's avatar
      Revert "x86/ioapic: Restore IO-APIC irq_chip retrigger callback" · fd96835e
      Linus Torvalds authored
      commit d966564f upstream.
      
      This reverts commit 020eb3da.
      
      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: default avatarGabriel C <nix.or.die@gmail.com>
      Cc: Ruslan Ruslichenko <rruslich@cisco.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fd96835e
    • Stephen Smalley's avatar
      selinux: fix off-by-one in setprocattr · e72c13d9
      Stephen Smalley authored
      commit 0c461cb7 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
      bb646cdb ("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: default avatarStephen Smalley <sds@tycho.nsa.gov>
      [PM: added the update about CVE-2017-2618 to the commit description]
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarJames Morris <james.l.morris@oracle.com>
      e72c13d9
    • Vineet Gupta's avatar
      ARC: [arcompact] brown paper bag bug in unaligned access delay slot fixup · e871ea6b
      Vineet Gupta authored
      commit a524c218 upstream.
      Reported-by: default avatarJo-Philipp Wich <jo@mein.io>
      Fixes: 9aed02fe ("ARC: [arcompact] handle unaligned access delay slot")
      Cc: linux-kernel@vger.kernel.org
      Cc: linux-snps-arc@lists.infradead.org
      Signed-off-by: default avatarVineet Gupta <vgupta@synopsys.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e871ea6b
  2. 09 Feb, 2017 30 commits
  3. 04 Feb, 2017 3 commits