1. 06 9月, 2017 2 次提交
  2. 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
  3. 11 8月, 2017 1 次提交
  4. 10 8月, 2017 1 次提交
  5. 03 8月, 2017 1 次提交
  6. 05 6月, 2017 1 次提交
  7. 25 5月, 2017 1 次提交
  8. 25 4月, 2017 1 次提交
  9. 04 4月, 2017 1 次提交
  10. 09 3月, 2017 5 次提交
  11. 17 1月, 2017 1 次提交
  12. 12 1月, 2017 1 次提交
  13. 11 1月, 2017 1 次提交
  14. 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
  15. 09 12月, 2016 1 次提交
  16. 23 11月, 2016 1 次提交
  17. 13 11月, 2016 1 次提交
  18. 30 10月, 2016 1 次提交
  19. 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
  20. 19 10月, 2016 1 次提交
  21. 02 9月, 2016 1 次提交
  22. 19 8月, 2016 2 次提交
    • H
      flow_dissector: Get vlan priority in addition to vlan id · f6a66927
      Hadar Hen Zion 提交于
      Add vlan priority check to the flow dissector by adding new flow
      dissector struct, flow_dissector_key_vlan which includes vlan tag
      fields.
      
      vlan_id and flow_label fields were under the same struct
      (flow_dissector_key_tags). It was a convenient setting since struct
      flow_dissector_key_tags is used by struct flow_keys and by setting
      vlan_id and flow_label under the same struct, we get precisely 24 or 48
      bytes in flow_keys from flow_dissector_key_basic.
      
      Now, when adding vlan priority support, the code will be cleaner if
      flow_label and vlan tag won't be under the same struct anymore.
      Signed-off-by: NHadar Hen Zion <hadarh@mellanox.com>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f6a66927
    • H
      flow_dissector: For stripped vlan, get vlan info from skb->vlan_tci · d5709f7a
      Hadar Hen Zion 提交于
      Early in the datapath skb_vlan_untag function is called, stripped
      the vlan from the skb and set skb->vlan_tci and skb->vlan_proto fields.
      
      The current dissection doesn't handle stripped vlan packets correctly.
      In some flows, vlan doesn't exist in skb->data anymore when applying
      flow dissection on the skb, fix that.
      
      In case vlan info wasn't stripped before applying flow_dissector (RPS
      flow for example), or in case of skb with multiple vlans (e.g. 802.1ad),
      get the vlan info from skb->data. The flow_dissector correctly skips
      any number of vlans and stores only the first level vlan.
      
      Fixes: 0744dd00 ('net: introduce skb_flow_dissect()')
      Signed-off-by: NHadar Hen Zion <hadarh@mellanox.com>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d5709f7a
  23. 11 8月, 2016 1 次提交
  24. 02 7月, 2016 1 次提交
    • D
      packet: Use symmetric hash for PACKET_FANOUT_HASH. · eb70db87
      David S. Miller 提交于
      People who use PACKET_FANOUT_HASH want a symmetric hash, meaning that
      they want packets going in both directions on a flow to hash to the
      same bucket.
      
      The core kernel SKB hash became non-symmetric when the ipv6 flow label
      and other entities were incorporated into the standard flow hash order
      to increase entropy.
      
      But there are no users of PACKET_FANOUT_HASH who want an assymetric
      hash, they all want a symmetric one.
      
      Therefore, use the flow dissector to compute a flat symmetric hash
      over only the protocol, addresses and ports.  This hash does not get
      installed into and override the normal skb hash, so this change has
      no effect whatsoever on the rest of the stack.
      Reported-by: NEric Leblond <eric@regit.org>
      Tested-by: NEric Leblond <eric@regit.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      eb70db87
  25. 11 3月, 2016 1 次提交
  26. 25 2月, 2016 4 次提交
  27. 17 2月, 2016 1 次提交
  28. 09 2月, 2016 1 次提交
  29. 02 9月, 2015 3 次提交