1. 27 Jan, 2016 4 commits
    • Bjørn Mork's avatar
      net: cdc_ncm: avoid changing RX/TX buffers on MTU changes · 4ed7bdb8
      Bjørn Mork authored
      [ Upstream commit 1dfddff5 ]
      
      NCM buffer sizes are negotiated with the device independently of
      the network device MTU.  The RX buffers are allocated by the
      usbnet framework based on the rx_urb_size value set by cdc_ncm. A
      single RX buffer can hold a number of MTU sized packets.
      
      The default usbnet change_mtu ndo only modifies rx_urb_size if it
      is equal to hard_mtu.  And the cdc_ncm driver will set rx_urb_size
      and hard_mtu independently of each other, based on dwNtbInMaxSize
      and dwNtbOutMaxSize respectively. It was therefore assumed that
      usbnet_change_mtu() would never touch rx_urb_size.  This failed to
      consider the case where dwNtbInMaxSize and dwNtbOutMaxSize happens
      to be equal.
      
      Fix by implementing an NCM specific change_mtu ndo, modifying the
      netdev MTU without touching the buffer size settings.
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      4ed7bdb8
    • Vijay Pandurangan's avatar
      veth: don’t modify ip_summed; doing so treats packets with bad checksums as good. · 176489b0
      Vijay Pandurangan authored
      [ Upstream commit ce8c839b ]
      
      Packets that arrive from real hardware devices have ip_summed ==
      CHECKSUM_UNNECESSARY if the hardware verified the checksums, or
      CHECKSUM_NONE if the packet is bad or it was unable to verify it. The
      current version of veth will replace CHECKSUM_NONE with
      CHECKSUM_UNNECESSARY, which causes corrupt packets routed from hardware to
      a veth device to be delivered to the application. This caused applications
      at Twitter to receive corrupt data when network hardware was corrupting
      packets.
      
      We believe this was added as an optimization to skip computing and
      verifying checksums for communication between containers. However, locally
      generated packets have ip_summed == CHECKSUM_PARTIAL, so the code as
      written does nothing for them. As far as we can tell, after removing this
      code, these packets are transmitted from one stack to another unmodified
      (tcpdump shows invalid checksums on both sides, as expected), and they are
      delivered correctly to applications. We didn’t test every possible network
      configuration, but we tried a few common ones such as bridging containers,
      using NAT between the host and a container, and routing from hardware
      devices to containers. We have effectively deployed this in production at
      Twitter (by disabling RX checksum offloading on veth devices).
      
      This code dates back to the first version of the driver, commit
      <e314dbdc> ("[NET]: Virtual ethernet device driver"), so I
      suspect this bug occurred mostly because the driver API has evolved
      significantly since then. Commit <0b796750> ("net/veth: Fix
      packet checksumming") (in December 2010) fixed this for packets that get
      created locally and sent to hardware devices, by not changing
      CHECKSUM_PARTIAL. However, the same issue still occurs for packets coming
      in from hardware devices.
      Co-authored-by: default avatarEvan Jones <ej@evanjones.ca>
      Signed-off-by: default avatarEvan Jones <ej@evanjones.ca>
      Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
      Cc: Phil Sutter <phil@nwl.cc>
      Cc: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
      Cc: netdev@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarVijay Pandurangan <vijayp@vijayp.ca>
      Acked-by: default avatarCong Wang <cwang@twopensource.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      176489b0
    • Trond Myklebust's avatar
      NFS: Ensure we revalidate attributes before using execute_ok() · 53b51ca1
      Trond Myklebust authored
      commit 5c5fc09a upstream.
      
      Donald Buczek reports that NFS clients can also report incorrect
      results for access() due to lack of revalidation of attributes
      before calling execute_ok().
      Looking closely, it seems chdir() is afflicted with the same problem.
      
      Fix is to ensure we call nfs_revalidate_inode_rcu() or
      nfs_revalidate_inode() as appropriate before deciding to trust
      execute_ok().
      Reported-by: default avatarDonald Buczek <buczek@molgen.mpg.de>
      Link: http://lkml.kernel.org/r/1451331530-3748-1-git-send-email-buczek@molgen.mpg.deSigned-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      53b51ca1
    • Trond Myklebust's avatar
      NFSv4: Don't perform cached access checks before we've OPENed the file · 9ddd9c61
      Trond Myklebust authored
      commit 762674f8 upstream.
      
      Donald Buczek reports that a nfs4 client incorrectly denies
      execute access based on outdated file mode (missing 'x' bit).
      After the mode on the server is 'fixed' (chmod +x) further execution
      attempts continue to fail, because the nfs ACCESS call updates
      the access parameter but not the mode parameter or the mode in
      the inode.
      
      The root cause is ultimately that the VFS is calling may_open()
      before the NFS client has a chance to OPEN the file and hence revalidate
      the access and attribute caches.
      
      Al Viro suggests:
      >>> Make nfs_permission() relax the checks when it sees MAY_OPEN, if you know
      >>> that things will be caught by server anyway?
      >>
      >> That can work as long as we're guaranteed that everything that calls
      >> inode_permission() with MAY_OPEN on a regular file will also follow up
      >> with a vfs_open() or dentry_open() on success. Is this always the
      >> case?
      >
      > 1) in do_tmpfile(), followed by do_dentry_open() (not reachable by NFS since
      > it doesn't have ->tmpfile() instance anyway)
      >
      > 2) in atomic_open(), after the call of ->atomic_open() has succeeded.
      >
      > 3) in do_last(), followed on success by vfs_open()
      >
      > That's all.  All calls of inode_permission() that get MAY_OPEN come from
      > may_open(), and there's no other callers of that puppy.
      Reported-by: default avatarDonald Buczek <buczek@molgen.mpg.de>
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=109771
      Link: http://lkml.kernel.org/r/1451046656-26319-1-git-send-email-buczek@molgen.mpg.de
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      9ddd9c61
  2. 26 Jan, 2016 36 commits