1. 07 Nov, 2016 35 commits
  2. 04 Nov, 2016 2 commits
    • Niklas Cassel's avatar
      PCI: designware: Check for iATU unroll support after initializing host · 416379f9
      Niklas Cassel authored
      dw_pcie_iatu_unroll_enabled() reads a dbi_base register.  Reading any
      dbi_base register before pp->ops->host_init has been called causes
      "imprecise external abort" on platforms like ARTPEC-6, where the PCIe
      module is disabled at boot and first enabled in pp->ops->host_init.  Move
      dw_pcie_iatu_unroll_enabled() to dw_pcie_setup_rc(), since it is after
      pp->ops->host_init, but before pp->iatu_unroll_enabled is actually used.
      Fixes: a0601a47
       ("PCI: designware: Add iATU Unroll feature")
      Tested-by: default avatarJames Le Cuirot <chewi@gentoo.org>
      Signed-off-by: default avatarNiklas Cassel <niklas.cassel@axis.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarJoao Pinto <jpinto@synopsys.com>
      Acked-by: default avatarOlof Johansson <olof@lixom.net>
    • Vladimir Zapolskiy's avatar
      i2c: core: fix NULL pointer dereference under race condition · 147b36d5
      Vladimir Zapolskiy authored
      Race condition between registering an I2C device driver and
      deregistering an I2C adapter device which is assumed to manage that
      I2C device may lead to a NULL pointer dereference due to the
      uninitialized list head of driver clients.
      The root cause of the issue is that the I2C bus may know about the
      registered device driver and thus it is matched by bus_for_each_drv(),
      but the list of clients is not initialized and commonly it is NULL,
      because I2C device drivers define struct i2c_driver as static and
      clients field is expected to be initialized by I2C core:
        i2c_register_driver()             i2c_del_adapter()
          driver_register()                 ...
            bus_add_driver()                ...
              ...                           bus_for_each_drv(..., __process_removed_adapter)
            ...                               i2c_do_del_adapter()
          ...                                   list_for_each_entry_safe(..., &driver->clients, ...)
      To solve the problem it is sufficient to do clients list head
      initialization before calling driver_register().
      The problem was found while using an I2C device driver with a sluggish
      registration routine on a bus provided by a physically detachable I2C
      master controller, but practically the oops may be reproduced under
      the race between arbitraty I2C device driver registration and managing
      I2C bus device removal e.g. by unbinding the latter over sysfs:
      % echo 21a4000.i2c > /sys/bus/platform/drivers/imx-i2c/unbind
        Unable to handle kernel NULL pointer dereference at virtual address 00000000
        Internal error: Oops: 17 [#1] SMP ARM
        CPU: 2 PID: 533 Comm: sh Not tainted 4.9.0-rc3+ #61
        Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
        task: e5ada400 task.stack: e4936000
        PC is at i2c_do_del_adapter+0x20/0xcc
        LR is at __process_removed_adapter+0x14/0x1c
        Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
        Control: 10c5387d  Table: 35bd004a  DAC: 00000051
        Process sh (pid: 533, stack limit = 0xe4936210)
        Stack: (0xe4937d28 to 0xe4938000)
        [<c0667be0>] (i2c_do_del_adapter) from [<c0667cc0>] (__process_removed_adapter+0x14/0x1c)
        [<c0667cac>] (__process_removed_adapter) from [<c0516998>] (bus_for_each_drv+0x6c/0xa0)
        [<c051692c>] (bus_for_each_drv) from [<c06685ec>] (i2c_del_adapter+0xbc/0x284)
        [<c0668530>] (i2c_del_adapter) from [<bf0110ec>] (i2c_imx_remove+0x44/0x164 [i2c_imx])
        [<bf0110a8>] (i2c_imx_remove [i2c_imx]) from [<c051a838>] (platform_drv_remove+0x2c/0x44)
        [<c051a80c>] (platform_drv_remove) from [<c05183d8>] (__device_release_driver+0x90/0x12c)
        [<c0518348>] (__device_release_driver) from [<c051849c>] (device_release_driver+0x28/0x34)
        [<c0518474>] (device_release_driver) from [<c0517150>] (unbind_store+0x80/0x104)
        [<c05170d0>] (unbind_store) from [<c0516520>] (drv_attr_store+0x28/0x34)
        [<c05164f8>] (drv_attr_store) from [<c0298acc>] (sysfs_kf_write+0x50/0x54)
        [<c0298a7c>] (sysfs_kf_write) from [<c029801c>] (kernfs_fop_write+0x100/0x214)
        [<c0297f1c>] (kernfs_fop_write) from [<c0220130>] (__vfs_write+0x34/0x120)
        [<c02200fc>] (__vfs_write) from [<c0221088>] (vfs_write+0xa8/0x170)
        [<c0220fe0>] (vfs_write) from [<c0221e74>] (SyS_write+0x4c/0xa8)
        [<c0221e28>] (SyS_write) from [<c0108a20>] (ret_fast_syscall+0x0/0x1c)
      Signed-off-by: default avatarVladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Cc: stable@kernel.org
  3. 03 Nov, 2016 3 commits
    • Stefan Richter's avatar
      firewire: net: fix fragmented datagram_size off-by-one · e9300a4b
      Stefan Richter authored
      RFC 2734 defines the datagram_size field in fragment encapsulation
      headers thus:
          datagram_size:  The encoded size of the entire IP datagram.  The
          value of datagram_size [...] SHALL be one less than the value of
          Total Length in the datagram's IP header (see STD 5, RFC 791).
      Accordingly, the eth1394 driver of Linux 2.6.36 and older set and got
      this field with a -/+1 offset:
          ether1394_tx() /* transmit */
                  hdr->ff.dg_size = dg_size - 1;
          ether1394_data_handler() /* receive */
              if (hdr->common.lf == ETH1394_HDR_LF_FF)
                  dg_size = hdr->ff.dg_size + 1;
                  dg_size = hdr->sf.dg_size + 1;
      Likewise, I observe OS X 10.4 and Windows XP Pro SP3 to transmit 1500
      byte sized datagrams in fragments with datagram_size=1499 if link
      fragmentation is required.
      Only firewire-net sets and gets datagram_size without this offset.  The
      result is lacking interoperability of firewire-net with OS X, Windows
      XP, and presumably Linux' eth1394.  (I did not test with the latter.)
      For example, FTP data transfers to a Linux firewire-net box with max_rec
      smaller than the 1500 bytes MTU
        - from OS X fail entirely,
        - from Win XP start out with a bunch of fragmented datagrams which
          time out, then continue with unfragmented datagrams because Win XP
          temporarily reduces the MTU to 576 bytes.
      So let's fix firewire-net's datagram_size accessors.
      Note that firewire-net thereby loses interoperability with unpatched
      firewire-net, but only if link fragmentation is employed.  (This happens
      with large broadcast datagrams, and with large datagrams on several
      FireWire CardBus cards with smaller max_rec than equivalent PCI cards,
      and it can be worked around by setting a small enough MTU.)
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
    • Stefan Richter's avatar
      firewire: net: guard against rx buffer overflows · 667121ac
      Stefan Richter authored
      The IP-over-1394 driver firewire-net lacked input validation when
      handling incoming fragmented datagrams.  A maliciously formed fragment
      with a respectively large datagram_offset would cause a memcpy past the
      datagram buffer.
      So, drop any packets carrying a fragment with offset + length larger
      than datagram_size.
      In addition, ensure that
        - GASP header, unfragmented encapsulation header, or fragment
          encapsulation header actually exists before we access it,
        - the encapsulated datagram or fragment is of nonzero size.
      Reported-by: default avatarEyal Itkin <eyal.itkin@gmail.com>
      Reviewed-by: default avatarEyal Itkin <eyal.itkin@gmail.com>
      Fixes: CVE 2016-8633
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
    • Gerd Hoffmann's avatar
      virtio-gpu: fix vblank events · eed6f0ed
      Gerd Hoffmann authored
      virtio-gpu sends vblank events in virtio_gpu_crtc_atomic_flush, and
      because of that it must be called for disabled planes too.  Ask
      drm_atomic_helper_commit_planes to do that.
      v2: update to use new drm_atomic_helper_commit_planes() API.
      Signed-off-by: default avatarGerd Hoffmann <kraxel@redhat.com>
      Signed-off-by: default avatarGustavo Padovan <gustavo.padovan@collabora.co.uk>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>