1. 28 3月, 2018 3 次提交
  2. 27 3月, 2018 29 次提交
  3. 26 3月, 2018 5 次提交
    • D
      Merge tag 'wireless-drivers-for-davem-2018-03-24' of... · c87308b1
      David S. Miller 提交于
      Merge tag 'wireless-drivers-for-davem-2018-03-24' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers
      
      Kalle Valo says:
      
      ====================
      wireless-drivers fixes for 4.16
      
      Some fixes for 4.16, only for iwlwifi and brcmfmac this time. All
      pretty small.
      
      iwlwifi
      
      * fix an issue with the multicast queue
      
      * fix IGTK handling
      
      * fix some missing return value checks
      
      * add support for a HW workaround for issues on some platforms
      
      * a couple of fixes for channel-switch
      
      * a few fixes for the aggregation handling code
      
      brcmfmac
      
      * drop Inter-Access Point Protocol packets by default
      
      * fix check for ISO3166 regulatory code
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c87308b1
    • P
      ipv6: the entire IPv6 header chain must fit the first fragment · 10b8a3de
      Paolo Abeni 提交于
      While building ipv6 datagram we currently allow arbitrary large
      extheaders, even beyond pmtu size. The syzbot has found a way
      to exploit the above to trigger the following splat:
      
      kernel BUG at ./include/linux/skbuff.h:2073!
      invalid opcode: 0000 [#1] SMP KASAN
      Dumping ftrace buffer:
          (ftrace buffer empty)
      Modules linked in:
      CPU: 1 PID: 4230 Comm: syzkaller672661 Not tainted 4.16.0-rc2+ #326
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
      Google 01/01/2011
      RIP: 0010:__skb_pull include/linux/skbuff.h:2073 [inline]
      RIP: 0010:__ip6_make_skb+0x1ac8/0x2190 net/ipv6/ip6_output.c:1636
      RSP: 0018:ffff8801bc18f0f0 EFLAGS: 00010293
      RAX: ffff8801b17400c0 RBX: 0000000000000738 RCX: ffffffff84f01828
      RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8801b415ac18
      RBP: ffff8801bc18f360 R08: ffff8801b4576844 R09: 0000000000000000
      R10: ffff8801bc18f380 R11: ffffed00367aee4e R12: 00000000000000d6
      R13: ffff8801b415a740 R14: dffffc0000000000 R15: ffff8801b45767c0
      FS:  0000000001535880(0000) GS:ffff8801db300000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 000000002000b000 CR3: 00000001b4123001 CR4: 00000000001606e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
        ip6_finish_skb include/net/ipv6.h:969 [inline]
        udp_v6_push_pending_frames+0x269/0x3b0 net/ipv6/udp.c:1073
        udpv6_sendmsg+0x2a96/0x3400 net/ipv6/udp.c:1343
        inet_sendmsg+0x11f/0x5e0 net/ipv4/af_inet.c:764
        sock_sendmsg_nosec net/socket.c:630 [inline]
        sock_sendmsg+0xca/0x110 net/socket.c:640
        ___sys_sendmsg+0x320/0x8b0 net/socket.c:2046
        __sys_sendmmsg+0x1ee/0x620 net/socket.c:2136
        SYSC_sendmmsg net/socket.c:2167 [inline]
        SyS_sendmmsg+0x35/0x60 net/socket.c:2162
        do_syscall_64+0x280/0x940 arch/x86/entry/common.c:287
        entry_SYSCALL_64_after_hwframe+0x42/0xb7
      RIP: 0033:0x4404c9
      RSP: 002b:00007ffdce35f948 EFLAGS: 00000217 ORIG_RAX: 0000000000000133
      RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 00000000004404c9
      RDX: 0000000000000003 RSI: 0000000020001f00 RDI: 0000000000000003
      RBP: 00000000006cb018 R08: 00000000004002c8 R09: 00000000004002c8
      R10: 0000000020000080 R11: 0000000000000217 R12: 0000000000401df0
      R13: 0000000000401e80 R14: 0000000000000000 R15: 0000000000000000
      Code: ff e8 1d 5e b9 fc e9 15 e9 ff ff e8 13 5e b9 fc e9 44 e8 ff ff e8 29
      5e b9 fc e9 c0 e6 ff ff e8 3f f3 80 fc 0f 0b e8 38 f3 80 fc <0f> 0b 49 8d
      87 80 00 00 00 4d 8d 87 84 00 00 00 48 89 85 20 fe
      RIP: __skb_pull include/linux/skbuff.h:2073 [inline] RSP: ffff8801bc18f0f0
      RIP: __ip6_make_skb+0x1ac8/0x2190 net/ipv6/ip6_output.c:1636 RSP:
      ffff8801bc18f0f0
      
      As stated by RFC 7112 section 5:
      
         When a host fragments an IPv6 datagram, it MUST include the entire
         IPv6 Header Chain in the First Fragment.
      
      So this patch addresses the issue dropping datagrams with excessive
      extheader length. It also updates the error path to report to the
      calling socket nonnegative pmtu values.
      
      The issue apparently predates git history.
      
      v1 -> v2: cleanup error path, as per Eric's suggestion
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Reported-by: syzbot+91e6f9932ff122fa4410@syzkaller.appspotmail.com
      Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
      Reviewed-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      10b8a3de
    • A
      netlink: make sure nladdr has correct size in netlink_connect() · 78802879
      Alexander Potapenko 提交于
      KMSAN reports use of uninitialized memory in the case when |alen| is
      smaller than sizeof(struct sockaddr_nl), and therefore |nladdr| isn't
      fully copied from the userspace.
      Signed-off-by: NAlexander Potapenko <glider@google.com>
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Reviewed-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      78802879
    • R
      lan78xx: Set ASD in MAC_CR when EEE is enabled. · e69647a1
      Raghuram Chary J 提交于
      Description:
      EEE does not work with lan7800 when AutoSpeed is not set.
      (This can happen when EEPROM is not populated or configured incorrectly)
      
      Root-Cause:
      When EEE is enabled, the mac config register ASD is not set
      i.e. in default state, causing EEE fail.
      
      Fix:
      Set the register when eeprom is not present.
      
      Fixes: 55d7de9d ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver")
      Signed-off-by: NRaghuram Chary J <raghuramchary.jallipalli@microchip.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e69647a1
    • H
      net/ipv4: disable SMC TCP option with SYN Cookies · bc58a1ba
      Hans Wippel 提交于
      Currently, the SMC experimental TCP option in a SYN packet is lost on
      the server side when SYN Cookies are active. However, the corresponding
      SYNACK sent back to the client contains the SMC option. This causes an
      inconsistent view of the SMC capabilities on the client and server.
      
      This patch disables the SMC option in the SYNACK when SYN Cookies are
      active to avoid this issue.
      
      Fixes: 60e2a778 ("tcp: TCP experimental option for SMC")
      Signed-off-by: NHans Wippel <hwippel@linux.vnet.ibm.com>
      Signed-off-by: NUrsula Braun <ubraun@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bc58a1ba
  4. 25 3月, 2018 2 次提交
    • D
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf · b9ee96b4
      David S. Miller 提交于
      Pablo Neira Ayuso says:
      
      ====================
      Netfilter fixes for net
      
      The following patchset contains Netfilter fixes for your net tree,
      they are:
      
      1) Don't pick fixed hash implementation for NFT_SET_EVAL sets, otherwise
         userspace hits EOPNOTSUPP with valid rules using the meter statement,
         from Florian Westphal.
      
      2) If you send a batch that flushes the existing ruleset (that contains
         a NAT chain) and the new ruleset definition comes with a new NAT
         chain, don't bogusly hit EBUSY. Also from Florian.
      
      3) Missing netlink policy attribute validation, from Florian.
      
      4) Detach conntrack template from skbuff if IP_NODEFRAG is set on,
         from Paolo Abeni.
      
      5) Cache device names in flowtable object, otherwise we may end up
         walking over devices going aways given no rtnl_lock is held.
      
      6) Fix incorrect net_device ingress with ingress hooks.
      
      7) Fix crash when trying to read more data than available in UDP
         packets from the nf_socket infrastructure, from Subash.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b9ee96b4
    • S
      netfilter: nf_socket: Fix out of bounds access in nf_sk_lookup_slow_v{4,6} · 32c1733f
      Subash Abhinov Kasiviswanathan 提交于
      skb_header_pointer will copy data into a buffer if data is non linear,
      otherwise it will return a pointer in the linear section of the data.
      nf_sk_lookup_slow_v{4,6} always copies data of size udphdr but later
      accesses memory within the size of tcphdr (th->doff) in case of TCP
      packets. This causes a crash when running with KASAN with the following
      call stack -
      
      BUG: KASAN: stack-out-of-bounds in xt_socket_lookup_slow_v4+0x524/0x718
      net/netfilter/xt_socket.c:178
      Read of size 2 at addr ffffffe3d417a87c by task syz-executor/28971
      CPU: 2 PID: 28971 Comm: syz-executor Tainted: G    B   W  O    4.9.65+ #1
      Call trace:
      [<ffffff9467e8d390>] dump_backtrace+0x0/0x428 arch/arm64/kernel/traps.c:76
      [<ffffff9467e8d7e0>] show_stack+0x28/0x38 arch/arm64/kernel/traps.c:226
      [<ffffff946842d9b8>] __dump_stack lib/dump_stack.c:15 [inline]
      [<ffffff946842d9b8>] dump_stack+0xd4/0x124 lib/dump_stack.c:51
      [<ffffff946811d4b0>] print_address_description+0x68/0x258 mm/kasan/report.c:248
      [<ffffff946811d8c8>] kasan_report_error mm/kasan/report.c:347 [inline]
      [<ffffff946811d8c8>] kasan_report.part.2+0x228/0x2f0 mm/kasan/report.c:371
      [<ffffff946811df44>] kasan_report+0x5c/0x70 mm/kasan/report.c:372
      [<ffffff946811bebc>] check_memory_region_inline mm/kasan/kasan.c:308 [inline]
      [<ffffff946811bebc>] __asan_load2+0x84/0x98 mm/kasan/kasan.c:739
      [<ffffff94694d6f04>] __tcp_hdrlen include/linux/tcp.h:35 [inline]
      [<ffffff94694d6f04>] xt_socket_lookup_slow_v4+0x524/0x718 net/netfilter/xt_socket.c:178
      
      Fix this by copying data into appropriate size headers based on protocol.
      
      Fixes: a583636a ("inet: refactor inet[6]_lookup functions to take skb")
      Signed-off-by: NTejaswi Tanikella <tejaswit@codeaurora.org>
      Signed-off-by: NSubash Abhinov Kasiviswanathan <subashab@codeaurora.org>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      32c1733f
  5. 24 3月, 2018 1 次提交
    • L
      batman-adv: fix packet loss for broadcasted DHCP packets to a server · a752c0a4
      Linus Lüssing 提交于
      DHCP connectivity issues can currently occur if the following conditions
      are met:
      
      1) A DHCP packet from a client to a server
      2) This packet has a multicast destination
      3) This destination has a matching entry in the translation table
         (FF:FF:FF:FF:FF:FF for IPv4, 33:33:00:01:00:02/33:33:00:01:00:03
          for IPv6)
      4) The orig-node determined by TT for the multicast destination
         does not match the orig-node determined by best-gateway-selection
      
      In this case the DHCP packet will be dropped.
      
      The "gateway-out-of-range" check is supposed to only be applied to
      unicasted DHCP packets to a specific DHCP server.
      
      In that case dropping the the unicasted frame forces the client to
      retry via a broadcasted one, but now directed to the new best
      gateway.
      
      A DHCP packet with broadcast/multicast destination is already ensured to
      always be delivered to the best gateway. Dropping a multicasted
      DHCP packet here will only prevent completing DHCP as there is no
      other fallback.
      
      So far, it seems the unicast check was implicitly performed by
      expecting the batadv_transtable_search() to return NULL for multicast
      destinations. However, a multicast address could have always ended up in
      the translation table and in fact is now common.
      
      To fix this potential loss of a DHCP client-to-server packet to a
      multicast address this patch adds an explicit multicast destination
      check to reliably bail out of the gateway-out-of-range check for such
      destinations.
      
      The issue and fix were tested in the following three node setup:
      
      - Line topology, A-B-C
      - A: gateway client, DHCP client
      - B: gateway server, hop-penalty increased: 30->60, DHCP server
      - C: gateway server, code modifications to announce FF:FF:FF:FF:FF:FF
      
      Without this patch, A would never transmit its DHCP Discover packet
      due to an always "out-of-range" condition. With this patch,
      a full DHCP handshake between A and B was possible again.
      
      Fixes: be7af5cf ("batman-adv: refactoring gateway handling code")
      Signed-off-by: NLinus Lüssing <linus.luessing@c0d3.blue>
      Signed-off-by: NSven Eckelmann <sven@narfation.org>
      Signed-off-by: NSimon Wunderlich <sw@simonwunderlich.de>
      a752c0a4