1. 07 5月, 2015 2 次提交
  2. 21 4月, 2015 5 次提交
  3. 16 4月, 2015 1 次提交
  4. 15 4月, 2015 4 次提交
  5. 11 4月, 2015 2 次提交
  6. 07 4月, 2015 12 次提交
  7. 06 4月, 2015 2 次提交
  8. 04 4月, 2015 2 次提交
  9. 03 4月, 2015 2 次提交
    • J
      xen-netfront: transmit fully GSO-sized packets · 0c36820e
      Jonathan Davies 提交于
      xen-netfront limits transmitted skbs to be at most 44 segments in size. However,
      GSO permits up to 65536 bytes, which means a maximum of 45 segments of 1448
      bytes each. This slight reduction in the size of packets means a slight loss in
      efficiency.
      
      Since c/s 9ecd1a75, xen-netfront sets gso_max_size to
          XEN_NETIF_MAX_TX_SIZE - MAX_TCP_HEADER,
      where XEN_NETIF_MAX_TX_SIZE is 65535 bytes.
      
      The calculation used by tcp_tso_autosize (and also tcp_xmit_size_goal since c/s
      6c09fa09) in determining when to split an skb into two is
          sk->sk_gso_max_size - 1 - MAX_TCP_HEADER.
      
      So the maximum permitted size of an skb is calculated to be
          (XEN_NETIF_MAX_TX_SIZE - MAX_TCP_HEADER) - 1 - MAX_TCP_HEADER.
      
      Intuitively, this looks like the wrong formula -- we don't need two TCP headers.
      Instead, there is no need to deviate from the default gso_max_size of 65536 as
      this already accommodates the size of the header.
      
      Currently, the largest skb transmitted by netfront is 63712 bytes (44 segments
      of 1448 bytes each), as observed via tcpdump. This patch makes netfront send
      skbs of up to 65160 bytes (45 segments of 1448 bytes each).
      
      Similarly, the maximum allowable mtu does not need to subtract MAX_TCP_HEADER as
      it relates to the size of the whole packet, including the header.
      
      Fixes: 9ecd1a75 ("xen-netfront: reduce gso_max_size to account for max TCP header")
      Signed-off-by: NJonathan Davies <jonathan.davies@citrix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0c36820e
    • S
      IB/uverbs: Prevent integer overflow in ib_umem_get address arithmetic · 8494057a
      Shachar Raindel 提交于
      Properly verify that the resulting page aligned end address is larger
      than both the start address and the length of the memory area requested.
      
      Both the start and length arguments for ib_umem_get are controlled by
      the user. A misbehaving user can provide values which will cause an
      integer overflow when calculating the page aligned end address.
      
      This overflow can cause also miscalculation of the number of pages
      mapped, and additional logic issues.
      
      Addresses: CVE-2014-8159
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NShachar Raindel <raindel@mellanox.com>
      Signed-off-by: NJack Morgenstein <jackm@mellanox.com>
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      8494057a
  10. 02 4月, 2015 8 次提交