1. 26 4月, 2019 1 次提交
  2. 24 4月, 2019 3 次提交
  3. 03 4月, 2019 2 次提交
  4. 28 3月, 2019 1 次提交
  5. 29 1月, 2019 1 次提交
  6. 08 12月, 2018 2 次提交
  7. 10 11月, 2018 1 次提交
    • flow_dissector: do not dissect l4 ports for fragments · 62230715
      배석진 提交于
      Only first fragment has the sport/dport information,
      not the following ones.
      
      If we want consistent hash for all fragments, we need to
      ignore ports even for first fragment.
      
      This bug is visible for IPv6 traffic, if incoming fragments
      do not have a flow label, since skb_get_hash() will give
      different results for first fragment and following ones.
      
      It is also visible if any routing rule wants dissection
      and sport or dport.
      
      See commit 5e5d6fed ("ipv6: route: dissect flow
      in input path if fib rules need it") for details.
      
      [edumazet] rewrote the changelog completely.
      
      Fixes: 06635a35 ("flow_dissect: use programable dissector in skb_flow_dissect and friends")
      Signed-off-by: N배석진 <soukjin.bae@samsung.com>
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      62230715
  8. 08 11月, 2018 1 次提交
  9. 25 9月, 2018 1 次提交
  10. 20 9月, 2018 1 次提交
  11. 15 9月, 2018 1 次提交
  12. 08 8月, 2018 1 次提交
  13. 20 7月, 2018 1 次提交
  14. 07 7月, 2018 2 次提交
  15. 05 6月, 2018 3 次提交
  16. 08 5月, 2018 2 次提交
  17. 05 3月, 2018 1 次提交
  18. 19 1月, 2018 1 次提交
    • E
      flow_dissector: properly cap thoff field · d0c081b4
      Eric Dumazet 提交于
      syzbot reported yet another crash [1] that is caused by
      insufficient validation of DODGY packets.
      
      Two bugs are happening here to trigger the crash.
      
      1) Flow dissection leaves with incorrect thoff field.
      
      2) skb_probe_transport_header() sets transport header to this invalid
      thoff, even if pointing after skb valid data.
      
      3) qdisc_pkt_len_init() reads out-of-bound data because it
      trusts tcp_hdrlen(skb)
      
      Possible fixes :
      
      - Full flow dissector validation before injecting bad DODGY packets in
      the stack.
       This approach was attempted here : https://patchwork.ozlabs.org/patch/
      861874/
      
      - Have more robust functions in the core.
        This might be needed anyway for stable versions.
      
      This patch fixes the flow dissection issue.
      
      [1]
      CPU: 1 PID: 3144 Comm: syzkaller271204 Not tainted 4.15.0-rc4-mm1+ #49
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:17 [inline]
       dump_stack+0x194/0x257 lib/dump_stack.c:53
       print_address_description+0x73/0x250 mm/kasan/report.c:256
       kasan_report_error mm/kasan/report.c:355 [inline]
       kasan_report+0x23b/0x360 mm/kasan/report.c:413
       __asan_report_load2_noabort+0x14/0x20 mm/kasan/report.c:432
       __tcp_hdrlen include/linux/tcp.h:35 [inline]
       tcp_hdrlen include/linux/tcp.h:40 [inline]
       qdisc_pkt_len_init net/core/dev.c:3160 [inline]
       __dev_queue_xmit+0x20d3/0x2200 net/core/dev.c:3465
       dev_queue_xmit+0x17/0x20 net/core/dev.c:3554
       packet_snd net/packet/af_packet.c:2943 [inline]
       packet_sendmsg+0x3ad5/0x60a0 net/packet/af_packet.c:2968
       sock_sendmsg_nosec net/socket.c:628 [inline]
       sock_sendmsg+0xca/0x110 net/socket.c:638
       sock_write_iter+0x31a/0x5d0 net/socket.c:907
       call_write_iter include/linux/fs.h:1776 [inline]
       new_sync_write fs/read_write.c:469 [inline]
       __vfs_write+0x684/0x970 fs/read_write.c:482
       vfs_write+0x189/0x510 fs/read_write.c:544
       SYSC_write fs/read_write.c:589 [inline]
       SyS_write+0xef/0x220 fs/read_write.c:581
       entry_SYSCALL_64_fastpath+0x1f/0x96
      
      Fixes: 34fad54c ("net: __skb_flow_dissect() must cap its return value")
      Fixes: a6e544b0 ("flow_dissector: Jump to exit code in __skb_flow_dissect")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Willem de Bruijn <willemb@google.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Acked-by: NJason Wang <jasowang@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d0c081b4
  19. 22 12月, 2017 1 次提交
  20. 06 12月, 2017 1 次提交
  21. 11 11月, 2017 1 次提交
    • J
      tipc: improve link resiliency when rps is activated · 8d6e79d3
      Jon Maloy 提交于
      Currently, the TIPC RPS dissector is based only on the incoming packets'
      source node address, hence steering all traffic from a node to the same
      core. We have seen that this makes the links vulnerable to starvation
      and unnecessary resets when we turn down the link tolerance to very low
      values.
      
      To reduce the risk of this happening, we exempt probe and probe replies
      packets from the convergence to one core per source node. Instead, we do
      the opposite, - we try to diverge those packets across as many cores as
      possible, by randomizing the flow selector key.
      
      To make such packets identifiable to the dissector, we add a new
      'is_keepalive' bit to word 0 of the LINK_PROTOCOL header. This bit is
      set both for PROBE and PROBE_REPLY messages, and only for those.
      
      It should be noted that these packets are not part of any flow anyway,
      and only constitute a minuscule fraction of all packets sent across a
      link. Hence, there is no risk that this will affect overall performance.
      Acked-by: NYing Xue <ying.xue@windriver.com>
      Signed-off-by: NJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8d6e79d3
  22. 03 10月, 2017 1 次提交
  23. 06 9月, 2017 2 次提交
  24. 16 8月, 2017 1 次提交
    • C
      dsa: fix flow disector null pointer · 7324157b
      Craig Gallek 提交于
      A recent change to fix up DSA device behavior made the assumption that
      all skbs passing through the flow disector will be associated with a
      device. This does not appear to be a safe assumption.  Syzkaller found
      the crash below by attaching a BPF socket filter that tries to find the
      payload offset of a packet passing between two unix sockets.
      
      kasan: GPF could be caused by NULL-ptr deref or user memory access
      general protection fault: 0000 [#1] SMP KASAN
      Dumping ftrace buffer:
         (ftrace buffer empty)
      Modules linked in:
      CPU: 0 PID: 2940 Comm: syzkaller872007 Not tainted 4.13.0-rc4-next-20170811 #1
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      task: ffff8801d1b425c0 task.stack: ffff8801d0bc0000
      RIP: 0010:__skb_flow_dissect+0xdcd/0x3ae0 net/core/flow_dissector.c:445
      RSP: 0018:ffff8801d0bc7340 EFLAGS: 00010206
      RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
      RDX: 0000000000000060 RSI: ffffffff856dc080 RDI: 0000000000000300
      RBP: ffff8801d0bc7870 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000008 R11: ffffed003a178f1e R12: 0000000000000000
      R13: 0000000000000000 R14: ffffffff856dc080 R15: ffff8801ce223140
      FS:  00000000016ed880(0000) GS:ffff8801dc000000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000020008000 CR3: 00000001ce22d000 CR4: 00000000001406f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       skb_flow_dissect_flow_keys include/linux/skbuff.h:1176 [inline]
       skb_get_poff+0x9a/0x1a0 net/core/flow_dissector.c:1079
       ______skb_get_pay_offset net/core/filter.c:114 [inline]
       __skb_get_pay_offset+0x15/0x20 net/core/filter.c:112
      Code: 80 3c 02 00 44 89 6d 10 0f 85 44 2b 00 00 4d 8b 67 20 48 b8 00 00 00 00 00 fc ff df 49 8d bc 24 00 03 00 00 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 13 2b 00 00 4d 8b a4 24 00 03 00 00 4d 85 e4
      RIP: __skb_flow_dissect+0xdcd/0x3ae0 net/core/flow_dissector.c:445 RSP: ffff8801d0bc7340
      
      Fixes: 43e66528 ("net-next: dsa: fix flow dissection")
      Reported-by: NDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: NCraig Gallek <kraig@google.com>
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7324157b
  25. 11 8月, 2017 1 次提交
  26. 10 8月, 2017 1 次提交
  27. 03 8月, 2017 1 次提交
  28. 05 6月, 2017 1 次提交
  29. 25 5月, 2017 1 次提交
  30. 25 4月, 2017 1 次提交
  31. 04 4月, 2017 1 次提交