1. 19 Mar, 2019 8 commits
    • Xin Long's avatar
      sctp: fix ignoring asoc_id for tcp-style sockets on SCTP_DEFAULT_SNDINFO sockopt · a842e65b
      Xin Long authored
      A similar fix as Patch "sctp: fix ignoring asoc_id for tcp-style sockets on
      SCTP_DEFAULT_SEND_PARAM sockopt" on SCTP_DEFAULT_SNDINFO sockopt.
      
      Fixes: 92fc3bd9 ("sctp: use SCTP_FUTURE_ASSOC and add SCTP_CURRENT_ASSOC for SCTP_DEFAULT_SNDINFO sockopt")
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a842e65b
    • Xin Long's avatar
      sctp: fix ignoring asoc_id for tcp-style sockets on SCTP_DELAYED_SACK sockopt · 8e2614fc
      Xin Long authored
      A similar fix as Patch "sctp: fix ignoring asoc_id for tcp-style sockets on
      SCTP_DEFAULT_SEND_PARAM sockopt" on SCTP_DELAYED_SACK sockopt.
      
      Fixes: 9c5829e1 ("sctp: use SCTP_FUTURE_ASSOC and add SCTP_CURRENT_ASSOC for SCTP_DELAYED_SACK sockopt")
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8e2614fc
    • Marcelo Ricardo Leitner's avatar
      sctp: fix ignoring asoc_id for tcp-style sockets on SCTP_DEFAULT_SEND_PARAM sockopt · 1354e72f
      Marcelo Ricardo Leitner authored
      Currently if the user pass an invalid asoc_id to SCTP_DEFAULT_SEND_PARAM
      on a TCP-style socket, it will silently ignore the new parameters.
      That's because after not finding an asoc, it is checking asoc_id against
      the known values of CURRENT/FUTURE/ALL values and that fails to match.
      
      IOW, if the user supplies an invalid asoc id or not, it should either
      match the current asoc or the socket itself so that it will inherit
      these later. Fixes it by forcing asoc_id to SCTP_FUTURE_ASSOC in case it
      is a TCP-style socket without an asoc, so that the values get set on the
      socket.
      
      Fixes: 707e45b3 ("sctp: use SCTP_FUTURE_ASSOC and add SCTP_CURRENT_ASSOC for SCTP_DEFAULT_SEND_PARAM sockopt")
      Signed-off-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1354e72f
    • Xin Long's avatar
      sctp: not copy sctp_sock pd_lobby in sctp_copy_descendant · 636d25d5
      Xin Long authored
      Now sctp_copy_descendant() copies pd_lobby from old sctp scok to new
      sctp sock. If sctp_sock_migrate() returns error, it will panic when
      releasing new sock and trying to purge pd_lobby due to the incorrect
      pointers in pd_lobby.
      
        [  120.485116] kasan: CONFIG_KASAN_INLINE enabled
        [  120.486270] kasan: GPF could be caused by NULL-ptr deref or user
        [  120.509901] Call Trace:
        [  120.510443]  sctp_ulpevent_free+0x1e8/0x490 [sctp]
        [  120.511438]  sctp_queue_purge_ulpevents+0x97/0xe0 [sctp]
        [  120.512535]  sctp_close+0x13a/0x700 [sctp]
        [  120.517483]  inet_release+0xdc/0x1c0
        [  120.518215]  __sock_release+0x1d2/0x2a0
        [  120.519025]  sctp_do_peeloff+0x30f/0x3c0 [sctp]
      
      We fix it by not copying sctp_sock pd_lobby in sctp_copy_descendan(),
      and skb_queue_head_init() can also be removed in sctp_sock_migrate().
      
      Reported-by: syzbot+85e0b422ff140b03672a@syzkaller.appspotmail.com
      Fixes: 89664c62 ("sctp: sctp_sock_migrate() returns error if sctp_bind_addr_dup() fails")
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      636d25d5
    • Xin Long's avatar
      sctp: get sctphdr by offset in sctp_compute_cksum · 273160ff
      Xin Long authored
      sctp_hdr(skb) only works when skb->transport_header is set properly.
      
      But in Netfilter, skb->transport_header for ipv6 is not guaranteed
      to be right value for sctphdr. It would cause to fail to check the
      checksum for sctp packets.
      
      So fix it by using offset, which is always right in all places.
      
      v1->v2:
        - Fix the changelog.
      
      Fixes: e6d8b64b ("net: sctp: fix and consolidate SCTP checksumming code")
      Reported-by: default avatarLi Shuang <shuali@redhat.com>
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      273160ff
    • Yoshiki Komachi's avatar
      af_packet: fix the tx skb protocol in raw sockets with ETH_P_ALL · 18bed891
      Yoshiki Komachi authored
      I am using "protocol ip" filters in TC to manipulate TC flower
      classifiers, which are only available with "protocol ip". However,
      I faced an issue that packets sent via raw sockets with ETH_P_ALL
      did not match the ip filters even if they did satisfy the condition
      (e.g., DHCP offer from dhcpd).
      
      I have determined that the behavior was caused by an unexpected
      value stored in skb->protocol, namely, ETH_P_ALL instead of ETH_P_IP,
      when packets were sent via raw sockets with ETH_P_ALL set.
      
      IMHO, storing ETH_P_ALL in skb->protocol is not appropriate for
      packets sent via raw sockets because ETH_P_ALL is not a real ether
      type used on wire, but a virtual one.
      
      This patch fixes the tx protocol selection in cases of transmission
      via raw sockets created with ETH_P_ALL so that it asks the driver to
      extract protocol from the Ethernet header.
      
      Fixes: 75c65772 ("net/packet: Ask driver for protocol if not provided by user")
      Signed-off-by: default avatarYoshiki Komachi <komachi.yoshiki@lab.ntt.co.jp>
      Acked-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      18bed891
    • Maxime Chevallier's avatar
      packets: Always register packet sk in the same order · a4dc6a49
      Maxime Chevallier authored
      When using fanouts with AF_PACKET, the demux functions such as
      fanout_demux_cpu will return an index in the fanout socket array, which
      corresponds to the selected socket.
      
      The ordering of this array depends on the order the sockets were added
      to a given fanout group, so for FANOUT_CPU this means sockets are bound
      to cpus in the order they are configured, which is OK.
      
      However, when stopping then restarting the interface these sockets are
      bound to, the sockets are reassigned to the fanout group in the reverse
      order, due to the fact that they were inserted at the head of the
      interface's AF_PACKET socket list.
      
      This means that traffic that was directed to the first socket in the
      fanout group is now directed to the last one after an interface restart.
      
      In the case of FANOUT_CPU, traffic from CPU0 will be directed to the
      socket that used to receive traffic from the last CPU after an interface
      restart.
      
      This commit introduces a helper to add a socket at the tail of a list,
      then uses it to register AF_PACKET sockets.
      
      Note that this changes the order in which sockets are listed in /proc and
      with sock_diag.
      
      Fixes: dc99f600 ("packet: Add fanout support")
      Signed-off-by: default avatarMaxime Chevallier <maxime.chevallier@bootlin.com>
      Acked-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a4dc6a49
    • Zhiqiang Liu's avatar
      vxlan: Don't call gro_cells_destroy() before device is unregistered · cc4807bb
      Zhiqiang Liu authored
      Commit ad6c9986 ("vxlan: Fix GRO cells race condition between
      receive and link delete") fixed a race condition for the typical case a vxlan
      device is dismantled from the current netns. But if a netns is dismantled,
      vxlan_destroy_tunnels() is called to schedule a unregister_netdevice_queue()
      of all the vxlan tunnels that are related to this netns.
      
      In vxlan_destroy_tunnels(), gro_cells_destroy() is called and finished before
      unregister_netdevice_queue(). This means that the gro_cells_destroy() call is
      done too soon, for the same reasons explained in above commit.
      
      So we need to fully respect the RCU rules, and thus must remove the
      gro_cells_destroy() call or risk use after-free.
      
      Fixes: 58ce31cc ("vxlan: GRO support at tunnel layer")
      Signed-off-by: default avatarSuanming.Mou <mousuanming@huawei.com>
      Suggested-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Reviewed-by: default avatarStefano Brivio <sbrivio@redhat.com>
      Reviewed-by: default avatarZhiqiang Liu <liuzhiqiang26@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cc4807bb
  2. 18 Mar, 2019 7 commits
    • Dmitry Bogdanov's avatar
      net: aquantia: fix rx checksum offload for UDP/TCP over IPv6 · a7faaa0c
      Dmitry Bogdanov authored
      TCP/UDP checksum validity was propagated to skb
      only if IP checksum is valid.
      But for IPv6 there is no validity as there is no checksum in IPv6.
      This patch propagates TCP/UDP checksum validity regardless of IP checksum.
      
      Fixes: 018423e9 ("net: ethernet: aquantia: Add ring support code")
      Signed-off-by: default avatarIgor Russkikh <igor.russkikh@aquantia.com>
      Signed-off-by: default avatarNikita Danilov <nikita.danilov@aquantia.com>
      Signed-off-by: default avatarDmitry Bogdanov <dmitry.bogdanov@aquantia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a7faaa0c
    • Finn Thain's avatar
      mac8390: Fix mmio access size probe · bb9e5c5b
      Finn Thain authored
      The bug that Stan reported is as follows. After a restart, a 16-bit NIC
      may be incorrectly identified as a 32-bit NIC and stop working.
      
      mac8390 slot.E: Memory length resource not found, probing
      mac8390 slot.E: Farallon EtherMac II-C (type farallon)
      mac8390 slot.E: MAC 00:00:c5:30:c2:99, IRQ 61, 32 KB shared memory at 0xfeed0000, 32-bit access.
      
      The bug never arises after a cold start and only intermittently after a
      warm start. (I didn't investigate why the bug is intermittent.)
      
      It turns out that memcpy_toio() is deprecated and memcmp_withio() also
      has issues. Replacing these calls with mmio accessors fixes the problem.
      Reported-and-tested-by: default avatarStan Johnson <userm57@yahoo.com>
      Fixes: 2964db0f ("m68k: Mac DP8390 update")
      Signed-off-by: default avatarFinn Thain <fthain@telegraphics.com.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bb9e5c5b
    • Matteo Croce's avatar
      gtp: change NET_UDP_TUNNEL dependency to select · c22da366
      Matteo Croce authored
      Similarly to commit a7603ac1 ("geneve: change NET_UDP_TUNNEL
      dependency to select"), GTP has a dependency on NET_UDP_TUNNEL which
      makes impossible to compile it if no other protocol depending on
      NET_UDP_TUNNEL is selected.
      
      Fix this by changing the depends to a select, and drop NET_IP_TUNNEL from
      the select list, as it already depends on NET_UDP_TUNNEL.
      Signed-off-by: default avatarMatteo Croce <mcroce@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c22da366
    • Eric Dumazet's avatar
      net: rose: fix a possible stack overflow · e5dcc0c3
      Eric Dumazet authored
      rose_write_internal() uses a temp buffer of 100 bytes, but a manual
      inspection showed that given arbitrary input, rose_create_facilities()
      can fill up to 110 bytes.
      
      Lets use a tailroom of 256 bytes for peace of mind, and remove
      the bounce buffer : we can simply allocate a big enough skb
      and adjust its length as needed.
      
      syzbot report :
      
      BUG: KASAN: stack-out-of-bounds in memcpy include/linux/string.h:352 [inline]
      BUG: KASAN: stack-out-of-bounds in rose_create_facilities net/rose/rose_subr.c:521 [inline]
      BUG: KASAN: stack-out-of-bounds in rose_write_internal+0x597/0x15d0 net/rose/rose_subr.c:116
      Write of size 7 at addr ffff88808b1ffbef by task syz-executor.0/24854
      
      CPU: 0 PID: 24854 Comm: syz-executor.0 Not tainted 5.0.0+ #97
      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:131
       memcpy include/linux/string.h:352 [inline]
       rose_create_facilities net/rose/rose_subr.c:521 [inline]
       rose_write_internal+0x597/0x15d0 net/rose/rose_subr.c:116
       rose_connect+0x7cb/0x1510 net/rose/af_rose.c:826
       __sys_connect+0x266/0x330 net/socket.c:1685
       __do_sys_connect net/socket.c:1696 [inline]
       __se_sys_connect net/socket.c:1693 [inline]
       __x64_sys_connect+0x73/0xb0 net/socket.c:1693
       do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x458079
      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:00007f47b8d9dc78 EFLAGS: 00000246 ORIG_RAX: 000000000000002a
      RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000458079
      RDX: 000000000000001c RSI: 0000000020000040 RDI: 0000000000000004
      RBP: 000000000073bf00 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 00007f47b8d9e6d4
      R13: 00000000004be4a4 R14: 00000000004ceca8 R15: 00000000ffffffff
      
      The buggy address belongs to the page:
      page:ffffea00022c7fc0 count:0 mapcount:0 mapping:0000000000000000 index:0x0
      flags: 0x1fffc0000000000()
      raw: 01fffc0000000000 0000000000000000 ffffffff022c0101 0000000000000000
      raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff88808b1ffa80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
       ffff88808b1ffb00: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 03
      >ffff88808b1ffb80: f2 f2 00 00 00 00 00 00 00 00 00 00 00 00 04 f3
                                                                   ^
       ffff88808b1ffc00: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
       ffff88808b1ffc80: 00 00 00 00 00 00 00 f1 f1 f1 f1 f1 f1 01 f2 01
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e5dcc0c3
    • Tobias Klauser's avatar
      doc: fix link to MSG_ZEROCOPY patchset · 25208dd8
      Tobias Klauser authored
      Use https and link to the patch directly.
      Signed-off-by: default avatarTobias Klauser <tklauser@distanz.ch>
      Acked-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      25208dd8
    • Erik Hugne's avatar
      tipc: allow service ranges to be connect()'ed on RDM/DGRAM · ea239314
      Erik Hugne authored
      We move the check that prevents connecting service ranges to after
      the RDM/DGRAM check, and move address sanity control to a separate
      function that also validates the service range.
      
      Fixes: 23998835 ("tipc: improve address sanity check in tipc_connect()")
      Signed-off-by: default avatarErik Hugne <erik.hugne@gmail.com>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ea239314
    • Randy Dunlap's avatar
      networking: fix snmp_counter.rst Doc. Warnings · 65e9a6d2
      Randy Dunlap authored
      Fix documentation markup warnings in snmp_counter.rst:
      
      Documentation/networking/snmp_counter.rst:416: WARNING: Title underline too short.
      Documentation/networking/snmp_counter.rst:684: WARNING: Bullet list ends without a blank line; unexpected unindent.
      Documentation/networking/snmp_counter.rst:693: WARNING: Title underline too short.
      Documentation/networking/snmp_counter.rst:707: WARNING: Bullet list ends without a blank line; unexpected unindent.
      Documentation/networking/snmp_counter.rst:712: WARNING: Bullet list ends without a blank line; unexpected unindent.
      Documentation/networking/snmp_counter.rst:722: WARNING: Title underline too short.
      Documentation/networking/snmp_counter.rst:733: WARNING: Bullet list ends without a blank line; unexpected unindent.
      Documentation/networking/snmp_counter.rst:736: WARNING: Bullet list ends without a blank line; unexpected unindent.
      Documentation/networking/snmp_counter.rst:739: WARNING: Bullet list ends without a blank line; unexpected unindent.
      
      Fixes: 80cc4950 ("net: Add part of TCP counts explanations in snmp_counters.rst")
      Fixes: 8e2ea53a ("add snmp counters document")
      Fixes: a6c7c7aa ("net: add document for several snmp counters")
      Signed-off-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Cc: yupeng <yupeng0921@gmail.com>
      65e9a6d2
  3. 17 Mar, 2019 1 commit
  4. 16 Mar, 2019 8 commits
  5. 15 Mar, 2019 11 commits
  6. 14 Mar, 2019 5 commits