1. 30 Oct, 2010 4 commits
    • Clemens Ladisch's avatar
      firewire: ohci: fix race when reading count in AR descriptor · 693fa779
      Clemens Ladisch authored
      If the controller is storing a split packet and therefore changing
      d->res_count to zero between the two reads by the driver, we end up with
      an end pointer that is not at a packet boundary, and therefore overflow
      the buffer when handling the split packet.
      
      To fix this, read the field once, atomically.  The compiler usually
      merges the two reads anyway, but for correctness, we have to enforce it.
      Signed-off-by: default avatarClemens Ladisch <clemens@ladisch.de>
      Tested-by: default avatarMaxim Levitsky <maximlevitsky@gmail.com>
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      693fa779
    • Clemens Ladisch's avatar
      firewire: ohci: avoid reallocation of AR buffers · 837596a6
      Clemens Ladisch authored
      Freeing an AR buffer page just to allocate a new page immediately
      afterwards is not only a pointless effort but also dangerous because
      the allocation can fail, which would result in an oops later.
      
      Split ar_context_add_page() into two functions so that we can reuse
      the old page directly.
      Signed-off-by: default avatarClemens Ladisch <clemens@ladisch.de>
      Tested-by: default avatarMaxim Levitsky <maximlevitsky@gmail.com>
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      837596a6
    • Clemens Ladisch's avatar
      firewire: ohci: fix race in AR split packet handling · a1f805e5
      Clemens Ladisch authored
      When handling an AR buffer that has been completely filled, we assumed
      that its descriptor will not be read by the controller and can be
      overwritten.  However, when the last received packet happens to end at
      the end of the buffer, the controller might not yet have moved on to the
      next buffer and might read the branch address later.  If we overwrite
      and free the page before that, the DMA context will either go dead
      because of an invalid Z value, or go off into some random memory.
      
      To fix this, ensure that the descriptor does not get overwritten by
      using only the actual buffer instead of the entire page for reassembling
      the split packet.  Furthermore, to avoid freeing the page too early,
      move on to the next buffer only when some data in it guarantees that the
      controller has moved on.
      
      This should eliminate the remaining firewire-net problems.
      Signed-off-by: default avatarClemens Ladisch <clemens@ladisch.de>
      Cc: 2.6.22-2.6.36 <stable@kernel.org>
      Tested-by: default avatarMaxim Levitsky <maximlevitsky@gmail.com>
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      a1f805e5
    • Clemens Ladisch's avatar
      firewire: ohci: fix buffer overflow in AR split packet handling · 85f7ffd5
      Clemens Ladisch authored
      When the controller had to split a received asynchronous packet into two
      buffers, the driver tries to reassemble it by copying both parts into
      the first page.  However, if size + rest > PAGE_SIZE, i.e., if the yet
      unhandled packets before the split packet, the split packet itself, and
      any received packets after the split packet are together larger than one
      page, then the memory after the first page would get overwritten.
      
      To fix this, do not try to copy the data of all unhandled packets at
      once, but copy the possibly needed data every time when handling
      a packet.
      
      This gets rid of most of the infamous crashes and data corruptions when
      using firewire-net.
      Signed-off-by: default avatarClemens Ladisch <clemens@ladisch.de>
      Cc: 2.6.22-2.6.36 <stable@kernel.org>
      Tested-by: default avatarMaxim Levitsky <maximlevitsky@gmail.com>
      Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (cast PAGE_SIZE to size_t)
      85f7ffd5
  2. 20 Oct, 2010 5 commits
  3. 19 Oct, 2010 7 commits
  4. 18 Oct, 2010 18 commits
  5. 17 Oct, 2010 4 commits
  6. 16 Oct, 2010 2 commits