1. 15 Sep, 2017 33 commits
  2. 26 Aug, 2017 7 commits
    • Ben Hutchings's avatar
      Linux 3.2.92 · 52bc1fde
      Ben Hutchings authored
      52bc1fde
    • Willem de Bruijn's avatar
      packet: fix tp_reserve race in packet_set_ring · 8f716035
      Willem de Bruijn authored
      commit c27927e3 upstream.
      
      Updates to tp_reserve can race with reads of the field in
      packet_set_ring. Avoid this by holding the socket lock during
      updates in setsockopt PACKET_RESERVE.
      
      This bug was discovered by syzkaller.
      
      Fixes: 8913336a ("packet: add PACKET_RESERVE sockopt")
      Reported-by: default avatarAndrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      8f716035
    • Cong Wang's avatar
      mqueue: fix a use-after-free in sys_mq_notify() · 3557f62e
      Cong Wang authored
      commit f991af3d upstream.
      
      The retry logic for netlink_attachskb() inside sys_mq_notify()
      is nasty and vulnerable:
      
      1) The sock refcnt is already released when retry is needed
      2) The fd is controllable by user-space because we already
         release the file refcnt
      
      so we when retry but the fd has been just closed by user-space
      during this small window, we end up calling netlink_detachskb()
      on the error path which releases the sock again, later when
      the user-space closes this socket a use-after-free could be
      triggered.
      
      Setting 'sock' to NULL here should be sufficient to fix it.
      Reported-by: default avatarGeneBlue <geneblue.mail@gmail.com>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Manfred Spraul <manfred@colorfullife.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      3557f62e
    • Thomas Gleixner's avatar
      timerfd: Protect the might cancel mechanism proper · 1b31fcb2
      Thomas Gleixner authored
      commit 1e38da30 upstream.
      
      The handling of the might_cancel queueing is not properly protected, so
      parallel operations on the file descriptor can race with each other and
      lead to list corruptions or use after free.
      
      Protect the context for these operations with a seperate lock.
      
      The wait queue lock cannot be reused for this because that would create a
      lock inversion scenario vs. the cancel lock. Replacing might_cancel with an
      atomic (atomic_t or atomic bit) does not help either because it still can
      race vs. the actual list operation.
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: "linux-fsdevel@vger.kernel.org"
      Cc: syzkaller <syzkaller@googlegroups.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: linux-fsdevel@vger.kernel.org
      Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1701311521430.3457@nanosSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      [bwh: Backported to 3.2: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      1b31fcb2
    • Sabrina Dubroca's avatar
      ipv6: avoid overflow of offset in ip6_find_1stfragopt · c5a5d1b1
      Sabrina Dubroca authored
      commit 6399f1fa upstream.
      
      In some cases, offset can overflow and can cause an infinite loop in
      ip6_find_1stfragopt(). Make it unsigned int to prevent the overflow, and
      cap it at IPV6_MAXPLEN, since packets larger than that should be invalid.
      
      This problem has been here since before the beginning of git history.
      Signed-off-by: default avatarSabrina Dubroca <sd@queasysnail.net>
      Acked-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [bwh: Backported to 3.2: adjust filename, context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      c5a5d1b1
    • Laura Abbott's avatar
      x86/mm/32: Set the '__vmalloc_start_set' flag in initmem_init() · 408ab21e
      Laura Abbott authored
      commit 861ce4a3 upstream.
      
      '__vmalloc_start_set' currently only gets set in initmem_init() when
      !CONFIG_NEED_MULTIPLE_NODES. This breaks detection of vmalloc address
      with virt_addr_valid() with CONFIG_NEED_MULTIPLE_NODES=y, causing
      a kernel crash:
      
        [mm/usercopy] 517e1fbe: kernel BUG at arch/x86/mm/physaddr.c:78!
      
      Set '__vmalloc_start_set' appropriately for that case as well.
      Reported-by: default avatarkbuild test robot <fengguang.wu@intel.com>
      Signed-off-by: default avatarLaura Abbott <labbott@redhat.com>
      Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Fixes: dc16ecf7 ("x86-32: use specific __vmalloc_start_set flag in __virt_addr_valid")
      Link: http://lkml.kernel.org/r/1494278596-30373-1-git-send-email-labbott@redhat.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      408ab21e
    • Arnd Bergmann's avatar
      fbdev: sti: don't select CONFIG_VT · 94cca398
      Arnd Bergmann authored
      commit 34bf129a upstream.
      
      While working on another build error, I ran into several variations of
      this dependency loop:
      
      subsection "Kconfig recursive dependency limitations"
      drivers/input/Kconfig:8:	symbol INPUT is selected by VT
      For a resolution refer to Documentation/kbuild/kconfig-language.txt
      subsection "Kconfig recursive dependency limitations"
      drivers/tty/Kconfig:12:	symbol VT is selected by FB_STI
      For a resolution refer to Documentation/kbuild/kconfig-language.txt
      subsection "Kconfig recursive dependency limitations"
      drivers/video/fbdev/Kconfig:677:	symbol FB_STI depends on FB
      For a resolution refer to Documentation/kbuild/kconfig-language.txt
      subsection "Kconfig recursive dependency limitations"
      drivers/video/fbdev/Kconfig:5:	symbol FB is selected by DRM_KMS_FB_HELPER
      For a resolution refer to Documentation/kbuild/kconfig-language.txt
      subsection "Kconfig recursive dependency limitations"
      drivers/gpu/drm/Kconfig:72:	symbol DRM_KMS_FB_HELPER is selected by DRM_KMS_CMA_HELPER
      For a resolution refer to Documentation/kbuild/kconfig-language.txt
      subsection "Kconfig recursive dependency limitations"
      drivers/gpu/drm/Kconfig:137:	symbol DRM_KMS_CMA_HELPER is selected by DRM_HDLCD
      For a resolution refer to Documentation/kbuild/kconfig-language.txt
      subsection "Kconfig recursive dependency limitations"
      drivers/gpu/drm/arm/Kconfig:6:	symbol DRM_HDLCD depends on OF
      For a resolution refer to Documentation/kbuild/kconfig-language.txt
      subsection "Kconfig recursive dependency limitations"
      drivers/of/Kconfig:4:	symbol OF is selected by X86_INTEL_CE
      For a resolution refer to Documentation/kbuild/kconfig-language.txt
      subsection "Kconfig recursive dependency limitations"
      arch/x86/Kconfig:523:	symbol X86_INTEL_CE depends on X86_IO_APIC
      For a resolution refer to Documentation/kbuild/kconfig-language.txt
      subsection "Kconfig recursive dependency limitations"
      arch/x86/Kconfig:1011:	symbol X86_IO_APIC depends on X86_LOCAL_APIC
      For a resolution refer to Documentation/kbuild/kconfig-language.txt
      subsection "Kconfig recursive dependency limitations"
      arch/x86/Kconfig:1005:	symbol X86_LOCAL_APIC depends on X86_UP_APIC
      For a resolution refer to Documentation/kbuild/kconfig-language.txt
      subsection "Kconfig recursive dependency limitations"
      arch/x86/Kconfig:980:	symbol X86_UP_APIC depends on PCI_MSI
      For a resolution refer to Documentation/kbuild/kconfig-language.txt
      subsection "Kconfig recursive dependency limitations"
      drivers/pci/Kconfig:11:	symbol PCI_MSI is selected by AMD_IOMMU
      For a resolution refer to Documentation/kbuild/kconfig-language.txt
      subsection "Kconfig recursive dependency limitations"
      drivers/iommu/Kconfig:106:	symbol AMD_IOMMU depends on IOMMU_SUPPORT
      For a resolution refer to Documentation/kbuild/kconfig-language.txt
      subsection "Kconfig recursive dependency limitations"
      drivers/iommu/Kconfig:5:	symbol IOMMU_SUPPORT is selected by DRM_ETNAVIV
      For a resolution refer to Documentation/kbuild/kconfig-language.txt
      subsection "Kconfig recursive dependency limitations"
      drivers/gpu/drm/etnaviv/Kconfig:2:	symbol DRM_ETNAVIV depends on THERMAL
      For a resolution refer to Documentation/kbuild/kconfig-language.txt
      subsection "Kconfig recursive dependency limitations"
      drivers/thermal/Kconfig:5:	symbol THERMAL is selected by ACPI_VIDEO
      For a resolution refer to Documentation/kbuild/kconfig-language.txt
      subsection "Kconfig recursive dependency limitations"
      drivers/acpi/Kconfig:183:	symbol ACPI_VIDEO is selected by INPUT
      
      This doesn't currently show up as I fixed the 'THERMAL' part of it,
      but I noticed that the FB_STI dependency should not be there but
      was introduced by slightly incorrect bug-fix patch that tried to
      fix a link error.
      
      Instead of selecting 'VT' to make us enter the drivers/video/console
      directory at compile-time, it's sufficient to build the
      drivers/video/console/sticore.c file by adding its directory
      to when CONFIG_FB_STI is enabled. Alternatively, we could move the
      sticore code to another directory that is always built when we
      have at STI_CONSOLE or FB_STI enabled.
      
      Fixes: 17085a93 ("parisc: stifb: should depend on STI_CONSOLE")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Cc: Helge Deller <deller@gmx.de>
      Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
      Cc: Alexander Beregalov <a.beregalov@gmail.com>
      Signed-off-by: default avatarBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      [bwh: Backported to 3.2: adjust filename]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      94cca398