1. 25 Mar, 2019 11 commits
  2. 19 Mar, 2019 25 commits
  3. 18 Mar, 2019 4 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