1. 15 9月, 2018 1 次提交
  2. 08 8月, 2018 1 次提交
  3. 20 7月, 2018 1 次提交
  4. 07 7月, 2018 2 次提交
  5. 05 6月, 2018 3 次提交
  6. 08 5月, 2018 2 次提交
  7. 05 3月, 2018 1 次提交
  8. 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
  9. 22 12月, 2017 1 次提交
  10. 06 12月, 2017 1 次提交
  11. 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
  12. 03 10月, 2017 1 次提交
  13. 06 9月, 2017 2 次提交
  14. 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
  15. 11 8月, 2017 1 次提交
  16. 10 8月, 2017 1 次提交
  17. 03 8月, 2017 1 次提交
  18. 05 6月, 2017 1 次提交
  19. 25 5月, 2017 1 次提交
  20. 25 4月, 2017 1 次提交
  21. 04 4月, 2017 1 次提交
  22. 09 3月, 2017 5 次提交
  23. 17 1月, 2017 1 次提交
  24. 12 1月, 2017 1 次提交
  25. 11 1月, 2017 1 次提交
  26. 03 1月, 2017 1 次提交
    • I
      flow_dissector: Update pptp handling to avoid null pointer deref. · d0af6834
      Ian Kumlien 提交于
      __skb_flow_dissect can be called with a skb or a data packet, either
      can be NULL. All calls seems to have been moved to __skb_header_pointer
      except the pptp handling which is still calling skb_header_pointer.
      
      skb_header_pointer will use skb->data and thus:
      [  109.556866] BUG: unable to handle kernel NULL pointer dereference at 0000000000000080
      [  109.557102] IP: [<ffffffff88dc02f8>] __skb_flow_dissect+0xa88/0xce0
      [  109.557263] PGD 0
      [  109.557338]
      [  109.557484] Oops: 0000 [#1] SMP
      [  109.557562] Modules linked in: chaoskey
      [  109.557783] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.9.0 #79
      [  109.557867] Hardware name: Supermicro A1SRM-LN7F/LN5F/A1SRM-LN7F-2758, BIOS 1.0c 11/04/2015
      [  109.557957] task: ffff94085c27bc00 task.stack: ffffb745c0068000
      [  109.558041] RIP: 0010:[<ffffffff88dc02f8>]  [<ffffffff88dc02f8>] __skb_flow_dissect+0xa88/0xce0
      [  109.558203] RSP: 0018:ffff94087fc83d40  EFLAGS: 00010206
      [  109.558286] RAX: 0000000000000130 RBX: ffffffff8975bf80 RCX: ffff94084fab6800
      [  109.558373] RDX: 0000000000000010 RSI: 000000000000000c RDI: 0000000000000000
      [  109.558460] RBP: 0000000000000b88 R08: 0000000000000000 R09: 0000000000000022
      [  109.558547] R10: 0000000000000008 R11: ffff94087fc83e04 R12: 0000000000000000
      [  109.558763] R13: ffff94084fab6800 R14: ffff94087fc83e04 R15: 000000000000002f
      [  109.558979] FS:  0000000000000000(0000) GS:ffff94087fc80000(0000) knlGS:0000000000000000
      [  109.559326] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  109.559539] CR2: 0000000000000080 CR3: 0000000281809000 CR4: 00000000001026e0
      [  109.559753] Stack:
      [  109.559957]  000000000000000c ffff94084fab6822 0000000000000001 ffff94085c2b5fc0
      [  109.560578]  0000000000000001 0000000000002000 0000000000000000 0000000000000000
      [  109.561200]  0000000000000000 0000000000000000 0000000000000000 0000000000000000
      [  109.561820] Call Trace:
      [  109.562027]  <IRQ>
      [  109.562108]  [<ffffffff88dfb4fa>] ? eth_get_headlen+0x7a/0xf0
      [  109.562522]  [<ffffffff88c5a35a>] ? igb_poll+0x96a/0xe80
      [  109.562737]  [<ffffffff88dc912b>] ? net_rx_action+0x20b/0x350
      [  109.562953]  [<ffffffff88546d68>] ? __do_softirq+0xe8/0x280
      [  109.563169]  [<ffffffff8854704a>] ? irq_exit+0xaa/0xb0
      [  109.563382]  [<ffffffff8847229b>] ? do_IRQ+0x4b/0xc0
      [  109.563597]  [<ffffffff8902d4ff>] ? common_interrupt+0x7f/0x7f
      [  109.563810]  <EOI>
      [  109.563890]  [<ffffffff88d57530>] ? cpuidle_enter_state+0x130/0x2c0
      [  109.564304]  [<ffffffff88d57520>] ? cpuidle_enter_state+0x120/0x2c0
      [  109.564520]  [<ffffffff8857eacf>] ? cpu_startup_entry+0x19f/0x1f0
      [  109.564737]  [<ffffffff8848d55a>] ? start_secondary+0x12a/0x140
      [  109.564950] Code: 83 e2 20 a8 80 0f 84 60 01 00 00 c7 04 24 08 00
      00 00 66 85 d2 0f 84 be fe ff ff e9 69 fe ff ff 8b 34 24 89 f2 83 c2
      04 66 85 c0 <41> 8b 84 24 80 00 00 00 0f 49 d6 41 8d 31 01 d6 41 2b 84
      24 84
      [  109.569959] RIP  [<ffffffff88dc02f8>] __skb_flow_dissect+0xa88/0xce0
      [  109.570245]  RSP <ffff94087fc83d40>
      [  109.570453] CR2: 0000000000000080
      
      Fixes: ab10dccb ("rps: Inspect PPTP encapsulated by GRE to get flow hash")
      Signed-off-by: NIan Kumlien <ian.kumlien@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d0af6834
  27. 09 12月, 2016 1 次提交
  28. 23 11月, 2016 1 次提交
  29. 13 11月, 2016 1 次提交
  30. 30 10月, 2016 1 次提交
  31. 28 10月, 2016 1 次提交
    • A
      flow_dissector: fix vlan tag handling · bc72f3dd
      Arnd Bergmann 提交于
      gcc warns about an uninitialized pointer dereference in the vlan
      priority handling:
      
      net/core/flow_dissector.c: In function '__skb_flow_dissect':
      net/core/flow_dissector.c:281:61: error: 'vlan' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      
      As pointed out by Jiri Pirko, the variable is never actually used
      without being initialized first as the only way it end up uninitialized
      is with skb_vlan_tag_present(skb)==true, and that means it does not
      get accessed.
      
      However, the warning hints at some related issues that I'm addressing
      here:
      
      - the second check for the vlan tag is different from the first one
        that tests the skb for being NULL first, causing both the warning
        and a possible NULL pointer dereference that was not entirely fixed.
      - The same patch that introduced the NULL pointer check dropped an
        earlier optimization that skipped the repeated check of the
        protocol type
      - The local '_vlan' variable is referenced through the 'vlan' pointer
        but the variable has gone out of scope by the time that it is
        accessed, causing undefined behavior
      
      Caching the result of the 'skb && skb_vlan_tag_present(skb)' check
      in a local variable allows the compiler to further optimize the
      later check. With those changes, the warning also disappears.
      
      Fixes: 3805a938 ("flow_dissector: Check skb for VLAN only if skb specified.")
      Fixes: d5709f7a ("flow_dissector: For stripped vlan, get vlan info from skb->vlan_tci")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Acked-by: NEric Garver <e@erig.me>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bc72f3dd