1. 16 Jul, 2018 4 commits
    • Eric Biggers's avatar
      KEYS: DNS: fix parsing multiple options · c604cb76
      Eric Biggers authored
      My recent fix for dns_resolver_preparse() printing very long strings was
      incomplete, as shown by syzbot which still managed to hit the
      WARN_ONCE() in set_precision() by adding a crafted "dns_resolver" key:
      
          precision 50001 too large
          WARNING: CPU: 7 PID: 864 at lib/vsprintf.c:2164 vsnprintf+0x48a/0x5a0
      
      The bug this time isn't just a printing bug, but also a logical error
      when multiple options ("#"-separated strings) are given in the key
      payload.  Specifically, when separating an option string into name and
      value, if there is no value then the name is incorrectly considered to
      end at the end of the key payload, rather than the end of the current
      option.  This bypasses validation of the option length, and also means
      that specifying multiple options is broken -- which presumably has gone
      unnoticed as there is currently only one valid option anyway.
      
      A similar problem also applied to option values, as the kstrtoul() when
      parsing the "dnserror" option will read past the end of the current
      option and into the next option.
      
      Fix these bugs by correctly computing the length of the option name and
      by copying the option value, null-terminated, into a temporary buffer.
      
      Reproducer for the WARN_ONCE() that syzbot hit:
      
          perl -e 'print "#A#", "\0" x 50000' | keyctl padd dns_resolver desc @s
      
      Reproducer for "dnserror" option being parsed incorrectly (expected
      behavior is to fail when seeing the unknown option "foo", actual
      behavior was to read the dnserror value as "1#foo" and fail there):
      
          perl -e 'print "#dnserror=1#foo\0"' | keyctl padd dns_resolver desc @s
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Fixes: 4a2d7892 ("DNS: If the DNS server returns an error, allow that to be cached [ver #2]")
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c604cb76
    • David S. Miller's avatar
      Merge branch 'multicast-init-as-INCLUDE-when-join-SSM-INCLUDE-group' · 8e05fd83
      David S. Miller authored
      Hangbin Liu says:
      
      ====================
      multicast: init as INCLUDE when join SSM INCLUDE group
      
      Based on RFC3376 5.1 and RFC3810 6.1, we should init as INCLUDE when join SSM
      INCLUDE group. In my first version I only clear the group change record. But
      this is not enough as when a new group join, it will init as EXCLUDE and
      trigger an filter mode change in ip/ip6_mc_add_src(), which will clear all
      source addresses' sf_crcount. This will prevent early joined address sending
      state change records if multi source addresses joined at the same time.
      
      In this v2 patchset, I fixed it by directly initializing the mode to INCLUDE
      for SSM JOIN_SOURCE_GROUP. I also split the original patch into two separated
      patches for IPv4 and IPv6.
      
      Test: test by myself and customer.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8e05fd83
    • Hangbin Liu's avatar
      ipv6/mcast: init as INCLUDE when join SSM INCLUDE group · c7ea20c9
      Hangbin Liu authored
      This an IPv6 version patch of "ipv4/igmp: init group mode as INCLUDE when
      join source group". From RFC3810, part 6.1:
      
         If no per-interface state existed for that
         multicast address before the change (i.e., the change consisted of
         creating a new per-interface record), or if no state exists after the
         change (i.e., the change consisted of deleting a per-interface
         record), then the "non-existent" state is considered to have an
         INCLUDE filter mode and an empty source list.
      
      Which means a new multicast group should start with state IN(). Currently,
      for MLDv2 SSM JOIN_SOURCE_GROUP mode, we first call ipv6_sock_mc_join(),
      then ip6_mc_source(), which will trigger a TO_IN() message instead of
      ALLOW().
      
      The issue was exposed by commit a052517a ("net/multicast: should not
      send source list records when have filter mode change"). Before this change,
      we sent both ALLOW(A) and TO_IN(A). Now, we only send TO_IN(A).
      
      Fix it by adding a new parameter to init group mode. Also add some wrapper
      functions to avoid changing too much code.
      
      v1 -> v2:
      In the first version I only cleared the group change record. But this is not
      enough. Because when a new group join, it will init as EXCLUDE and trigger
      a filter mode change in ip/ip6_mc_add_src(), which will clear all source
      addresses sf_crcount. This will prevent early joined address sending state
      change records if multi source addressed joined at the same time.
      
      In v2 patch, I fixed it by directly initializing the mode to INCLUDE for SSM
      JOIN_SOURCE_GROUP. I also split the original patch into two separated patches
      for IPv4 and IPv6.
      
      There is also a difference between v4 and v6 version. For IPv6, when the
      interface goes down and up, we will send correct state change record with
      unspecified IPv6 address (::) with function ipv6_mc_up(). But after DAD is
      completed, we resend the change record TO_IN() in mld_send_initial_cr().
      Fix it by sending ALLOW() for INCLUDE mode in mld_send_initial_cr().
      
      Fixes: a052517a ("net/multicast: should not send source list records when have filter mode change")
      Reviewed-by: default avatarStefano Brivio <sbrivio@redhat.com>
      Signed-off-by: default avatarHangbin Liu <liuhangbin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c7ea20c9
    • Hangbin Liu's avatar
      ipv4/igmp: init group mode as INCLUDE when join source group · 6e2059b5
      Hangbin Liu authored
      Based on RFC3376 5.1
         If no interface
         state existed for that multicast address before the change (i.e., the
         change consisted of creating a new per-interface record), or if no
         state exists after the change (i.e., the change consisted of deleting
         a per-interface record), then the "non-existent" state is considered
         to have a filter mode of INCLUDE and an empty source list.
      
      Which means a new multicast group should start with state IN().
      
      Function ip_mc_join_group() works correctly for IGMP ASM(Any-Source Multicast)
      mode. It adds a group with state EX() and inits crcount to mc_qrv,
      so the kernel will send a TO_EX() report message after adding group.
      
      But for IGMPv3 SSM(Source-specific multicast) JOIN_SOURCE_GROUP mode, we
      split the group joining into two steps. First we join the group like ASM,
      i.e. via ip_mc_join_group(). So the state changes from IN() to EX().
      
      Then we add the source-specific address with INCLUDE mode. So the state
      changes from EX() to IN(A).
      
      Before the first step sends a group change record, we finished the second
      step. So we will only send the second change record. i.e. TO_IN(A).
      
      Regarding the RFC stands, we should actually send an ALLOW(A) message for
      SSM JOIN_SOURCE_GROUP as the state should mimic the 'IN() to IN(A)'
      transition.
      
      The issue was exposed by commit a052517a ("net/multicast: should not
      send source list records when have filter mode change"). Before this change,
      we used to send both ALLOW(A) and TO_IN(A). After this change we only send
      TO_IN(A).
      
      Fix it by adding a new parameter to init group mode. Also add new wrapper
      functions so we don't need to change too much code.
      
      v1 -> v2:
      In my first version I only cleared the group change record. But this is not
      enough. Because when a new group join, it will init as EXCLUDE and trigger
      an filter mode change in ip/ip6_mc_add_src(), which will clear all source
      addresses' sf_crcount. This will prevent early joined address sending state
      change records if multi source addressed joined at the same time.
      
      In v2 patch, I fixed it by directly initializing the mode to INCLUDE for SSM
      JOIN_SOURCE_GROUP. I also split the original patch into two separated patches
      for IPv4 and IPv6.
      
      Fixes: a052517a ("net/multicast: should not send source list records when have filter mode change")
      Reviewed-by: default avatarStefano Brivio <sbrivio@redhat.com>
      Signed-off-by: default avatarHangbin Liu <liuhangbin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6e2059b5
  2. 14 Jul, 2018 5 commits
  3. 13 Jul, 2018 7 commits
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf · c849eb0d
      David S. Miller authored
      Daniel Borkmann says:
      
      ====================
      pull-request: bpf 2018-07-13
      
      The following pull-request contains BPF updates for your *net* tree.
      
      The main changes are:
      
      1) Fix AF_XDP TX error reporting before final kernel release such that it
         becomes consistent between copy mode and zero-copy, from Magnus.
      
      2) Fix three different syzkaller reported issues: oob due to ld_abs
         rewrite with too large offset, another oob in l3 based skb test run
         and a bug leaving mangled prog in subprog JITing error path, from Daniel.
      
      3) Fix BTF handling for bitfield extraction on big endian, from Okash.
      
      4) Fix a missing linux/errno.h include in cgroup/BPF found by kbuild bot,
         from Roman.
      
      5) Fix xdp2skb_meta.sh sample by using just command names instead of
         absolute paths for tc and ip and allow them to be redefined, from Taeung.
      
      6) Fix availability probing for BPF seg6 helpers before final kernel ships
         so they can be detected at prog load time, from Mathieu.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c849eb0d
    • Stefano Brivio's avatar
      skbuff: Unconditionally copy pfmemalloc in __skb_clone() · e78bfb07
      Stefano Brivio authored
      Commit 8b700862 ("net: Don't copy pfmemalloc flag in
      __copy_skb_header()") introduced a different handling for the
      pfmemalloc flag in copy and clone paths.
      
      In __skb_clone(), now, the flag is set only if it was set in the
      original skb, but not cleared if it wasn't. This is wrong and
      might lead to socket buffers being flagged with pfmemalloc even
      if the skb data wasn't allocated from pfmemalloc reserves. Copy
      the flag instead of ORing it.
      Reported-by: default avatarSabrina Dubroca <sd@queasysnail.net>
      Fixes: 8b700862 ("net: Don't copy pfmemalloc flag in __copy_skb_header()")
      Signed-off-by: default avatarStefano Brivio <sbrivio@redhat.com>
      Tested-by: default avatarSabrina Dubroca <sd@queasysnail.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e78bfb07
    • Daniel Borkmann's avatar
      Merge branch 'bpf-af-xdp-consistent-err-reporting' · 5e3e6e83
      Daniel Borkmann authored
      Magnus Karlsson says:
      
      ====================
      This patch set adjusts the AF_XDP TX error reporting so that it becomes
      consistent between copy mode and zero-copy. First some background:
      
      Copy-mode for TX uses the SKB path in which the action of sending the
      packet is performed from process context using the sendmsg
      syscall. Completions are usually done asynchronously from NAPI mode by
      using a TX interrupt. In this mode, send errors can be returned back
      through the syscall.
      
      In zero-copy mode both the sending of the packet and the completions
      are done asynchronously from NAPI mode for performance reasons. In
      this mode, the sendmsg syscall only makes sure that the TX NAPI loop
      will be run that performs both the actions of sending and
      completing. In this mode it is therefore not possible to return errors
      through the sendmsg syscall as the sending is done from the NAPI
      loop. Note that it is possible to implement a synchronous send with
      our API, but in our benchmarks that made the TX performance drop by
      nearly half due to synchronization requirements and cache line
      bouncing. But for some netdevs this might be preferable so let us
      leave it up to the implementation to decide.
      
      The problem is that the current code base returns some errors in
      copy-mode that are not possible to return in zero-copy mode. This
      patch set aligns them so that the two modes always return the same
      error code. We achieve this by removing some of the errors returned by
      sendmsg in copy-mode (and in one case adding an error message for
      zero-copy mode) and offering alternative error detection methods that
      are consistent between the two modes.
      
      The structure of the patch set is as follows:
      
      Patch 1: removes the ENXIO return code from copy-mode when someone has
      forcefully changed the number of queues on the device so that the
      queue bound to the socket is no longer available. Just silently stop
      sending anything as in zero-copy mode.
      
      Patch 2: stop returning EAGAIN in copy mode when the completion queue
      is full as zero-copy does not do this. Instead this situation can be
      detected by comparing the head and tail pointers of the completion
      queue in both modes. In any case, EAGAIN was not the correct error code
      here since no amount of calling sendmsg will solve the problem. Only
      consuming one or more messages on the completion queue will fix this.
      
      Patch 3: Always return ENOBUFS from sendmsg if there is no TX queue
      configured. This was not the case for zero-copy mode.
      
      Patch 4: stop returning EMSGSIZE when the size of the packet is larger
      than the MTU. Just send it to the device so that it will drop it as in
      zero-copy mode.
      
      Note that copy-mode can still return EAGAIN in certain circumstances,
      but as these conditions cannot occur in zero-copy mode it is fine for
      copy-mode to return them.
      ====================
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      5e3e6e83
    • Magnus Karlsson's avatar
      xsk: do not return EMSGSIZE in copy mode for packets larger than MTU · 09210c4b
      Magnus Karlsson authored
      This patch stops returning EMSGSIZE from sendmsg in copy mode when the
      size of the packet is larger than the MTU. Just send it to the device
      so that it will drop it as in zero-copy mode. This makes the error
      reporting consistent between copy mode and zero-copy mode.
      
      Fixes: 35fcde7f ("xsk: support for Tx")
      Signed-off-by: default avatarMagnus Karlsson <magnus.karlsson@intel.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      09210c4b
    • Magnus Karlsson's avatar
      xsk: always return ENOBUFS from sendmsg if there is no TX queue · 6efb4436
      Magnus Karlsson authored
      This patch makes sure ENOBUFS is always returned from sendmsg if there
      is no TX queue configured. This was not the case for zero-copy
      mode. With this patch this error reporting is consistent between copy
      mode and zero-copy mode.
      
      Fixes: ac98d8aa ("xsk: wire upp Tx zero-copy functions")
      Signed-off-by: default avatarMagnus Karlsson <magnus.karlsson@intel.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      6efb4436
    • Magnus Karlsson's avatar
      xsk: do not return EAGAIN from sendmsg when completion queue is full · 9684f5e7
      Magnus Karlsson authored
      This patch stops returning EAGAIN in TX copy mode when the completion
      queue is full as zero-copy does not do this. Instead this situation
      can be detected by comparing the head and tail pointers of the
      completion queue in both modes. In any case, EAGAIN was not the
      correct error code here since no amount of calling sendmsg will solve
      the problem. Only consuming one or more messages on the completion
      queue will fix this.
      
      With this patch, the error reporting becomes consistent between copy
      mode and zero-copy mode.
      
      Fixes: 35fcde7f ("xsk: support for Tx")
      Signed-off-by: default avatarMagnus Karlsson <magnus.karlsson@intel.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      9684f5e7
    • Magnus Karlsson's avatar
      xsk: do not return ENXIO from TX copy mode · 509d7648
      Magnus Karlsson authored
      This patch removes the ENXIO return code from TX copy-mode when
      someone has forcefully changed the number of queues on the device so
      that the queue bound to the socket is no longer available. Just
      silently stop sending anything as in zero-copy mode so the error
      reporting gets consistent between the two modes.
      
      Fixes: 35fcde7f ("xsk: support for Tx")
      Signed-off-by: default avatarMagnus Karlsson <magnus.karlsson@intel.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      509d7648
  4. 12 Jul, 2018 21 commits
    • Willem de Bruijn's avatar
      selftests: in udpgso_bench do not test udp zerocopy · 8f19f12b
      Willem de Bruijn authored
      The udpgso benchmark compares various configurations of UDP and TCP.
      Including one that is not upstream, udp zerocopy. This is a leftover
      from the earlier RFC patchset.
      
      The test is part of kselftests and run in continuous spinners. Remove
      the failing case to make the test start passing.
      
      Fixes: 3a687bef ("selftests: udp gso benchmark")
      Reported-by: default avatarNaresh Kamboju <naresh.kamboju@linaro.org>
      Signed-off-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8f19f12b
    • Willem de Bruijn's avatar
      packet: reset network header if packet shorter than ll reserved space · 993675a3
      Willem de Bruijn authored
      If variable length link layer headers result in a packet shorter
      than dev->hard_header_len, reset the network header offset. Else
      skb->mac_len may exceed skb->len after skb_mac_reset_len.
      
      packet_sendmsg_spkt already has similar logic.
      
      Fixes: b84bbaf7 ("packet: in packet_snd start writing at link layer allocation")
      Signed-off-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      993675a3
    • Willem de Bruijn's avatar
      nsh: set mac len based on inner packet · bab2c80e
      Willem de Bruijn authored
      When pulling the NSH header in nsh_gso_segment, set the mac length
      based on the encapsulated packet type.
      
      skb_reset_mac_len computes an offset to the network header, which
      here still points to the outer packet:
      
        >     skb_reset_network_header(skb);
        >     [...]
        >     __skb_pull(skb, nsh_len);
        >     skb_reset_mac_header(skb);    // now mac hdr starts nsh_len == 8B after net hdr
        >     skb_reset_mac_len(skb);       // mac len = net hdr - mac hdr == (u16) -8 == 65528
        >     [..]
        >     skb_mac_gso_segment(skb, ..)
      
      Link: http://lkml.kernel.org/r/CAF=yD-KeAcTSOn4AxirAxL8m7QAS8GBBe1w09eziYwvPbbUeYA@mail.gmail.com
      Reported-by: syzbot+7b9ed9872dab8c32305d@syzkaller.appspotmail.com
      Fixes: c411ed85 ("nsh: add GSO support")
      Signed-off-by: default avatarWillem de Bruijn <willemb@google.com>
      Acked-by: default avatarJiri Benc <jbenc@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bab2c80e
    • Stefano Brivio's avatar
      net: Don't copy pfmemalloc flag in __copy_skb_header() · 8b700862
      Stefano Brivio authored
      The pfmemalloc flag indicates that the skb was allocated from
      the PFMEMALLOC reserves, and the flag is currently copied on skb
      copy and clone.
      
      However, an skb copied from an skb flagged with pfmemalloc
      wasn't necessarily allocated from PFMEMALLOC reserves, and on
      the other hand an skb allocated that way might be copied from an
      skb that wasn't.
      
      So we should not copy the flag on skb copy, and rather decide
      whether to allow an skb to be associated with sockets unrelated
      to page reclaim depending only on how it was allocated.
      
      Move the pfmemalloc flag before headers_start[0] using an
      existing 1-bit hole, so that __copy_skb_header() doesn't copy
      it.
      
      When cloning, we'll now take care of this flag explicitly,
      contravening to the warning comment of __skb_clone().
      
      While at it, restore the newline usage introduced by commit
      b1937227 ("net: reorganize sk_buff for faster
      __copy_skb_header()") to visually separate bytes used in
      bitfields after headers_start[0], that was gone after commit
      a9e419dc ("netfilter: merge ctinfo into nfct pointer storage
      area"), and describe the pfmemalloc flag in the kernel-doc
      structure comment.
      
      This doesn't change the size of sk_buff or cacheline boundaries,
      but consolidates the 15 bits hole before tc_index into a 2 bytes
      hole before csum, that could now be filled more easily.
      Reported-by: default avatarPatrick Talbert <ptalbert@redhat.com>
      Fixes: c93bdd0e ("netvm: allow skb allocation to use PFMEMALLOC reserves")
      Signed-off-by: default avatarStefano Brivio <sbrivio@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8b700862
    • David S. Miller's avatar
      Merge branch 'sfc-filter-locking-fixes' · 1ff9c66b
      David S. Miller authored
      Bert Kenward says:
      
      ====================
      sfc: filter locking fixes
      
      Two fixes for sfc ef10 filter table locking. Initially spotted
      by lockdep, but one issue has also been seen in normal use.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1ff9c66b
    • Bert Kenward's avatar
      sfc: hold filter_sem consistently during reset · 193f2003
      Bert Kenward authored
      We should take and release the filter_sem consistently during the
      reset process, in the same manner as the mac_lock and reset_lock.
      
      For lockdep consistency we also take the filter_sem for write around
      other calls to efx->type->init().
      
      Fixes: c2bebe37 ("sfc: give ef10 its own rwsem in the filter table instead of filter_lock")
      Signed-off-by: default avatarBert Kenward <bkenward@solarflare.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      193f2003
    • Bert Kenward's avatar
      sfc: avoid hang from nested use of the filter_sem · 1c56c099
      Bert Kenward authored
      In some situations we may end up calling down_read while already
      holding the semaphore for write, thus hanging. This has been seen
      when setting the MAC address for the interface. The hung task log
      in this situation includes this stack:
        down_read
        efx_ef10_filter_insert
        efx_ef10_filter_insert_addr_list
        efx_ef10_filter_vlan_sync_rx_mode
        efx_ef10_filter_add_vlan
        efx_ef10_filter_table_probe
        efx_ef10_set_mac_address
        efx_set_mac_address
        dev_set_mac_address
      
      In addition, lockdep rightly points out that nested calling of
      down_read is incorrect.
      
      Fixes: c2bebe37 ("sfc: give ef10 its own rwsem in the filter table instead of filter_lock")
      Tested-by: default avatarJarod Wilson <jarod@redhat.com>
      Signed-off-by: default avatarBert Kenward <bkenward@solarflare.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1c56c099
    • Florian Fainelli's avatar
      net: systemport: Fix CRC forwarding check for SYSTEMPORT Lite · 9e3bff92
      Florian Fainelli authored
      SYSTEMPORT Lite reversed the logic compared to SYSTEMPORT, the
      GIB_FCS_STRIP bit is set when the Ethernet FCS is stripped, and that bit
      is not set by default. Fix the logic such that we properly check whether
      that bit is set or not and we don't forward an extra 4 bytes to the
      network stack.
      
      Fixes: 44a4524c ("net: systemport: Add support for SYSTEMPORT Lite")
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9e3bff92
    • Stefan Baranoff's avatar
      tcp: allow user to create repair socket without window probes · 70b7ff13
      Stefan Baranoff authored
      Under rare conditions where repair code may be used it is possible that
      window probes are either unnecessary or undesired. If the user knows that
      window probes are not wanted or needed this change allows them to skip
      sending them when a socket comes out of repair.
      Signed-off-by: default avatarStefan Baranoff <sbaranoff@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      70b7ff13
    • Stefan Baranoff's avatar
      tcp: fix sequence numbers for repaired sockets re-using TIME-WAIT sockets · 21684dc4
      Stefan Baranoff authored
      This patch fixes a bug where the sequence numbers of a socket created using
      TCP repair functionality are lower than set after connect is called.
      This occurs when the repair socket overlaps with a TIME-WAIT socket and
      triggers the re-use code. The amount lower is equal to the number of times
      that a particular IP/port set is re-used and then put back into TIME-WAIT.
      Re-using the first time the sequence number is 1 lower, closing that socket
      and then re-opening (with repair) a new socket with the same addresses/ports
      puts the sequence number 2 lower than set via setsockopt. The third time is
      3 lower, etc. I have not tested what the limit of this acrewal is, if any.
      
      The fix is, if a socket is in repair mode, to respect the already set
      sequence number and timestamp when it would have already re-used the
      TIME-WAIT socket.
      Signed-off-by: default avatarStefan Baranoff <sbaranoff@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      21684dc4
    • Daniel Borkmann's avatar
      bpf: don't leave partial mangled prog in jit_subprogs error path · c7a89784
      Daniel Borkmann authored
      syzkaller managed to trigger the following bug through fault injection:
      
        [...]
        [  141.043668] verifier bug. No program starts at insn 3
        [  141.044648] WARNING: CPU: 3 PID: 4072 at kernel/bpf/verifier.c:1613
                       get_callee_stack_depth kernel/bpf/verifier.c:1612 [inline]
        [  141.044648] WARNING: CPU: 3 PID: 4072 at kernel/bpf/verifier.c:1613
                       fixup_call_args kernel/bpf/verifier.c:5587 [inline]
        [  141.044648] WARNING: CPU: 3 PID: 4072 at kernel/bpf/verifier.c:1613
                       bpf_check+0x525e/0x5e60 kernel/bpf/verifier.c:5952
        [  141.047355] CPU: 3 PID: 4072 Comm: a.out Not tainted 4.18.0-rc4+ #51
        [  141.048446] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),BIOS 1.10.2-1 04/01/2014
        [  141.049877] Call Trace:
        [  141.050324]  __dump_stack lib/dump_stack.c:77 [inline]
        [  141.050324]  dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
        [  141.050950]  ? dump_stack_print_info.cold.2+0x52/0x52 lib/dump_stack.c:60
        [  141.051837]  panic+0x238/0x4e7 kernel/panic.c:184
        [  141.052386]  ? add_taint.cold.5+0x16/0x16 kernel/panic.c:385
        [  141.053101]  ? __warn.cold.8+0x148/0x1ba kernel/panic.c:537
        [  141.053814]  ? __warn.cold.8+0x117/0x1ba kernel/panic.c:530
        [  141.054506]  ? get_callee_stack_depth kernel/bpf/verifier.c:1612 [inline]
        [  141.054506]  ? fixup_call_args kernel/bpf/verifier.c:5587 [inline]
        [  141.054506]  ? bpf_check+0x525e/0x5e60 kernel/bpf/verifier.c:5952
        [  141.055163]  __warn.cold.8+0x163/0x1ba kernel/panic.c:538
        [  141.055820]  ? get_callee_stack_depth kernel/bpf/verifier.c:1612 [inline]
        [  141.055820]  ? fixup_call_args kernel/bpf/verifier.c:5587 [inline]
        [  141.055820]  ? bpf_check+0x525e/0x5e60 kernel/bpf/verifier.c:5952
        [...]
      
      What happens in jit_subprogs() is that kcalloc() for the subprog func
      buffer is failing with NULL where we then bail out. Latter is a plain
      return -ENOMEM, and this is definitely not okay since earlier in the
      loop we are walking all subprogs and temporarily rewrite insn->off to
      remember the subprog id as well as insn->imm to temporarily point the
      call to __bpf_call_base + 1 for the initial JIT pass. Thus, bailing
      out in such state and handing this over to the interpreter is troublesome
      since later/subsequent e.g. find_subprog() lookups are based on wrong
      insn->imm.
      
      Therefore, once we hit this point, we need to jump to out_free path
      where we undo all changes from earlier loop, so that interpreter can
      work on unmodified insn->{off,imm}.
      
      Another point is that should find_subprog() fail in jit_subprogs() due
      to a verifier bug, then we also should not simply defer the program to
      the interpreter since also here we did partial modifications. Instead
      we should just bail out entirely and return an error to the user who is
      trying to load the program.
      
      Fixes: 1c2a088a ("bpf: x64: add JIT support for multi-function programs")
      Reported-by: syzbot+7d427828b2ea6e592804@syzkaller.appspotmail.com
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      c7a89784
    • Jacob Keller's avatar
      sch_fq_codel: zero q->flows_cnt when fq_codel_init fails · 83fe6b87
      Jacob Keller authored
      When fq_codel_init fails, qdisc_create_dflt will cleanup by using
      qdisc_destroy. This function calls the ->reset() op prior to calling the
      ->destroy() op.
      
      Unfortunately, during the failure flow for sch_fq_codel, the ->flows
      parameter is not initialized, so the fq_codel_reset function will null
      pointer dereference.
      
         kernel: BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
         kernel: IP: fq_codel_reset+0x58/0xd0 [sch_fq_codel]
         kernel: PGD 0 P4D 0
         kernel: Oops: 0000 [#1] SMP PTI
         kernel: Modules linked in: i40iw i40e(OE) xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack tun bridge stp llc devlink ebtable_filter ebtables ip6table_filter ip6_tables rpcrdma ib_isert iscsi_target_mod sunrpc ib_iser libiscsi scsi_transport_iscsi ib_srpt target_core_mod ib_srp scsi_transport_srp ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm intel_rapl sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel intel_cstate iTCO_wdt iTCO_vendor_support intel_uncore ib_core intel_rapl_perf mei_me mei joydev i2c_i801 lpc_ich ioatdma shpchp wmi sch_fq_codel xfs libcrc32c mgag200 ixgbe drm_kms_helper isci ttm firewire_ohci
         kernel:  mdio drm igb libsas crc32c_intel firewire_core ptp pps_core scsi_transport_sas crc_itu_t dca i2c_algo_bit ipmi_si ipmi_devintf ipmi_msghandler [last unloaded: i40e]
         kernel: CPU: 10 PID: 4219 Comm: ip Tainted: G           OE    4.16.13custom-fq-codel-test+ #3
         kernel: Hardware name: Intel Corporation S2600CO/S2600CO, BIOS SE5C600.86B.02.05.0004.051120151007 05/11/2015
         kernel: RIP: 0010:fq_codel_reset+0x58/0xd0 [sch_fq_codel]
         kernel: RSP: 0018:ffffbfbf4c1fb620 EFLAGS: 00010246
         kernel: RAX: 0000000000000400 RBX: 0000000000000000 RCX: 00000000000005b9
         kernel: RDX: 0000000000000000 RSI: ffff9d03264a60c0 RDI: ffff9cfd17b31c00
         kernel: RBP: 0000000000000001 R08: 00000000000260c0 R09: ffffffffb679c3e9
         kernel: R10: fffff1dab06a0e80 R11: ffff9cfd163af800 R12: ffff9cfd17b31c00
         kernel: R13: 0000000000000001 R14: ffff9cfd153de600 R15: 0000000000000001
         kernel: FS:  00007fdec2f92800(0000) GS:ffff9d0326480000(0000) knlGS:0000000000000000
         kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
         kernel: CR2: 0000000000000008 CR3: 0000000c1956a006 CR4: 00000000000606e0
         kernel: Call Trace:
         kernel:  qdisc_destroy+0x56/0x140
         kernel:  qdisc_create_dflt+0x8b/0xb0
         kernel:  mq_init+0xc1/0xf0
         kernel:  qdisc_create_dflt+0x5a/0xb0
         kernel:  dev_activate+0x205/0x230
         kernel:  __dev_open+0xf5/0x160
         kernel:  __dev_change_flags+0x1a3/0x210
         kernel:  dev_change_flags+0x21/0x60
         kernel:  do_setlink+0x660/0xdf0
         kernel:  ? down_trylock+0x25/0x30
         kernel:  ? xfs_buf_trylock+0x1a/0xd0 [xfs]
         kernel:  ? rtnl_newlink+0x816/0x990
         kernel:  ? _xfs_buf_find+0x327/0x580 [xfs]
         kernel:  ? _cond_resched+0x15/0x30
         kernel:  ? kmem_cache_alloc+0x20/0x1b0
         kernel:  ? rtnetlink_rcv_msg+0x200/0x2f0
         kernel:  ? rtnl_calcit.isra.30+0x100/0x100
         kernel:  ? netlink_rcv_skb+0x4c/0x120
         kernel:  ? netlink_unicast+0x19e/0x260
         kernel:  ? netlink_sendmsg+0x1ff/0x3c0
         kernel:  ? sock_sendmsg+0x36/0x40
         kernel:  ? ___sys_sendmsg+0x295/0x2f0
         kernel:  ? ebitmap_cmp+0x6d/0x90
         kernel:  ? dev_get_by_name_rcu+0x73/0x90
         kernel:  ? skb_dequeue+0x52/0x60
         kernel:  ? __inode_wait_for_writeback+0x7f/0xf0
         kernel:  ? bit_waitqueue+0x30/0x30
         kernel:  ? fsnotify_grab_connector+0x3c/0x60
         kernel:  ? __sys_sendmsg+0x51/0x90
         kernel:  ? do_syscall_64+0x74/0x180
         kernel:  ? entry_SYSCALL_64_after_hwframe+0x3d/0xa2
         kernel: Code: 00 00 48 89 87 00 02 00 00 8b 87 a0 01 00 00 85 c0 0f 84 84 00 00 00 31 ed 48 63 dd 83 c5 01 48 c1 e3 06 49 03 9c 24 90 01 00 00 <48> 8b 73 08 48 8b 3b e8 6c 9a 4f f6 48 8d 43 10 48 c7 03 00 00
         kernel: RIP: fq_codel_reset+0x58/0xd0 [sch_fq_codel] RSP: ffffbfbf4c1fb620
         kernel: CR2: 0000000000000008
         kernel: ---[ end trace e81a62bede66274e ]---
      
      This is caused because flows_cnt is non-zero, but flows hasn't been
      initialized. fq_codel_init has left the private data in a partially
      initialized state.
      
      To fix this, reset flows_cnt to 0 when we fail to initialize.
      Additionally, to make the state more consistent, also cleanup the flows
      pointer when the allocation of backlogs fails.
      
      This fixes the NULL pointer dereference, since both the for-loop and
      memset in fq_codel_reset will be no-ops when flow_cnt is zero.
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      83fe6b87
    • David S. Miller's avatar
      Merge branch '10GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue · 35288486
      David S. Miller authored
      Jeff Kirsher says:
      
      ====================
      Intel Wired LAN Driver Updates 2018-07-12
      
      This series contains updates to ixgbe and e100/e1000 kernel documentation.
      
      Alex fixes ixgbe to ensure that we are more explicit about the ordering
      of updates to the receive address register (RAR) table.
      
      Dan Carpenter fixes an issue where we were reading one element beyond
      the end of the array.
      
      Mauro Carvalho Chehab fixes formatting issues in the e100.rst and
      e1000.rst that were causing errors during 'make htmldocs'.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      35288486
    • Mauro Carvalho Chehab's avatar
      networking: e1000.rst: Get rid of Sphinx warnings · 8dc4b1a7
      Mauro Carvalho Chehab authored
      Documentation/networking/e1000.rst:83: ERROR: Unexpected indentation.
          Documentation/networking/e1000.rst:84: WARNING: Block quote ends without a blank line; unexpected unindent.
          Documentation/networking/e1000.rst:173: WARNING: Definition list ends without a blank line; unexpected unindent.
          Documentation/networking/e1000.rst:236: WARNING: Definition list ends without a blank line; unexpected unindent.
      
      While here, fix highlights and mark a table as such.
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      8dc4b1a7
    • Mauro Carvalho Chehab's avatar
      networking: e100.rst: Get rid of Sphinx warnings · b203cc7a
      Mauro Carvalho Chehab authored
      Documentation/networking/e100.rst:57: WARNING: Literal block expected; none found.
          Documentation/networking/e100.rst:68: WARNING: Literal block expected; none found.
          Documentation/networking/e100.rst:75: WARNING: Literal block expected; none found.
          Documentation/networking/e100.rst:84: WARNING: Literal block expected; none found.
          Documentation/networking/e100.rst:93: WARNING: Inline emphasis start-string without end-string.
      
      While here, fix some highlights.
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab+samsung@kernel.org>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      b203cc7a
    • Dan Carpenter's avatar
      ixgbe: Off by one in ixgbe_ipsec_tx() · c4111041
      Dan Carpenter authored
      The ipsec->tx_tbl[] has IXGBE_IPSEC_MAX_SA_COUNT elements so the > needs
      to be changed to >= so we don't read one element beyond the end of the
      array.
      
      Fixes: 59259470 ("ixgbe: process the Tx ipsec offload")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Acked-by: default avatarShannon Nelson <shannon.nelson@oracle.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      c4111041
    • Alexander Duyck's avatar
      ixgbe: Be more careful when modifying MAC filters · d14c780c
      Alexander Duyck authored
      This change makes it so that we are much more explicit about the ordering
      of updates to the receive address register (RAR) table. Prior to this patch
      I believe we may have been updating the table while entries were still
      active, or possibly allowing for reordering of things since we weren't
      explicitly flushing writes to either the lower or upper portion of the
      register prior to accessing the other half.
      Signed-off-by: default avatarAlexander Duyck <alexander.h.duyck@intel.com>
      Reviewed-by: default avatarShannon Nelson <shannon.nelson@oracle.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      d14c780c
    • David S. Miller's avatar
      Merge branch 'ieee802154-for-davem-2018-07-11' of... · 672f5cce
      David S. Miller authored
      Merge branch 'ieee802154-for-davem-2018-07-11' of git://git.kernel.org/pub/scm/linux/kernel/git/sschmidt/wpan
      
      Stefan Schmidt says:
      
      ====================
      pull-request: ieee802154 for net 2018-07-11
      
      An update from ieee802154 for your *net* tree.
      
      Build system fix for a missing include from Arnd Bergmann.
      Setting the IFLA_LINK for the lowpan parent from Lubomir Rintel.
      Fixes for some RX corner cases in adf7242 driver by Michael Hennerich.
      And some small patches to cleanup our BUG_ON vs WARN_ON usage.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      672f5cce
    • Ewan D. Milne's avatar
      qed: fix spelling mistake "successffuly" -> "successfully" · 20c4515a
      Ewan D. Milne authored
      Trivial fix to spelling mistake in qed_probe message.
      Signed-off-by: default avatarEwan D. Milne <emilne@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      20c4515a
    • Russell King's avatar
      sfp: fix module initialisation with netdev already up · 576cd320
      Russell King authored
      It was been observed that with a particular order of initialisation,
      the netdev can be up, but the SFP module still has its TX_DISABLE
      signal asserted.  This occurs when the network device brought up before
      the SFP kernel module has been inserted by userspace.
      
      This occurs because sfp-bus layer does not hear about the change in
      network device state, and so assumes that it is still down.  Set
      netdev->sfp when the upstream is registered to work around this problem.
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      576cd320
    • Russell King's avatar
      sfp: ensure we clean up properly on bus registration failure · f20a4c46
      Russell King authored
      We fail to correctly clean up after a bus registration failure, which
      can lead to an incorrect assumption about the registration state of
      the upstream or sfp cage.
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f20a4c46
  5. 11 Jul, 2018 3 commits
    • Daniel Borkmann's avatar
      bpf: fix panic due to oob in bpf_prog_test_run_skb · 6e6fddc7
      Daniel Borkmann authored
      sykzaller triggered several panics similar to the below:
      
        [...]
        [  248.851531] BUG: KASAN: use-after-free in _copy_to_user+0x5c/0x90
        [  248.857656] Read of size 985 at addr ffff8808017ffff2 by task a.out/1425
        [...]
        [  248.865902] CPU: 1 PID: 1425 Comm: a.out Not tainted 4.18.0-rc4+ #13
        [  248.865903] Hardware name: Supermicro SYS-5039MS-H12TRF/X11SSE-F, BIOS 2.1a 03/08/2018
        [  248.865905] Call Trace:
        [  248.865910]  dump_stack+0xd6/0x185
        [  248.865911]  ? show_regs_print_info+0xb/0xb
        [  248.865913]  ? printk+0x9c/0xc3
        [  248.865915]  ? kmsg_dump_rewind_nolock+0xe4/0xe4
        [  248.865919]  print_address_description+0x6f/0x270
        [  248.865920]  kasan_report+0x25b/0x380
        [  248.865922]  ? _copy_to_user+0x5c/0x90
        [  248.865924]  check_memory_region+0x137/0x190
        [  248.865925]  kasan_check_read+0x11/0x20
        [  248.865927]  _copy_to_user+0x5c/0x90
        [  248.865930]  bpf_test_finish.isra.8+0x4f/0xc0
        [  248.865932]  bpf_prog_test_run_skb+0x6a0/0xba0
        [...]
      
      After scrubbing the BPF prog a bit from the noise, turns out it called
      bpf_skb_change_head() for the lwt_xmit prog with headroom of 2. Nothing
      wrong in that, however, this was run with repeat >> 0 in bpf_prog_test_run_skb()
      and the same skb thus keeps changing until the pskb_expand_head() called
      from skb_cow() keeps bailing out in atomic alloc context with -ENOMEM.
      So upon return we'll basically have 0 headroom left yet blindly do the
      __skb_push() of 14 bytes and keep copying data from there in bpf_test_finish()
      out of bounds. Fix to check if we have enough headroom and if pskb_expand_head()
      fails, bail out with error.
      
      Another bug independent of this fix (but related in triggering above) is
      that BPF_PROG_TEST_RUN should be reworked to reset the skb/xdp buffer to
      it's original state from input as otherwise repeating the same test in a
      loop won't work for benchmarking when underlying input buffer is getting
      changed by the prog each time and reused for the next run leading to
      unexpected results.
      
      Fixes: 1cf1cae9 ("bpf: introduce BPF_PROG_TEST_RUN command")
      Reported-by: syzbot+709412e651e55ed96498@syzkaller.appspotmail.com
      Reported-by: syzbot+54f39d6ab58f39720a55@syzkaller.appspotmail.com
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      6e6fddc7
    • Okash Khawaja's avatar
      bpf: btf: Fix bitfield extraction for big endian · b65f370d
      Okash Khawaja authored
      When extracting bitfield from a number, btf_int_bits_seq_show() builds
      a mask and accesses least significant byte of the number in a way
      specific to little-endian. This patch fixes that by checking endianness
      of the machine and then shifting left and right the unneeded bits.
      
      Thanks to Martin Lau for the help in navigating potential pitfalls when
      dealing with endianess and for the final solution.
      
      Fixes: b00b8dae ("bpf: btf: Add pretty print capability for data with BTF type info")
      Signed-off-by: default avatarOkash Khawaja <osk@fb.com>
      Acked-by: default avatarMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      b65f370d
    • Mathieu Xhonneux's avatar
      bpf: fix availability probing for seg6 helpers · 61d76980
      Mathieu Xhonneux authored
      bpf_lwt_seg6_* helpers require CONFIG_IPV6_SEG6_BPF, and currently
      return -EOPNOTSUPP to indicate unavailability. This patch forces the
      BPF verifier to reject programs using these helpers when
      !CONFIG_IPV6_SEG6_BPF, allowing users to more easily probe if they are
      available or not.
      Signed-off-by: default avatarMathieu Xhonneux <m.xhonneux@gmail.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      61d76980