1. 15 Sep, 2017 3 commits
  2. 26 Aug, 2017 37 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
    • Richard Weinberger's avatar
      um: Fix PTRACE_POKEUSER on x86_64 · c58b2c46
      Richard Weinberger authored
      commit 9abc74a2 upstream.
      
      This is broken since ever but sadly nobody noticed.
      Recent versions of GDB set DR_CONTROL unconditionally and
      UML dies due to a heap corruption. It turns out that
      the PTRACE_POKEUSER was copy&pasted from i386 and assumes
      that addresses are 4 bytes long.
      
      Fix that by using 8 as address size in the calculation.
      Reported-by: default avatarjie cao <cj3054@gmail.com>
      Signed-off-by: default avatarRichard Weinberger <richard@nod.at>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      c58b2c46
    • Steve French's avatar
      Set unicode flag on cifs echo request to avoid Mac error · c5de619e
      Steve French authored
      commit 26c9cb66 upstream.
      
      Mac requires the unicode flag to be set for cifs, even for the smb
      echo request (which doesn't have strings).
      
      Without this Mac rejects the periodic echo requests (when mounting
      with cifs) that we use to check if server is down
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      c5de619e
    • Dan Carpenter's avatar
      cifs: small underflow in cnvrtDosUnixTm() · 67a70eac
      Dan Carpenter authored
      commit 564277ec upstream.
      
      January is month 1.  There is no zero-th month.  If someone passes a
      zero month then it means we read from one space before the start of the
      total_days_of_prev_months[] array.
      
      We may as well also be strict about days as well.
      
      Fixes: 1bd5bbcb ("[CIFS] Legacy time handling for Win9x and OS/2 part 1")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarSteve French <smfrench@gmail.com>
      [bwh: Backported to 3.2: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      67a70eac
    • Eric Dumazet's avatar
      tcp: fix wraparound issue in tcp_lp · e8f2dfc1
      Eric Dumazet authored
      commit a9f11f96 upstream.
      
      Be careful when comparing tcp_time_stamp to some u32 quantity,
      otherwise result can be surprising.
      
      Fixes: 7c106d7e ("[TCP]: TCP Low Priority congestion control")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [bwh: Backported to 3.2: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      e8f2dfc1
    • David S. Miller's avatar
      ipv6: Need to export ipv6_push_frag_opts for tunneling now. · 52c4c86e
      David S. Miller authored
      commit 5b8481fa upstream.
      
      Since that change also made the nfrag function not necessary
      for exports, remove it.
      
      Fixes: 89a23c8b ("ip6_tunnel: Fix missing tunnel encapsulation limit option")
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [bwh: Backported to 3.2: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      52c4c86e
    • Craig Gallek's avatar
      ip6_tunnel: Fix missing tunnel encapsulation limit option · 700f4609
      Craig Gallek authored
      commit 89a23c8b upstream.
      
      The IPv6 tunneling code tries to insert IPV6_TLV_TNL_ENCAP_LIMIT and
      IPV6_TLV_PADN options when an encapsulation limit is defined (the
      default is a limit of 4).  An MTU adjustment is done to account for
      these options as well.  However, the options are never present in the
      generated packets.
      
      The issue appears to be a subtlety between IPV6_DSTOPTS and
      IPV6_RTHDRDSTOPTS defined in RFC 3542.  When the IPIP tunnel driver was
      written, the encap limit options were included as IPV6_RTHDRDSTOPTS in
      dst0opt of struct ipv6_txoptions.  Later, ipv6_push_nfrags_opts was
      (correctly) updated to require IPV6_RTHDR options when IPV6_RTHDRDSTOPTS
      are to be used.  This caused the options to no longer be included in v6
      encapsulated packets.
      
      The fix is to use IPV6_DSTOPTS (in dst1opt of struct ipv6_txoptions)
      instead.  IPV6_DSTOPTS do not have the additional IPV6_RTHDR requirement.
      
      Fixes: 1df64a85: ("[IPV6]: Add ip6ip6 tunnel driver.")
      Fixes: 333fad53: ("[IPV6]: Support several new sockopt / ancillary data in Advanced API (RFC3542)")
      Signed-off-by: default avatarCraig Gallek <kraig@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      [bwh: Backported to 3.2: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      700f4609
    • Michael Trimarchi's avatar
      power: supply: pda_power: move from timer to delayed_work · 1d876569
      Michael Trimarchi authored
      commit 633e8799 upstream.
      
      This changed is needed to avoid locking problem during
      boot as shown:
      
      <5>[    8.824096] Registering SWP/SWPB emulation handler
      <6>[    8.977294] clock: disabling unused clocks to save power
      <3>[    9.108154] BUG: sleeping function called from invalid context at kernel_albert/kernel/mutex.c:269
      <3>[    9.122894] in_atomic(): 1, irqs_disabled(): 0, pid: 1, name: swapper/0
      <4>[    9.130249] 3 locks held by swapper/0/1:
      <4>[    9.134613]  #0:  (&__lockdep_no_validate__){......}, at: [<c0342430>] __driver_attach+0x58/0xa8
      <4>[    9.144500]  #1:  (&__lockdep_no_validate__){......}, at: [<c0342440>] __driver_attach+0x68/0xa8
      <4>[    9.154357]  #2:  (&polling_timer){......}, at: [<c0053770>] run_timer_softirq+0x108/0x3ec
      <4>[    9.163726] Backtrace:
      <4>[    9.166473] [<c001269c>] (dump_backtrace+0x0/0x114) from [<c067e5f0>] (dump_stack+0x20/0x24)
      <4>[    9.175811]  r6:00203230 r5:0000010d r4:d782e000 r3:60000113
      <4>[    9.182250] [<c067e5d0>] (dump_stack+0x0/0x24) from [<c007441c>] (__might_sleep+0x10c/0x128)
      <4>[    9.191650] [<c0074310>] (__might_sleep+0x0/0x128) from [<c0688f60>] (mutex_lock_nested+0x34/0x36c)
      <4>[    9.201660]  r5:c02d5350 r4:d79a0c64
      <4>[    9.205688] [<c0688f2c>] (mutex_lock_nested+0x0/0x36c) from [<c02d5350>] (regulator_set_current_limit+0x30/0x118)
      <4>[    9.217071] [<c02d5320>] (regulator_set_current_limit+0x0/0x118) from [<c0435ce0>] (update_charger+0x84/0xc4)
      <4>[    9.228027]  r7:d782fb20 r6:00000101 r5:c1767e94 r4:00000000
      <4>[    9.234436] [<c0435c5c>] (update_charger+0x0/0xc4) from [<c0435d40>] (psy_changed+0x20/0x48)
      <4>[    9.243804]  r5:d782e000 r4:c1767e94
      <4>[    9.247802] [<c0435d20>] (psy_changed+0x0/0x48) from [<c0435dec>] (polling_timer_func+0x84/0xb8)
      <4>[    9.257537]  r4:c1767e94 r3:00000002
      <4>[    9.261566] [<c0435d68>] (polling_timer_func+0x0/0xb8) from [<c00537e4>] (run_timer_softirq+0x17c/0x3ec)
      <4>[    9.272033]  r4:c1767eb0 r3:00000000
      <4>[    9.276062] [<c0053668>] (run_timer_softirq+0x0/0x3ec) from [<c004b000>] (__do_softirq+0xf0/0x298)
      <4>[    9.286010] [<c004af10>] (__do_softirq+0x0/0x298) from [<c004b650>] (irq_exit+0x98/0xa0)
      <4>[    9.295013] [<c004b5b8>] (irq_exit+0x0/0xa0) from [<c000edbc>] (handle_IRQ+0x60/0xc0)
      <4>[    9.303680]  r4:c1194e98 r3:c00bc778
      <4>[    9.307708] [<c000ed5c>] (handle_IRQ+0x0/0xc0) from [<c0008504>] (gic_handle_irq+0x34/0x68)
      <4>[    9.316955]  r8:000ac383 r7:d782fc3c r6:d782fc08 r5:c11936c4 r4:e0802100
      <4>[    9.324310] r3:c026ba48
      <4>[    9.327301] [<c00084d0>] (gic_handle_irq+0x0/0x68) from [<c068c2c0>] (__irq_svc+0x40/0x74)
      <4>[    9.336456] Exception stack(0xd782fc08 to 0xd782fc50)
      <4>[    9.342041] fc00:                   d6e30e6c ac383627 00000000 ac383417 ea19c000 ea200000
      <4>[    9.351104] fc20: beffffff 00000667 000ac383 d6e30670 d6e3066c d782fc94 d782fbe8 d782fc50
      <4>[    9.360168] fc40: c026ba48 c001d1f0 00000113 ffffffff
      
      Fixes: b2998049 ("[BATTERY] pda_power platform driver")
      Signed-off-by: default avatarMichael Trimarchi <michael@amarulasolutions.com>
      Signed-off-by: default avatarAnthony Brandon <anthony@amarulasolutions.com>
      Signed-off-by: default avatarSebastian Reichel <sebastian.reichel@collabora.co.uk>
      [bwh: Backported to 3.2:
       - Drop changes in otg_handle_notification()
       - Adjust filename]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      1d876569
    • Szymon Janc's avatar
      Bluetooth: Fix user channel for 32bit userspace on 64bit kernel · 03e1c5f4
      Szymon Janc authored
      commit ab89f0bd upstream.
      
      Running 32bit userspace on 64bit kernel results in MSG_CMSG_COMPAT being
      defined as 0x80000000. This results in sendmsg failure if used from 32bit
      userspace running on 64bit kernel. Fix this by accounting for MSG_CMSG_COMPAT
      in flags check in hci_sock_sendmsg.
      Signed-off-by: default avatarSzymon Janc <szymon.janc@codecoup.pl>
      Signed-off-by: default avatarMarko Kiiskila <marko@runtime.io>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      03e1c5f4
    • Christophe Leroy's avatar
      net: ethernet: ucc_geth: fix MEM_PART_MURAM mode · 36c08d83
      Christophe Leroy authored
      commit 8b8642af upstream.
      
      Since commit 5093bb96 ("powerpc/QE: switch to the cpm_muram
      implementation"), muram area is not part of immrbar mapping anymore
      so immrbar_virt_to_phys() is not usable anymore.
      
      Fixes: 5093bb96 ("powerpc/QE: switch to the cpm_muram implementation")
      Signed-off-by: default avatarChristophe Leroy <christophe.leroy@c-s.fr>
      Acked-by: default avatarDavid S. Miller <davem@davemloft.net>
      Acked-by: default avatarLi Yang <pku.leo@gmail.com>
      Signed-off-by: default avatarScott Wood <oss@buserror.net>
      [bwh: Backported to 3.2: adjust filename]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      36c08d83
    • Christoph Hellwig's avatar
      libata: reject passthrough WRITE SAME requests · 4d34a500
      Christoph Hellwig authored
      commit c6ade20f upstream.
      
      The WRITE SAME to TRIM translation rewrites the DATA OUT buffer.  While
      the SCSI code accomodates for this by passing a read-writable buffer
      userspace applications don't cater for this behavior.  In fact it can
      be used to rewrite e.g. a readonly file through mmap and should be
      considered as a security fix.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      [bwh: Backported to 3.2:
       - Open-code blk_rq_is_passthrough()
       - We don't distinguish which field is invaid so goto invalid_fld
       - Adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      4d34a500
    • Michael J. Ruhl's avatar
      IB/core: For multicast functions, verify that LIDs are multicast LIDs · 258132a3
      Michael J. Ruhl authored
      commit 8561eae6 upstream.
      
      The Infiniband spec defines "A multicast address is defined by a
      MGID and a MLID" (section 10.5).  Currently the MLID value is not
      validated.
      
      Add check to verify that the MLID value is in the correct address
      range.
      
      Fixes: 0c33aeed ("[IB] Add checks to multicast attach and detach")
      Reviewed-by: default avatarIra Weiny <ira.weiny@intel.com>
      Reviewed-by: default avatarDasaratharaman Chandramouli <dasaratharaman.chandramouli@intel.com>
      Signed-off-by: default avatarMichael J. Ruhl <michael.j.ruhl@intel.com>
      Signed-off-by: default avatarDennis Dalessandro <dennis.dalessandro@intel.com>
      Reviewed-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      [bwh: Backported to 3.2: use literal number instead of IB_MULTICAST_LID_BASE]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      258132a3
    • Michael J. Ruhl's avatar
      IB/core: If the MGID/MLID pair is not on the list return an error · 748b9d53
      Michael J. Ruhl authored
      commit 20c7840a upstream.
      
      A list of MGID/MLID pairs is built when doing a multicast attach.  When
      the multicast detach is called, the list is searched, and regardless of
      the search outcome, the driver detach is called.
      
      If an MGID/MLID pair is not on the list, driver detach should not be
      called, and an error should be returned.  Calling the driver without
      removing an MGID/MLID pair from the list can leave the core and driver
      out of sync.
      
      Fixes: f4e40156 ("IB/uverbs: track multicast group membership for userspace QPs")
      Reviewed-by: default avatarIra Weiny <ira.weiny@intel.com>
      Reviewed-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: default avatarMichael J. Ruhl <michael.j.ruhl@intel.com>
      Signed-off-by: default avatarDennis Dalessandro <dennis.dalessandro@intel.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      [bwh: Backported to 3.2: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      748b9d53
    • Alexey Brodkin's avatar
      usb: Make sure usb/phy/of gets built-in · 2be53503
      Alexey Brodkin authored
      commit 3d615964 upstream.
      
      DWC3 driver uses of_usb_get_phy_mode() which is
      implemented in drivers/usb/phy/of.c and in bare minimal
      configuration it might not be pulled in kernel binary.
      
      In case of ARC or ARM this could be easily reproduced with
      "allnodefconfig" +CONFIG_USB=m +CONFIG_USB_DWC3=m.
      
      On building all ends-up with:
      ---------------------->8------------------
        Kernel: arch/arm/boot/Image is ready
        Kernel: arch/arm/boot/zImage is ready
        Building modules, stage 2.
        MODPOST 5 modules
      ERROR: "of_usb_get_phy_mode" [drivers/usb/dwc3/dwc3.ko] undefined!
      make[1]: *** [__modpost] Error 1
      make: *** [modules] Error 2
      ---------------------->8------------------
      Signed-off-by: default avatarAlexey Brodkin <abrodkin@synopsys.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
      Cc: Geert Uytterhoeven <geert+renesas@glider.be>
      Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Felipe Balbi <balbi@kernel.org>
      Cc: Felix Fietkau <nbd@nbd.name>
      Cc: Jeremy Kerr <jk@ozlabs.org>
      Cc: linux-snps-arc@lists.infradead.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      2be53503
    • Stefan Assmann's avatar
      PCI: Disable boot interrupt quirk for ASUS M2N-LR · 7825ba3a
      Stefan Assmann authored
      commit c4e649b0 upstream.
      
      The ASUS M2N-LR should not trigger boot interrupt quirks although it
      carries an Intel 6702PXH.  On this board the boot interrupt quirks cause
      incorrect IRQ assignments and should be disabled.
      
      Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=43074Tested-by: default avatarSolomon Peachy <pizza@shaftnet.org>
      Signed-off-by: default avatarStefan Assmann <sassmann@kpanic.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      7825ba3a
    • Liping Zhang's avatar
      netfilter: ctnetlink: make it safer when updating ct->status · 883a0ef4
      Liping Zhang authored
      commit 53b56da8 upstream.
      
      After converting to use rcu for conntrack hash, one CPU may update
      the ct->status via ctnetlink, while another CPU may process the
      packets and update the ct->status.
      
      So the non-atomic operation "ct->status |= status;" via ctnetlink
      becomes unsafe, and this may clear the IPS_DYING_BIT bit set by
      another CPU unexpectedly. For example:
               CPU0                            CPU1
        ctnetlink_change_status        __nf_conntrack_find_get
            old = ct->status              nf_ct_gc_expired
                -                         nf_ct_kill
                -                      test_and_set_bit(IPS_DYING_BIT
            new = old | status;                 -
        ct->status = new; <-- oops, _DYING_ is cleared!
      
      Now using a series of atomic bit operation to solve the above issue.
      
      Also note, user shouldn't set IPS_TEMPLATE, IPS_SEQ_ADJUST directly,
      so make these two bits be unchangable too.
      
      If we set the IPS_TEMPLATE_BIT, ct will be freed by nf_ct_tmpl_free,
      but actually it is alloced by nf_conntrack_alloc.
      If we set the IPS_SEQ_ADJUST_BIT, this may cause the NULL pointer
      deference, as the nfct_seqadj(ct) maybe NULL.
      
      Last, add some comments to describe the logic change due to the
      commit a963d710 ("netfilter: ctnetlink: Fix regression in CTA_STATUS
      processing"), which makes me feel a little confusing.
      
      Fixes: 76507f69 ("[NETFILTER]: nf_conntrack: use RCU for conntrack hash")
      Signed-off-by: default avatarLiping Zhang <zlpnobody@gmail.com>
      Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
      [bwh: Backported to 3.2:
       - IPS_UNCHANGEABLE_MASK was not previously defined and ctnetlink_update_status()
         is not needed
       - enum ip_conntrack_status only assigns 13 bits
       - Adjust filename]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      883a0ef4
    • Ashish Kalra's avatar
      x86/boot: Fix BSS corruption/overwrite bug in early x86 kernel startup · 85763352
      Ashish Kalra authored
      commit d594aa02 upstream.
      
      The minimum size for a new stack (512 bytes) setup for arch/x86/boot components
      when the bootloader does not setup/provide a stack for the early boot components
      is not "enough".
      
      The setup code executing as part of early kernel startup code, uses the stack
      beyond 512 bytes and accidentally overwrites and corrupts part of the BSS
      section. This is exposed mostly in the early video setup code, where
      it was corrupting BSS variables like force_x, force_y, which in-turn affected
      kernel parameters such as screen_info (screen_info.orig_video_cols) and
      later caused an exception/panic in console_init().
      
      Most recent boot loaders setup the stack for early boot components, so this
      stack overwriting into BSS section issue has not been exposed.
      Signed-off-by: default avatarAshish Kalra <ashish@bluestacks.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/20170419152015.10011-1-ashishkalra@Ashishs-MacBook-Pro.localSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      85763352
    • Peter Chen's avatar
      usb: host: xhci: print correct command ring address · f9196a6d
      Peter Chen authored
      commit 6fc091fb upstream.
      
      Print correct command ring address using 'val_64'.
      Signed-off-by: default avatarPeter Chen <peter.chen@nxp.com>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      [bwh: Backported to 3.2: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      f9196a6d
    • Frank Schaefer's avatar
      ov2640: fix vflip control · 1791088d
      Frank Schaefer authored
      commit 7f140fc2 upstream.
      
      Enabling vflip currently causes wrong colors.
      It seems that (at least with the current sensor setup) REG04_VFLIP_IMG only
      changes the vertical readout direction.
      Because pixels are arranged RGRG... in odd lines and GBGB... in even lines,
      either a one line shift or even/odd line swap is required, too, but
      apparently this doesn't happen.
      
      I finally figured out that this can be done manually by setting
      REG04_VREF_EN.
      Looking at hflip, it turns out that bit REG04_HREF_EN is set there
      permanetly, but according to my tests has no effect on the pixel readout
      order.
      So my conclusion is that the current documentation of sensor register 0x04
      is wrong (has changed after preliminary datasheet version 2.2).
      
      I'm pretty sure that automatic vertical line shift/switch can be enabled,
      too, but until anyone finds ot how this works, we have to stick with manual
      switching.
      Signed-off-by: default avatarFrank Schäfer <fschaefer.oss@googlemail.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      [bwh: Backported to 3.2: adjust filename]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      1791088d
    • Alyssa Milburn's avatar
      dw2102: limit messages to buffer size · 716e324b
      Alyssa Milburn authored
      commit 950e252c upstream.
      
      Otherwise the i2c transfer functions can read or write beyond the end of
      stack or heap buffers.
      Signed-off-by: default avatarAlyssa Milburn <amilburn@zall.org>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      [bwh: Backported to 3.2:
       - Use obuf instead of state->data
       - Adjust filename, context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      716e324b
    • Dan Carpenter's avatar
      dw2102: some missing unlocks on error · 45fd70b4
      Dan Carpenter authored
      commit 324ed533 upstream.
      
      We recently introduced some new error paths but the unlocks are missing.
      Fixes: 0065a79a ('[media] dw2102: Don't use dynamic static allocation')
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <m.chehab@samsung.com>
      [bwh: Backported to 3.2: adjust filename, context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      45fd70b4
    • Mauro Carvalho Chehab's avatar
      dw2102: Don't use dynamic static allocation · 0cfbb464
      Mauro Carvalho Chehab authored
      commit 0065a79a upstream.
      
      Dynamic static allocation is evil, as Kernel stack is too low, and
      compilation complains about it on some archs:
      	drivers/media/usb/dvb-usb/dw2102.c:368:1: warning: 'dw2102_earda_i2c_transfer' uses dynamic stack allocation [enabled by default]
      	drivers/media/usb/dvb-usb/dw2102.c:449:1: warning: 'dw2104_i2c_transfer' uses dynamic stack allocation [enabled by default]
      	drivers/media/usb/dvb-usb/dw2102.c:512:1: warning: 'dw3101_i2c_transfer' uses dynamic stack allocation [enabled by default]
      	drivers/media/usb/dvb-usb/dw2102.c:621:1: warning: 's6x0_i2c_transfer' uses dynamic stack allocation [enabled by default]
      Instead, let's enforce a limit for the buffer to be the max size of
      a control URB payload data (64 bytes).
      Signed-off-by: default avatarMauro Carvalho Chehab <m.chehab@samsung.com>
      Reviewed-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <m.chehab@samsung.com>
      [bwh: Backported to 3.2: adjust filename, context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      0cfbb464
    • Alyssa Milburn's avatar
      ttusb2: limit messages to buffer size · a09cc2a3
      Alyssa Milburn authored
      commit a12b8ab8 upstream.
      
      Otherwise ttusb2_i2c_xfer can read or write beyond the end of static and
      heap buffers.
      Signed-off-by: default avatarAlyssa Milburn <amilburn@zall.org>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      [bwh: Backported to 3.2: adjust filename]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      a09cc2a3
    • Josh Boyer's avatar
      ttusb2: Don't use stack variables for DMA · 489c8015
      Josh Boyer authored
      commit ff179991 upstream.
      
      The ttusb2_msg function uses on-stack variables to submit commands to
      dvb_usb_generic.  This eventually gets to the DMA api layer and will throw a
      traceback if the debugging options are set.
      
      This allocates the temporary buffer variables with kzalloc instead.
      
      Fixes https://bugzilla.redhat.com/show_bug.cgi?id=734506Signed-off-by: default avatarJosh Boyer <jwboyer@redhat.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      489c8015
    • Lukas Wunner's avatar
      PCI: Freeze PME scan before suspending devices · e8fba609
      Lukas Wunner authored
      commit ea00353f upstream.
      
      Laurent Pinchart reported that the Renesas R-Car H2 Lager board (r8a7790)
      crashes during suspend tests.  Geert Uytterhoeven managed to reproduce the
      issue on an M2-W Koelsch board (r8a7791):
      
        It occurs when the PME scan runs, once per second.  During PME scan, the
        PCI host bridge (rcar-pci) registers are accessed while its module clock
        has already been disabled, leading to the crash.
      
      One reproducer is to configure s2ram to use "s2idle" instead of "deep"
      suspend:
      
        # echo 0 > /sys/module/printk/parameters/console_suspend
        # echo s2idle > /sys/power/mem_sleep
        # echo mem > /sys/power/state
      
      Another reproducer is to write either "platform" or "processors" to
      /sys/power/pm_test.  It does not (or is less likely) to happen during full
      system suspend ("core" or "none") because system suspend also disables
      timers, and thus the workqueue handling PME scans no longer runs.  Geert
      believes the issue may still happen in the small window between disabling
      module clocks and disabling timers:
      
        # echo 0 > /sys/module/printk/parameters/console_suspend
        # echo platform > /sys/power/pm_test    # Or "processors"
        # echo mem > /sys/power/state
      
      (Make sure CONFIG_PCI_RCAR_GEN2 and CONFIG_USB_OHCI_HCD_PCI are enabled.)
      
      Rafael Wysocki agrees that PME scans should be suspended before the host
      bridge registers become inaccessible.  To that end, queue the task on a
      workqueue that gets frozen before devices suspend.
      
      Rafael notes however that as a result, some wakeup events may be missed if
      they are delivered via PME from a device without working IRQ (which hence
      must be polled) and occur after the workqueue has been frozen.  If that
      turns out to be an issue in practice, it may be possible to solve it by
      calling pci_pme_list_scan() once directly from one of the host bridge's
      pm_ops callbacks.
      
      Stacktrace for posterity:
      
        PM: Syncing filesystems ... [   38.566237] done.
        PM: Preparing system for sleep (mem)
        Freezing user space processes ... [   38.579813] (elapsed 0.001 seconds) done.
        Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
        PM: Suspending system (mem)
        PM: suspend of devices complete after 152.456 msecs
        PM: late suspend of devices complete after 2.809 msecs
        PM: noirq suspend of devices complete after 29.863 msecs
        suspend debug: Waiting for 5 second(s).
        Unhandled fault: asynchronous external abort (0x1211) at 0x00000000
        pgd = c0003000
        [00000000] *pgd=80000040004003, *pmd=00000000
        Internal error: : 1211 [#1] SMP ARM
        Modules linked in:
        CPU: 1 PID: 20 Comm: kworker/1:1 Not tainted
        4.9.0-rc1-koelsch-00011-g68db9bc8 #3383
        Hardware name: Generic R8A7791 (Flattened Device Tree)
        Workqueue: events pci_pme_list_scan
        task: eb56e140 task.stack: eb58e000
        PC is at pci_generic_config_read+0x64/0x6c
        LR is at rcar_pci_cfg_base+0x64/0x84
        pc : [<c041d7b4>]    lr : [<c04309a0>]    psr: 600d0093
        sp : eb58fe98  ip : c041d750  fp : 00000008
        r10: c0e2283c  r9 : 00000000  r8 : 600d0013
        r7 : 00000008  r6 : eb58fed6  r5 : 00000002  r4 : eb58feb4
        r3 : 00000000  r2 : 00000044  r1 : 00000008  r0 : 00000000
        Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
        Control: 30c5387d  Table: 6a9f6c80  DAC: 55555555
        Process kworker/1:1 (pid: 20, stack limit = 0xeb58e210)
        Stack: (0xeb58fe98 to 0xeb590000)
        fe80:                                                       00000002 00000044
        fea0: eb6f5800 c041d9b0 eb58feb4 00000008 00000044 00000000 eb78a000 eb78a000
        fec0: 00000044 00000000 eb9aff00 c0424bf0 eb78a000 00000000 eb78a000 c0e22830
        fee0: ea8a6fc0 c0424c5c eaae79c0 c0424ce0 eb55f380 c0e22838 eb9a9800 c0235fbc
        ff00: eb55f380 c0e22838 eb55f380 eb9a9800 eb9a9800 eb58e000 eb9a9824 c0e02100
        ff20: eb55f398 c02366c4 eb56e140 eb5631c0 00000000 eb55f380 c023641c 00000000
        ff40: 00000000 00000000 00000000 c023a928 cd105598 00000000 40506a34 eb55f380
        ff60: 00000000 00000000 dead4ead ffffffff ffffffff eb58ff74 eb58ff74 00000000
        ff80: 00000000 dead4ead ffffffff ffffffff eb58ff90 eb58ff90 eb58ffac eb5631c0
        ffa0: c023a844 00000000 00000000 c0206d68 00000000 00000000 00000000 00000000
        ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
        ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 3a81336c 10ccd1dd
        [<c041d7b4>] (pci_generic_config_read) from [<c041d9b0>]
        (pci_bus_read_config_word+0x58/0x80)
        [<c041d9b0>] (pci_bus_read_config_word) from [<c0424bf0>]
        (pci_check_pme_status+0x34/0x78)
        [<c0424bf0>] (pci_check_pme_status) from [<c0424c5c>] (pci_pme_wakeup+0x28/0x54)
        [<c0424c5c>] (pci_pme_wakeup) from [<c0424ce0>] (pci_pme_list_scan+0x58/0xb4)
        [<c0424ce0>] (pci_pme_list_scan) from [<c0235fbc>]
        (process_one_work+0x1bc/0x308)
        [<c0235fbc>] (process_one_work) from [<c02366c4>] (worker_thread+0x2a8/0x3e0)
        [<c02366c4>] (worker_thread) from [<c023a928>] (kthread+0xe4/0xfc)
        [<c023a928>] (kthread) from [<c0206d68>] (ret_from_fork+0x14/0x2c)
        Code: ea000000 e5903000 f57ff04f e3a00000 (e5843000)
        ---[ end trace 667d43ba3aa9e589 ]---
      
      Fixes: df17e62e ("PCI: Add support for polling PME state on suspended legacy PCI devices")
      Reported-and-tested-by: default avatarLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
      Reported-and-tested-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Acked-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
      Cc: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
      Cc: Simon Horman <horms+renesas@verge.net.au>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      [bwh: Backported to 3.2: adjust context, indentation]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      e8fba609
    • David Woodhouse's avatar
      PCI: Only allow WC mmap on prefetchable resources · 999df205
      David Woodhouse authored
      commit cef4d023 upstream.
      
      The /proc/bus/pci mmap interface allows the user to specify whether they
      want WC or not.  Don't let them do so on non-prefetchable BARs.
      Signed-off-by: default avatarDavid Woodhouse <dwmw@amazon.co.uk>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      999df205
    • David Woodhouse's avatar
      PCI: Fix another sanity check bug in /proc/pci mmap · 077b04d6
      David Woodhouse authored
      commit 17caf567 upstream.
      
      Don't match MMIO maps with I/O BARs and vice versa.
      Signed-off-by: default avatarDavid Woodhouse <dwmw@amazon.co.uk>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      077b04d6
    • Bjorn Helgaas's avatar
      PCI: Ignore write combining when mapping I/O port space · 727867ee
      Bjorn Helgaas authored
      commit 3a92c319 upstream.
      
      PCI exposes files like /proc/bus/pci/00/00.0 in procfs.  These files
      support operations like this:
      
        ioctl(fd, PCIIOC_MMAP_IS_IO);           # request I/O port space
        ioctl(fd, PCIIOC_WRITE_COMBINE, 1);     # request write-combining
        mmap(fd, ...)
      
      Write combining is useful on PCI memory space, but I don't think it makes
      sense on PCI I/O port space.
      
      We *could* change proc_bus_pci_ioctl() to make it impossible to set
      mmap_state == pci_mmap_io and write_combine at the same time, but that
      would break the following sequence, which is currently legal:
      
        mmap(fd, ...)                           # default is I/O, non-combining
        ioctl(fd, PCIIOC_WRITE_COMBINE, 1);     # request write-combining
        ioctl(fd, PCIIOC_MMAP_IS_MEM);          # request memory space
        mmap(fd, ...)                           # get write-combining mapping
      
      Ignore the write-combining flag when mapping I/O port space.
      
      This patch should have no functional effect, based on this analysis of all
      implementations of pci_mmap_page_range():
      
        - ia64 mips parisc sh unicore32 x86 do not support mapping of I/O port
          space at all.
      
        - arm cris microblaze mn10300 sparc xtensa support mapping of I/O port
          space, but ignore the write_combine argument to pci_mmap_page_range().
      
        - powerpc supports mapping of I/O port space and uses write_combine, and
          it disables write combining for I/O port space in
          __pci_mmap_set_pgprot().
      
      This patch makes it possible to remove __pci_mmap_set_pgprot() from
      powerpc, which simplifies that path.
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      727867ee
    • Alyssa Milburn's avatar
      zr364xx: enforce minimum size when reading header · e674844a
      Alyssa Milburn authored
      commit ee0fe833 upstream.
      
      This code copies actual_length-128 bytes from the header, which will
      underflow if the received buffer is too small.
      Signed-off-by: default avatarAlyssa Milburn <amilburn@zall.org>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      [bwh: Backported to 3.2: adjust filename]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      e674844a
    • Alyssa Milburn's avatar
      digitv: limit messages to buffer size · 1a4b6a9a
      Alyssa Milburn authored
      commit 821117dc upstream.
      
      Return an error rather than memcpy()ing beyond the end of the buffer.
      Internal callers use appropriate sizes, but digitv_i2c_xfer may not.
      Signed-off-by: default avatarAlyssa Milburn <amilburn@zall.org>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@s-opensource.com>
      [bwh: Backported to 3.2: adjust filename, context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      1a4b6a9a
    • David Woodhouse's avatar
      PCI: Fix pci_mmap_fits() for HAVE_PCI_RESOURCE_TO_USER platforms · b0531078
      David Woodhouse authored
      commit 6bccc7f4 upstream.
      
      In the PCI_MMAP_PROCFS case when the address being passed by the user is a
      'user visible' resource address based on the bus window, and not the actual
      contents of the resource, that's what we need to be checking it against.
      Signed-off-by: default avatarDavid Woodhouse <dwmw@amazon.co.uk>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      [bwh: Backported to 3.2: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      b0531078