1. 13 9月, 2013 6 次提交
    • D
      net: sctp: fix ipv6 ipsec encryption bug in sctp_v6_xmit · 95ee6208
      Daniel Borkmann 提交于
      Alan Chester reported an issue with IPv6 on SCTP that IPsec traffic is not
      being encrypted, whereas on IPv4 it is. Setting up an AH + ESP transport
      does not seem to have the desired effect:
      
      SCTP + IPv4:
      
        22:14:20.809645 IP (tos 0x2,ECT(0), ttl 64, id 0, offset 0, flags [DF], proto AH (51), length 116)
          192.168.0.2 > 192.168.0.5: AH(spi=0x00000042,sumlen=16,seq=0x1): ESP(spi=0x00000044,seq=0x1), length 72
        22:14:20.813270 IP (tos 0x2,ECT(0), ttl 64, id 0, offset 0, flags [DF], proto AH (51), length 340)
          192.168.0.5 > 192.168.0.2: AH(spi=0x00000043,sumlen=16,seq=0x1):
      
      SCTP + IPv6:
      
        22:31:19.215029 IP6 (class 0x02, hlim 64, next-header SCTP (132) payload length: 364)
          fe80::222:15ff:fe87:7fc.3333 > fe80::92e6:baff:fe0d:5a54.36767: sctp
          1) [INIT ACK] [init tag: 747759530] [rwnd: 62464] [OS: 10] [MIS: 10]
      
      Moreover, Alan says:
      
        This problem was seen with both Racoon and Racoon2. Other people have seen
        this with OpenSwan. When IPsec is configured to encrypt all upper layer
        protocols the SCTP connection does not initialize. After using Wireshark to
        follow packets, this is because the SCTP packet leaves Box A unencrypted and
        Box B believes all upper layer protocols are to be encrypted so it drops
        this packet, causing the SCTP connection to fail to initialize. When IPsec
        is configured to encrypt just SCTP, the SCTP packets are observed unencrypted.
      
      In fact, using `socat sctp6-listen:3333 -` on one end and transferring "plaintext"
      string on the other end, results in cleartext on the wire where SCTP eventually
      does not report any errors, thus in the latter case that Alan reports, the
      non-paranoid user might think he's communicating over an encrypted transport on
      SCTP although he's not (tcpdump ... -X):
      
        ...
        0x0030: 5d70 8e1a 0003 001a 177d eb6c 0000 0000  ]p.......}.l....
        0x0040: 0000 0000 706c 6169 6e74 6578 740a 0000  ....plaintext...
      
      Only in /proc/net/xfrm_stat we can see XfrmInTmplMismatch increasing on the
      receiver side. Initial follow-up analysis from Alan's bug report was done by
      Alexey Dobriyan. Also thanks to Vlad Yasevich for feedback on this.
      
      SCTP has its own implementation of sctp_v6_xmit() not calling inet6_csk_xmit().
      This has the implication that it probably never really got updated along with
      changes in inet6_csk_xmit() and therefore does not seem to invoke xfrm handlers.
      
      SCTP's IPv4 xmit however, properly calls ip_queue_xmit() to do the work. Since
      a call to inet6_csk_xmit() would solve this problem, but result in unecessary
      route lookups, let us just use the cached flowi6 instead that we got through
      sctp_v6_get_dst(). Since all SCTP packets are being sent through sctp_packet_transmit(),
      we do the route lookup / flow caching in sctp_transport_route(), hold it in
      tp->dst and skb_dst_set() right after that. If we would alter fl6->daddr in
      sctp_v6_xmit() to np->opt->srcrt, we possibly could run into the same effect
      of not having xfrm layer pick it up, hence, use fl6_update_dst() in sctp_v6_get_dst()
      instead to get the correct source routed dst entry, which we assign to the skb.
      
      Also source address routing example from 62503411 ("sctp: fix sctp to work with
      ipv6 source address routing") still works with this patch! Nevertheless, in RFC5095
      it is actually 'recommended' to not use that anyway due to traffic amplification [1].
      So it seems we're not supposed to do that anyway in sctp_v6_xmit(). Moreover, if
      we overwrite the flow destination here, the lower IPv6 layer will be unable to
      put the correct destination address into IP header, as routing header is added in
      ipv6_push_nfrag_opts() but then probably with wrong final destination. Things aside,
      result of this patch is that we do not have any XfrmInTmplMismatch increase plus on
      the wire with this patch it now looks like:
      
      SCTP + IPv6:
      
        08:17:47.074080 IP6 2620:52:0:102f:7a2b:cbff:fe27:1b0a > 2620:52:0:102f:213:72ff:fe32:7eba:
          AH(spi=0x00005fb4,seq=0x1): ESP(spi=0x00005fb5,seq=0x1), length 72
        08:17:47.074264 IP6 2620:52:0:102f:213:72ff:fe32:7eba > 2620:52:0:102f:7a2b:cbff:fe27:1b0a:
          AH(spi=0x00003d54,seq=0x1): ESP(spi=0x00003d55,seq=0x1), length 296
      
      This fixes Kernel Bugzilla 24412. This security issue seems to be present since
      2.6.18 kernels. Lets just hope some big passive adversary in the wild didn't have
      its fun with that. lksctp-tools IPv6 regression test suite passes as well with
      this patch.
      
       [1] http://www.secdev.org/conf/IPv6_RH_security-csw07.pdfReported-by: NAlan Chester <alan.chester@tekelec.com>
      Reported-by: NAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
      Cc: Steffen Klassert <steffen.klassert@secunet.com>
      Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
      Acked-by: NVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      95ee6208
    • J
      tuntap: correctly handle error in tun_set_iff() · 662ca437
      Jason Wang 提交于
      Commit c8d68e6b
      (tuntap: multiqueue support) only call free_netdev() on error in
      tun_set_iff(). This causes several issues:
      
      - memory of tun security were leaked
      - use after free since the flow gc timer was not deleted and the tfile
        were not detached
      
      This patch solves the above issues.
      Reported-by: NWannes Rombouts <wannes.rombouts@epitech.eu>
      Cc: Michael S. Tsirkin <mst@redhat.com>
      Signed-off-by: NJason Wang <jasowang@redhat.com>
      Acked-by: NMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      662ca437
    • K
      xen-netback: fix possible format string flaw · a9677bc0
      Kees Cook 提交于
      This makes sure a format string cannot accidentally leak into the
      kthread_run() call.
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Acked-by: NIan Campbell <ian.campbell@citrix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a9677bc0
    • S
      netpoll: Should handle ETH_P_ARP other than ETH_P_IP in netpoll_neigh_reply · b0dd663b
      Sonic Zhang 提交于
      The received ARP request type in the Ethernet packet head is ETH_P_ARP other than ETH_P_IP.
      
      [ Bug introduced by commit b7394d24
        ("netpoll: prepare for ipv6") ]
      Signed-off-by: NSonic Zhang <sonic.zhang@analog.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b0dd663b
    • F
      igb: Read flow control for i350 from correct EEPROM section · c7cb020d
      Fujinaka, Todd 提交于
      Flow control is defined in the four EEPROM sections but the driver only reads
      from section 0.
      Signed-off-by: NTodd Fujinaka <todd.fujinaka@intel.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c7cb020d
    • C
      igb: Add additional get_phy_id call for i354 devices · bb1d18d1
      Carolyn Wyborny 提交于
      This patch fixes a problem where some ports can fail to initialize on a
      cold boot. This patch adds an additional call to read the PHY id for i354
      devices in order workaround the hardware problem.
      Signed-off-by: NCarolyn Wyborny <carolyn.wyborny@intel.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bb1d18d1
  2. 12 9月, 2013 34 次提交