1. 24 3月, 2015 3 次提交
  2. 23 3月, 2015 1 次提交
  3. 21 3月, 2015 5 次提交
  4. 19 3月, 2015 6 次提交
  5. 18 3月, 2015 4 次提交
  6. 17 3月, 2015 1 次提交
  7. 15 3月, 2015 1 次提交
  8. 13 3月, 2015 5 次提交
  9. 12 3月, 2015 2 次提交
  10. 10 3月, 2015 2 次提交
    • F
      netfilter: fix sparse warnings in reject handling · a03a8dbe
      Florian Westphal 提交于
      make C=1 CF=-D__CHECK_ENDIAN__ shows following:
      
      net/bridge/netfilter/nft_reject_bridge.c:65:50: warning: incorrect type in argument 3 (different base types)
      net/bridge/netfilter/nft_reject_bridge.c:65:50:    expected restricted __be16 [usertype] protocol [..]
      net/bridge/netfilter/nft_reject_bridge.c:102:37: warning: cast from restricted __be16
      net/bridge/netfilter/nft_reject_bridge.c:102:37: warning: incorrect type in argument 1 (different base types) [..]
      net/bridge/netfilter/nft_reject_bridge.c:121:50: warning: incorrect type in argument 3 (different base types) [..]
      net/bridge/netfilter/nft_reject_bridge.c:168:52: warning: incorrect type in argument 3 (different base types) [..]
      net/bridge/netfilter/nft_reject_bridge.c:233:52: warning: incorrect type in argument 3 (different base types) [..]
      
      Caused by two (harmless) errors:
      1. htons() instead of ntohs()
      2. __be16 for protocol in nf_reject_ipXhdr_put API, use u8 instead.
      Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      a03a8dbe
    • E
      net: Remove protocol from struct dst_ops · ddb3b603
      Eric W. Biederman 提交于
      After my change to neigh_hh_init to obtain the protocol from the
      neigh_table there are no more users of protocol in struct dst_ops.
      Remove the protocol field from dst_ops and all of it's initializers.
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ddb3b603
  11. 09 3月, 2015 1 次提交
    • W
      ip: fix error queue empty skb handling · c247f053
      Willem de Bruijn 提交于
      When reading from the error queue, msg_name and msg_control are only
      populated for some errors. A new exception for empty timestamp skbs
      added a false positive on icmp errors without payload.
      
      `traceroute -M udpconn` only displayed gateways that return payload
      with the icmp error: the embedded network headers are pulled before
      sock_queue_err_skb, leaving an skb with skb->len == 0 otherwise.
      
      Fix this regression by refining when msg_name and msg_control
      branches are taken. The solutions for the two fields are independent.
      
      msg_name only makes sense for errors that configure serr->port and
      serr->addr_offset. Test the first instead of skb->len. This also fixes
      another issue. saddr could hold the wrong data, as serr->addr_offset
      is not initialized  in some code paths, pointing to the start of the
      network header. It is only valid when serr->port is set (non-zero).
      
      msg_control support differs between IPv4 and IPv6. IPv4 only honors
      requests for ICMP and timestamps with SOF_TIMESTAMPING_OPT_CMSG. The
      skb->len test can simply be removed, because skb->dev is also tested
      and never true for empty skbs. IPv6 honors requests for all errors
      aside from local errors and timestamps on empty skbs.
      
      In both cases, make the policy more explicit by moving this logic to
      a new function that decides whether to process msg_control and that
      optionally prepares the necessary fields in skb->cb[]. After this
      change, the IPv4 and IPv6 paths are more similar.
      
      The last case is rxrpc. Here, simply refine to only match timestamps.
      
      Fixes: 49ca0d8b ("net-timestamp: no-payload option")
      Reported-by: NJan Niehusmann <jan@gondor.com>
      Signed-off-by: NWillem de Bruijn <willemb@google.com>
      
      ----
      
      Changes
        v1->v2
        - fix local origin test inversion in ip6_datagram_support_cmsg
        - make v4 and v6 code paths more similar by introducing analogous
          ipv4_datagram_support_cmsg
        - fix compile bug in rxrpc
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c247f053
  12. 06 3月, 2015 1 次提交
  13. 05 3月, 2015 1 次提交
    • L
      net: ping: Return EAFNOSUPPORT when appropriate. · 9145736d
      Lorenzo Colitti 提交于
      1. For an IPv4 ping socket, ping_check_bind_addr does not check
         the family of the socket address that's passed in. Instead,
         make it behave like inet_bind, which enforces either that the
         address family is AF_INET, or that the family is AF_UNSPEC and
         the address is 0.0.0.0.
      2. For an IPv6 ping socket, ping_check_bind_addr returns EINVAL
         if the socket family is not AF_INET6. Return EAFNOSUPPORT
         instead, for consistency with inet6_bind.
      3. Make ping_v4_sendmsg and ping_v6_sendmsg return EAFNOSUPPORT
         instead of EINVAL if an incorrect socket address structure is
         passed in.
      4. Make IPv6 ping sockets be IPv6-only. The code does not support
         IPv4, and it cannot easily be made to support IPv4 because
         the protocol numbers for ICMP and ICMPv6 are different. This
         makes connect(::ffff:192.0.2.1) fail with EAFNOSUPPORT instead
         of making the socket unusable.
      
      Among other things, this fixes an oops that can be triggered by:
      
          int s = socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP);
          struct sockaddr_in6 sin6 = {
              .sin6_family = AF_INET6,
              .sin6_addr = in6addr_any,
          };
          bind(s, (struct sockaddr *) &sin6, sizeof(sin6));
      
      Change-Id: If06ca86d9f1e4593c0d6df174caca3487c57a241
      Signed-off-by: NLorenzo Colitti <lorenzo@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9145736d
  14. 04 3月, 2015 1 次提交
    • E
      neigh: Factor out ___neigh_lookup_noref · 60395a20
      Eric W. Biederman 提交于
      While looking at the mpls code I found myself writing yet another
      version of neigh_lookup_noref.  We currently have __ipv4_lookup_noref
      and __ipv6_lookup_noref.
      
      So to make my work a little easier and to make it a smidge easier to
      verify/maintain the mpls code in the future I stopped and wrote
      ___neigh_lookup_noref.  Then I rewote __ipv4_lookup_noref and
      __ipv6_lookup_noref in terms of this new function.  I tested my new
      version by verifying that the same code is generated in
      ip_finish_output2 and ip6_finish_output2 where these functions are
      inlined.
      
      To get to ___neigh_lookup_noref I added a new neighbour cache table
      function key_eq.  So that the static size of the key would be
      available.
      
      I also added __neigh_lookup_noref for people who want to to lookup
      a neighbour table entry quickly but don't know which neibhgour table
      they are going to look up.
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      60395a20
  15. 03 3月, 2015 4 次提交
    • M
      udp: only allow UFO for packets from SOCK_DGRAM sockets · acf8dd0a
      Michal Kubeček 提交于
      If an over-MTU UDP datagram is sent through a SOCK_RAW socket to a
      UFO-capable device, ip_ufo_append_data() sets skb->ip_summed to
      CHECKSUM_PARTIAL unconditionally as all GSO code assumes transport layer
      checksum is to be computed on segmentation. However, in this case,
      skb->csum_start and skb->csum_offset are never set as raw socket
      transmit path bypasses udp_send_skb() where they are usually set. As a
      result, driver may access invalid memory when trying to calculate the
      checksum and store the result (as observed in virtio_net driver).
      
      Moreover, the very idea of modifying the userspace provided UDP header
      is IMHO against raw socket semantics (I wasn't able to find a document
      clearly stating this or the opposite, though). And while allowing
      CHECKSUM_NONE in the UFO case would be more efficient, it would be a bit
      too intrusive change just to handle a corner case like this. Therefore
      disallowing UFO for packets from SOCK_DGRAM seems to be the best option.
      Signed-off-by: NMichal Kubecek <mkubecek@suse.cz>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      acf8dd0a
    • F
      netfilter: reject: don't send icmp error if csum is invalid · ee586bbc
      Florian Westphal 提交于
      tcp resets are never emitted if the packet that triggers the
      reject/reset has an invalid checksum.
      
      For icmp error responses there was no such check.
      It allows to distinguish icmp response generated via
      
      iptables -I INPUT -p udp --dport 42 -j REJECT
      
      and those emitted by network stack (won't respond if csum is invalid,
      REJECT does).
      
      Arguably its possible to avoid this by using conntrack and only
      using REJECT with -m conntrack NEW/RELATED.
      
      However, this doesn't work when connection tracking is not in use
      or when using nf_conntrack_checksum=0.
      
      Furthermore, sending errors in response to invalid csums doesn't make
      much sense so just add similar test as in nf_send_reset.
      
      Validate csum if needed and only send the response if it is ok.
      
      Reference: http://bugzilla.redhat.com/show_bug.cgi?id=1169829Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      ee586bbc
    • E
      neigh: Don't require dst in neigh_hh_init · bdf53c58
      Eric W. Biederman 提交于
      - Add protocol to neigh_tbl so that dst->ops->protocol is not needed
      - Acquire the device from neigh->dev
      
      This results in a neigh_hh_init that will cache the samve values
      regardless of the packets flowing through it.
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bdf53c58
    • Y
      net: Remove iocb argument from sendmsg and recvmsg · 1b784140
      Ying Xue 提交于
      After TIPC doesn't depend on iocb argument in its internal
      implementations of sendmsg() and recvmsg() hooks defined in proto
      structure, no any user is using iocb argument in them at all now.
      Then we can drop the redundant iocb argument completely from kinds of
      implementations of both sendmsg() and recvmsg() in the entire
      networking stack.
      
      Cc: Christoph Hellwig <hch@lst.de>
      Suggested-by: NAl Viro <viro@ZenIV.linux.org.uk>
      Signed-off-by: NYing Xue <ying.xue@windriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1b784140
  16. 02 3月, 2015 1 次提交
  17. 01 3月, 2015 1 次提交