1. 18 6月, 2019 1 次提交
  2. 04 6月, 2019 4 次提交
  3. 26 5月, 2019 3 次提交
  4. 17 5月, 2019 1 次提交
  5. 05 5月, 2019 1 次提交
  6. 02 5月, 2019 2 次提交
    • Z
      ipv4: set the tcp_min_rtt_wlen range from 0 to one day · 250e51f8
      ZhangXiaoxu 提交于
      [ Upstream commit 19fad20d15a6494f47f85d869f00b11343ee5c78 ]
      
      There is a UBSAN report as below:
      UBSAN: Undefined behaviour in net/ipv4/tcp_input.c:2877:56
      signed integer overflow:
      2147483647 * 1000 cannot be represented in type 'int'
      CPU: 3 PID: 0 Comm: swapper/3 Not tainted 5.1.0-rc4-00058-g582549e #1
      Call Trace:
       <IRQ>
       dump_stack+0x8c/0xba
       ubsan_epilogue+0x11/0x60
       handle_overflow+0x12d/0x170
       ? ttwu_do_wakeup+0x21/0x320
       __ubsan_handle_mul_overflow+0x12/0x20
       tcp_ack_update_rtt+0x76c/0x780
       tcp_clean_rtx_queue+0x499/0x14d0
       tcp_ack+0x69e/0x1240
       ? __wake_up_sync_key+0x2c/0x50
       ? update_group_capacity+0x50/0x680
       tcp_rcv_established+0x4e2/0xe10
       tcp_v4_do_rcv+0x22b/0x420
       tcp_v4_rcv+0xfe8/0x1190
       ip_protocol_deliver_rcu+0x36/0x180
       ip_local_deliver+0x15b/0x1a0
       ip_rcv+0xac/0xd0
       __netif_receive_skb_one_core+0x7f/0xb0
       __netif_receive_skb+0x33/0xc0
       netif_receive_skb_internal+0x84/0x1c0
       napi_gro_receive+0x2a0/0x300
       receive_buf+0x3d4/0x2350
       ? detach_buf_split+0x159/0x390
       virtnet_poll+0x198/0x840
       ? reweight_entity+0x243/0x4b0
       net_rx_action+0x25c/0x770
       __do_softirq+0x19b/0x66d
       irq_exit+0x1eb/0x230
       do_IRQ+0x7a/0x150
       common_interrupt+0xf/0xf
       </IRQ>
      
      It can be reproduced by:
        echo 2147483647 > /proc/sys/net/ipv4/tcp_min_rtt_wlen
      
      Fixes: f6722583 ("tcp: track min RTT using windowed min-filter")
      Signed-off-by: NZhangXiaoxu <zhangxiaoxu5@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      250e51f8
    • E
      ipv4: add sanity checks in ipv4_link_failure() · 07445fea
      Eric Dumazet 提交于
      [ Upstream commit 20ff83f10f113c88d0bb74589389b05250994c16 ]
      
      Before calling __ip_options_compile(), we need to ensure the network
      header is a an IPv4 one, and that it is already pulled in skb->head.
      
      RAW sockets going through a tunnel can end up calling ipv4_link_failure()
      with total garbage in the skb, or arbitrary lengthes.
      
      syzbot report :
      
      BUG: KASAN: stack-out-of-bounds in memcpy include/linux/string.h:355 [inline]
      BUG: KASAN: stack-out-of-bounds in __ip_options_echo+0x294/0x1120 net/ipv4/ip_options.c:123
      Write of size 69 at addr ffff888096abf068 by task syz-executor.4/9204
      
      CPU: 0 PID: 9204 Comm: syz-executor.4 Not tainted 5.1.0-rc5+ #77
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x172/0x1f0 lib/dump_stack.c:113
       print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
       kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
       check_memory_region_inline mm/kasan/generic.c:185 [inline]
       check_memory_region+0x123/0x190 mm/kasan/generic.c:191
       memcpy+0x38/0x50 mm/kasan/common.c:133
       memcpy include/linux/string.h:355 [inline]
       __ip_options_echo+0x294/0x1120 net/ipv4/ip_options.c:123
       __icmp_send+0x725/0x1400 net/ipv4/icmp.c:695
       ipv4_link_failure+0x29f/0x550 net/ipv4/route.c:1204
       dst_link_failure include/net/dst.h:427 [inline]
       vti6_xmit net/ipv6/ip6_vti.c:514 [inline]
       vti6_tnl_xmit+0x10d4/0x1c0c net/ipv6/ip6_vti.c:553
       __netdev_start_xmit include/linux/netdevice.h:4414 [inline]
       netdev_start_xmit include/linux/netdevice.h:4423 [inline]
       xmit_one net/core/dev.c:3292 [inline]
       dev_hard_start_xmit+0x1b2/0x980 net/core/dev.c:3308
       __dev_queue_xmit+0x271d/0x3060 net/core/dev.c:3878
       dev_queue_xmit+0x18/0x20 net/core/dev.c:3911
       neigh_direct_output+0x16/0x20 net/core/neighbour.c:1527
       neigh_output include/net/neighbour.h:508 [inline]
       ip_finish_output2+0x949/0x1740 net/ipv4/ip_output.c:229
       ip_finish_output+0x73c/0xd50 net/ipv4/ip_output.c:317
       NF_HOOK_COND include/linux/netfilter.h:278 [inline]
       ip_output+0x21f/0x670 net/ipv4/ip_output.c:405
       dst_output include/net/dst.h:444 [inline]
       NF_HOOK include/linux/netfilter.h:289 [inline]
       raw_send_hdrinc net/ipv4/raw.c:432 [inline]
       raw_sendmsg+0x1d2b/0x2f20 net/ipv4/raw.c:663
       inet_sendmsg+0x147/0x5d0 net/ipv4/af_inet.c:798
       sock_sendmsg_nosec net/socket.c:651 [inline]
       sock_sendmsg+0xdd/0x130 net/socket.c:661
       sock_write_iter+0x27c/0x3e0 net/socket.c:988
       call_write_iter include/linux/fs.h:1866 [inline]
       new_sync_write+0x4c7/0x760 fs/read_write.c:474
       __vfs_write+0xe4/0x110 fs/read_write.c:487
       vfs_write+0x20c/0x580 fs/read_write.c:549
       ksys_write+0x14f/0x2d0 fs/read_write.c:599
       __do_sys_write fs/read_write.c:611 [inline]
       __se_sys_write fs/read_write.c:608 [inline]
       __x64_sys_write+0x73/0xb0 fs/read_write.c:608
       do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x458c29
      Code: ad b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007f293b44bc78 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
      RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000458c29
      RDX: 0000000000000014 RSI: 00000000200002c0 RDI: 0000000000000003
      RBP: 000000000073bf00 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00007f293b44c6d4
      R13: 00000000004c8623 R14: 00000000004ded68 R15: 00000000ffffffff
      
      The buggy address belongs to the page:
      page:ffffea00025aafc0 count:0 mapcount:0 mapping:0000000000000000 index:0x0
      flags: 0x1fffc0000000000()
      raw: 01fffc0000000000 0000000000000000 ffffffff025a0101 0000000000000000
      raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff888096abef80: 00 00 00 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 f2
       ffff888096abf000: f2 f2 f2 f2 00 00 00 00 00 00 00 00 00 00 00 00
      >ffff888096abf080: 00 00 f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00
                               ^
       ffff888096abf100: 00 00 00 00 f1 f1 f1 f1 00 00 f3 f3 00 00 00 00
       ffff888096abf180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      
      Fixes: ed0de45a1008 ("ipv4: recompile ip options in ipv4_link_failure")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Stephen Suryaputra <ssuryaextr@gmail.com>
      Acked-by: NWillem de Bruijn <willemb@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      07445fea
  7. 27 4月, 2019 5 次提交
    • P
      net: IP defrag: encapsulate rbtree defrag code into callable functions · 702ddf86
      Peter Oskolkov 提交于
      [ Upstream commit c23f35d19db3b36ffb9e04b08f1d91565d15f84f ]
      
      This is a refactoring patch: without changing runtime behavior,
      it moves rbtree-related code from IPv4-specific files/functions
      into .h/.c defrag files shared with IPv6 defragmentation code.
      
      v2: make handling of overlapping packets match upstream.
      Signed-off-by: NPeter Oskolkov <posk@google.com>
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: Florian Westphal <fw@strlen.de>
      Cc: Tom Herbert <tom@herbertland.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      702ddf86
    • E
      ipv4: ensure rcu_read_lock() in ipv4_link_failure() · 7ba5ec69
      Eric Dumazet 提交于
      [ Upstream commit c543cb4a5f07e09237ec0fc2c60c9f131b2c79ad ]
      
      fib_compute_spec_dst() needs to be called under rcu protection.
      
      syzbot reported :
      
      WARNING: suspicious RCU usage
      5.1.0-rc4+ #165 Not tainted
      include/linux/inetdevice.h:220 suspicious rcu_dereference_check() usage!
      
      other info that might help us debug this:
      
      rcu_scheduler_active = 2, debug_locks = 1
      1 lock held by swapper/0/0:
       #0: 0000000051b67925 ((&n->timer)){+.-.}, at: lockdep_copy_map include/linux/lockdep.h:170 [inline]
       #0: 0000000051b67925 ((&n->timer)){+.-.}, at: call_timer_fn+0xda/0x720 kernel/time/timer.c:1315
      
      stack backtrace:
      CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.1.0-rc4+ #165
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       <IRQ>
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x172/0x1f0 lib/dump_stack.c:113
       lockdep_rcu_suspicious+0x153/0x15d kernel/locking/lockdep.c:5162
       __in_dev_get_rcu include/linux/inetdevice.h:220 [inline]
       fib_compute_spec_dst+0xbbd/0x1030 net/ipv4/fib_frontend.c:294
       spec_dst_fill net/ipv4/ip_options.c:245 [inline]
       __ip_options_compile+0x15a7/0x1a10 net/ipv4/ip_options.c:343
       ipv4_link_failure+0x172/0x400 net/ipv4/route.c:1195
       dst_link_failure include/net/dst.h:427 [inline]
       arp_error_report+0xd1/0x1c0 net/ipv4/arp.c:297
       neigh_invalidate+0x24b/0x570 net/core/neighbour.c:995
       neigh_timer_handler+0xc35/0xf30 net/core/neighbour.c:1081
       call_timer_fn+0x190/0x720 kernel/time/timer.c:1325
       expire_timers kernel/time/timer.c:1362 [inline]
       __run_timers kernel/time/timer.c:1681 [inline]
       __run_timers kernel/time/timer.c:1649 [inline]
       run_timer_softirq+0x652/0x1700 kernel/time/timer.c:1694
       __do_softirq+0x266/0x95a kernel/softirq.c:293
       invoke_softirq kernel/softirq.c:374 [inline]
       irq_exit+0x180/0x1d0 kernel/softirq.c:414
       exiting_irq arch/x86/include/asm/apic.h:536 [inline]
       smp_apic_timer_interrupt+0x14a/0x570 arch/x86/kernel/apic/apic.c:1062
       apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:807
      
      Fixes: ed0de45a1008 ("ipv4: recompile ip options in ipv4_link_failure")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Cc: Stephen Suryaputra <ssuryaextr@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7ba5ec69
    • S
      ipv4: recompile ip options in ipv4_link_failure · 8a430e56
      Stephen Suryaputra 提交于
      [ Upstream commit ed0de45a1008991fdaa27a0152befcb74d126a8b ]
      
      Recompile IP options since IPCB may not be valid anymore when
      ipv4_link_failure is called from arp_error_report.
      
      Refer to the commit 3da1ed7ac398 ("net: avoid use IPCB in cipso_v4_error")
      and the commit before that (9ef6b42ad6fd) for a similar issue.
      Signed-off-by: NStephen Suryaputra <ssuryaextr@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8a430e56
    • E
      tcp: tcp_grow_window() needs to respect tcp_space() · 6728c617
      Eric Dumazet 提交于
      [ Upstream commit 50ce163a72d817a99e8974222dcf2886d5deb1ae ]
      
      For some reason, tcp_grow_window() correctly tests if enough room
      is present before attempting to increase tp->rcv_ssthresh,
      but does not prevent it to grow past tcp_space()
      
      This is causing hard to debug issues, like failing
      the (__tcp_select_window(sk) >= tp->rcv_wnd) test
      in __tcp_ack_snd_check(), causing ACK delays and possibly
      slow flows.
      
      Depending on tcp_rmem[2], MTU, skb->len/skb->truesize ratio,
      we can see the problem happening on "netperf -t TCP_RR -- -r 2000,2000"
      after about 60 round trips, when the active side no longer sends
      immediate acks.
      
      This bug predates git history.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Acked-by: NSoheil Hassas Yeganeh <soheil@google.com>
      Acked-by: NNeal Cardwell <ncardwell@google.com>
      Acked-by: NWei Wang <weiwan@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6728c617
    • L
      net: fou: do not use guehdr after iptunnel_pull_offloads in gue_udp_recv · 1cd87883
      Lorenzo Bianconi 提交于
      [ Upstream commit 988dc4a9a3b66be75b30405a5494faf0dc7cffb6 ]
      
      gue tunnels run iptunnel_pull_offloads on received skbs. This can
      determine a possible use-after-free accessing guehdr pointer since
      the packet will be 'uncloned' running pskb_expand_head if it is a
      cloned gso skb (e.g if the packet has been sent though a veth device)
      
      Fixes: a09a4c8d ("tunnels: Remove encapsulation offloads on decap")
      Signed-off-by: NLorenzo Bianconi <lorenzo.bianconi@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1cd87883
  8. 17 4月, 2019 4 次提交
    • L
      net: ip_gre: fix possible use-after-free in erspan_rcv · 5c6f2f4c
      Lorenzo Bianconi 提交于
      [ Upstream commit 492b67e28ee5f2a2522fb72e3d3bcb990e461514 ]
      
      erspan tunnels run __iptunnel_pull_header on received skbs to remove
      gre and erspan headers. This can determine a possible use-after-free
      accessing pkt_md pointer in erspan_rcv since the packet will be 'uncloned'
      running pskb_expand_head if it is a cloned gso skb (e.g if the packet has
      been sent though a veth device). Fix it resetting pkt_md pointer after
      __iptunnel_pull_header
      
      Fixes: 1d7e2ed2 ("net: erspan: refactor existing erspan code")
      Signed-off-by: NLorenzo Bianconi <lorenzo.bianconi@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      5c6f2f4c
    • S
      vrf: check accept_source_route on the original netdevice · 0516ef27
      Stephen Suryaputra 提交于
      [ Upstream commit 8c83f2df9c6578ea4c5b940d8238ad8a41b87e9e ]
      
      Configuration check to accept source route IP options should be made on
      the incoming netdevice when the skb->dev is an l3mdev master. The route
      lookup for the source route next hop also needs the incoming netdev.
      
      v2->v3:
      - Simplify by passing the original netdevice down the stack (per David
        Ahern).
      Signed-off-by: NStephen Suryaputra <ssuryaextr@gmail.com>
      Reviewed-by: NDavid Ahern <dsahern@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      0516ef27
    • D
      tcp: fix a potential NULL pointer dereference in tcp_sk_exit · 7243e352
      Dust Li 提交于
      [ Upstream commit b506bc975f60f06e13e74adb35e708a23dc4e87c ]
      
       When tcp_sk_init() failed in inet_ctl_sock_create(),
       'net->ipv4.tcp_congestion_control' will be left
       uninitialized, but tcp_sk_exit() hasn't check for
       that.
      
       This patch add checking on 'net->ipv4.tcp_congestion_control'
       in tcp_sk_exit() to prevent NULL-ptr dereference.
      
      Fixes: 6670e152 ("tcp: Namespace-ify sysctl_tcp_default_congestion_control")
      Signed-off-by: NDust Li <dust.li@linux.alibaba.com>
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      7243e352
    • K
      tcp: Ensure DCTCP reacts to losses · 0e0afb06
      Koen De Schepper 提交于
      [ Upstream commit aecfde23108b8e637d9f5c5e523b24fb97035dc3 ]
      
      RFC8257 §3.5 explicitly states that "A DCTCP sender MUST react to
      loss episodes in the same way as conventional TCP".
      
      Currently, Linux DCTCP performs no cwnd reduction when losses
      are encountered. Optionally, the dctcp_clamp_alpha_on_loss resets
      alpha to its maximal value if a RTO happens. This behavior
      is sub-optimal for at least two reasons: i) it ignores losses
      triggering fast retransmissions; and ii) it causes unnecessary large
      cwnd reduction in the future if the loss was isolated as it resets
      the historical term of DCTCP's alpha EWMA to its maximal value (i.e.,
      denoting a total congestion). The second reason has an especially
      noticeable effect when using DCTCP in high BDP environments, where
      alpha normally stays at low values.
      
      This patch replace the clamping of alpha by setting ssthresh to
      half of cwnd for both fast retransmissions and RTOs, at most once
      per RTT. Consequently, the dctcp_clamp_alpha_on_loss module parameter
      has been removed.
      
      The table below shows experimental results where we measured the
      drop probability of a PIE AQM (not applying ECN marks) at a
      bottleneck in the presence of a single TCP flow with either the
      alpha-clamping option enabled or the cwnd halving proposed by this
      patch. Results using reno or cubic are given for comparison.
      
                                |  Link   |   RTT    |    Drop
                       TCP CC   |  speed  | base+AQM | probability
              ==================|=========|==========|============
                          CUBIC |  40Mbps |  7+20ms  |    0.21%
                           RENO |         |          |    0.19%
              DCTCP-CLAMP-ALPHA |         |          |   25.80%
               DCTCP-HALVE-CWND |         |          |    0.22%
              ------------------|---------|----------|------------
                          CUBIC | 100Mbps |  7+20ms  |    0.03%
                           RENO |         |          |    0.02%
              DCTCP-CLAMP-ALPHA |         |          |   23.30%
               DCTCP-HALVE-CWND |         |          |    0.04%
              ------------------|---------|----------|------------
                          CUBIC | 800Mbps |   1+1ms  |    0.04%
                           RENO |         |          |    0.05%
              DCTCP-CLAMP-ALPHA |         |          |   18.70%
               DCTCP-HALVE-CWND |         |          |    0.06%
      
      We see that, without halving its cwnd for all source of losses,
      DCTCP drives the AQM to large drop probabilities in order to keep
      the queue length under control (i.e., it repeatedly faces RTOs).
      Instead, if DCTCP reacts to all source of losses, it can then be
      controlled by the AQM using similar drop levels than cubic or reno.
      Signed-off-by: NKoen De Schepper <koen.de_schepper@nokia-bell-labs.com>
      Signed-off-by: NOlivier Tilmans <olivier.tilmans@nokia-bell-labs.com>
      Cc: Bob Briscoe <research@bobbriscoe.net>
      Cc: Lawrence Brakmo <brakmo@fb.com>
      Cc: Florian Westphal <fw@strlen.de>
      Cc: Daniel Borkmann <borkmann@iogearbox.net>
      Cc: Yuchung Cheng <ycheng@google.com>
      Cc: Neal Cardwell <ncardwell@google.com>
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: Andrew Shewmaker <agshew@gmail.com>
      Cc: Glenn Judd <glenn.judd@morganstanley.com>
      Acked-by: NFlorian Westphal <fw@strlen.de>
      Acked-by: NNeal Cardwell <ncardwell@google.com>
      Acked-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      0e0afb06
  9. 24 3月, 2019 2 次提交
    • A
      netfilter: ipt_CLUSTERIP: fix warning unused variable cn · 0d98ecb1
      Anders Roxell 提交于
      commit 206b8cc514d7ff2b79dd2d5ad939adc7c493f07a upstream.
      
      When CONFIG_PROC_FS isn't set the variable cn isn't used.
      
      net/ipv4/netfilter/ipt_CLUSTERIP.c: In function ‘clusterip_net_exit’:
      net/ipv4/netfilter/ipt_CLUSTERIP.c:849:24: warning: unused variable ‘cn’ [-Wunused-variable]
        struct clusterip_net *cn = clusterip_pernet(net);
                              ^~
      
      Rework so the variable 'cn' is declared inside "#ifdef CONFIG_PROC_FS".
      
      Fixes: b12f7bad5ad3 ("netfilter: ipt_CLUSTERIP: remove wrong WARN_ON_ONCE in netns exit routine")
      Signed-off-by: NAnders Roxell <anders.roxell@linaro.org>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0d98ecb1
    • M
      esp: Skip TX bytes accounting when sending from a request socket · b92eaed3
      Martin Willi 提交于
      [ Upstream commit 09db51241118aeb06e1c8cd393b45879ce099b36 ]
      
      On ESP output, sk_wmem_alloc is incremented for the added padding if a
      socket is associated to the skb. When replying with TCP SYNACKs over
      IPsec, the associated sk is a casted request socket, only. Increasing
      sk_wmem_alloc on a request socket results in a write at an arbitrary
      struct offset. In the best case, this produces the following WARNING:
      
      WARNING: CPU: 1 PID: 0 at lib/refcount.c:102 esp_output_head+0x2e4/0x308 [esp4]
      refcount_t: addition on 0; use-after-free.
      CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.0.0-rc3 #2
      Hardware name: Marvell Armada 380/385 (Device Tree)
      [...]
      [<bf0ff354>] (esp_output_head [esp4]) from [<bf1006a4>] (esp_output+0xb8/0x180 [esp4])
      [<bf1006a4>] (esp_output [esp4]) from [<c05dee64>] (xfrm_output_resume+0x558/0x664)
      [<c05dee64>] (xfrm_output_resume) from [<c05d07b0>] (xfrm4_output+0x44/0xc4)
      [<c05d07b0>] (xfrm4_output) from [<c05956bc>] (tcp_v4_send_synack+0xa8/0xe8)
      [<c05956bc>] (tcp_v4_send_synack) from [<c0586ad8>] (tcp_conn_request+0x7f4/0x948)
      [<c0586ad8>] (tcp_conn_request) from [<c058c404>] (tcp_rcv_state_process+0x2a0/0xe64)
      [<c058c404>] (tcp_rcv_state_process) from [<c05958ac>] (tcp_v4_do_rcv+0xf0/0x1f4)
      [<c05958ac>] (tcp_v4_do_rcv) from [<c0598a4c>] (tcp_v4_rcv+0xdb8/0xe20)
      [<c0598a4c>] (tcp_v4_rcv) from [<c056eb74>] (ip_protocol_deliver_rcu+0x2c/0x2dc)
      [<c056eb74>] (ip_protocol_deliver_rcu) from [<c056ee6c>] (ip_local_deliver_finish+0x48/0x54)
      [<c056ee6c>] (ip_local_deliver_finish) from [<c056eecc>] (ip_local_deliver+0x54/0xec)
      [<c056eecc>] (ip_local_deliver) from [<c056efac>] (ip_rcv+0x48/0xb8)
      [<c056efac>] (ip_rcv) from [<c0519c2c>] (__netif_receive_skb_one_core+0x50/0x6c)
      [...]
      
      The issue triggers only when not using TCP syncookies, as for syncookies
      no socket is associated.
      
      Fixes: cac2661c ("esp4: Avoid skb_cow_data whenever possible")
      Fixes: 03e2a30f ("esp6: Avoid skb_cow_data whenever possible")
      Signed-off-by: NMartin Willi <martin@strongswan.org>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      b92eaed3
  10. 19 3月, 2019 5 次提交
  11. 14 3月, 2019 1 次提交
    • S
      vti4: Fix a ipip packet processing bug in 'IPCOMP' virtual tunnel · 8ce41db0
      Su Yanjun 提交于
      [ Upstream commit dd9ee3444014e8f28c0eefc9fffc9ac9c5248c12 ]
      
      Recently we run a network test over ipcomp virtual tunnel.We find that
      if a ipv4 packet needs fragment, then the peer can't receive
      it.
      
      We deep into the code and find that when packet need fragment the smaller
      fragment will be encapsulated by ipip not ipcomp. So when the ipip packet
      goes into xfrm, it's skb->dev is not properly set. The ipv4 reassembly code
      always set skb'dev to the last fragment's dev. After ipv4 defrag processing,
      when the kernel rp_filter parameter is set, the skb will be drop by -EXDEV
      error.
      
      This patch adds compatible support for the ipip process in ipcomp virtual tunnel.
      Signed-off-by: NSu Yanjun <suyj.fnst@cn.fujitsu.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      8ce41db0
  12. 10 3月, 2019 6 次提交
  13. 27 2月, 2019 2 次提交
    • T
      netfilter: ipt_CLUSTERIP: fix sleep-in-atomic bug in clusterip_config_entry_put() · 6546e115
      Taehee Yoo 提交于
      commit 2a61d8b883bbad26b06d2e6cc3777a697e78830d upstream.
      
      A proc_remove() can sleep. so that it can't be inside of spin_lock.
      Hence proc_remove() is moved to outside of spin_lock. and it also
      adds mutex to sync create and remove of proc entry(config->pde).
      
      test commands:
      SHELL#1
         %while :; do iptables -A INPUT -p udp -i enp2s0 -d 192.168.1.100 \
      	   --dport 9000  -j CLUSTERIP --new --hashmode sourceip \
      	   --clustermac 01:00:5e:00:00:21 --total-nodes 3 --local-node 3; \
      	   iptables -F; done
      
      SHELL#2
         %while :; do echo +1 > /proc/net/ipt_CLUSTERIP/192.168.1.100; \
      	   echo -1 > /proc/net/ipt_CLUSTERIP/192.168.1.100; done
      
      [ 2949.569864] BUG: sleeping function called from invalid context at kernel/sched/completion.c:99
      [ 2949.579944] in_atomic(): 1, irqs_disabled(): 0, pid: 5472, name: iptables
      [ 2949.587920] 1 lock held by iptables/5472:
      [ 2949.592711]  #0: 000000008f0ebcf2 (&(&cn->lock)->rlock){+...}, at: refcount_dec_and_lock+0x24/0x50
      [ 2949.603307] CPU: 1 PID: 5472 Comm: iptables Tainted: G        W         4.19.0-rc5+ #16
      [ 2949.604212] Hardware name: To be filled by O.E.M. To be filled by O.E.M./Aptio CRB, BIOS 5.6.5 07/08/2015
      [ 2949.604212] Call Trace:
      [ 2949.604212]  dump_stack+0xc9/0x16b
      [ 2949.604212]  ? show_regs_print_info+0x5/0x5
      [ 2949.604212]  ___might_sleep+0x2eb/0x420
      [ 2949.604212]  ? set_rq_offline.part.87+0x140/0x140
      [ 2949.604212]  ? _rcu_barrier_trace+0x400/0x400
      [ 2949.604212]  wait_for_completion+0x94/0x710
      [ 2949.604212]  ? wait_for_completion_interruptible+0x780/0x780
      [ 2949.604212]  ? __kernel_text_address+0xe/0x30
      [ 2949.604212]  ? __lockdep_init_map+0x10e/0x5c0
      [ 2949.604212]  ? __lockdep_init_map+0x10e/0x5c0
      [ 2949.604212]  ? __init_waitqueue_head+0x86/0x130
      [ 2949.604212]  ? init_wait_entry+0x1a0/0x1a0
      [ 2949.604212]  proc_entry_rundown+0x208/0x270
      [ 2949.604212]  ? proc_reg_get_unmapped_area+0x370/0x370
      [ 2949.604212]  ? __lock_acquire+0x4500/0x4500
      [ 2949.604212]  ? complete+0x18/0x70
      [ 2949.604212]  remove_proc_subtree+0x143/0x2a0
      [ 2949.708655]  ? remove_proc_entry+0x390/0x390
      [ 2949.708655]  clusterip_tg_destroy+0x27a/0x630 [ipt_CLUSTERIP]
      [ ... ]
      
      Fixes: b3e456fc ("netfilter: ipt_CLUSTERIP: fix a race condition of proc file creation")
      Signed-off-by: NTaehee Yoo <ap420073@gmail.com>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6546e115
    • K
      inet_diag: fix reporting cgroup classid and fallback to priority · 589503cb
      Konstantin Khlebnikov 提交于
      [ Upstream commit 1ec17dbd90f8b638f41ee650558609c1af63dfa0 ]
      
      Field idiag_ext in struct inet_diag_req_v2 used as bitmap of requested
      extensions has only 8 bits. Thus extensions starting from DCTCPINFO
      cannot be requested directly. Some of them included into response
      unconditionally or hook into some of lower 8 bits.
      
      Extension INET_DIAG_CLASS_ID has not way to request from the beginning.
      
      This patch bundle it with INET_DIAG_TCLASS (ipv6 tos), fixes space
      reservation, and documents behavior for other extensions.
      
      Also this patch adds fallback to reporting socket priority. This filed
      is more widely used for traffic classification because ipv4 sockets
      automatically maps TOS to priority and default qdisc pfifo_fast knows
      about that. But priority could be changed via setsockopt SO_PRIORITY so
      INET_DIAG_TOS isn't enough for predicting class.
      
      Also cgroup2 obsoletes net_cls classid (it always zero), but we cannot
      reuse this field for reporting cgroup2 id because it is 64-bit (ino+gen).
      
      So, after this patch INET_DIAG_CLASS_ID will report socket priority
      for most common setup when net_cls isn't set and/or cgroup2 in use.
      
      Fixes: 0888e372 ("net: inet: diag: expose sockets cgroup classid")
      Signed-off-by: NKonstantin Khlebnikov <khlebnikov@yandex-team.ru>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      589503cb
  14. 23 2月, 2019 3 次提交