1. 20 Feb, 2020 6 commits
    • Kees Cook's avatar
      net: core: Distribute switch variables for initialization · 161d1792
      Kees Cook authored
      Variables declared in a switch statement before any case statements
      cannot be automatically initialized with compiler instrumentation (as
      they are not part of any execution flow). With GCC's proposed automatic
      stack variable initialization feature, this triggers a warning (and they
      don't get initialized). Clang's automatic stack variable initialization
      (via CONFIG_INIT_STACK_ALL=y) doesn't throw a warning, but it also
      doesn't initialize such variables[1]. Note that these warnings (or silent
      skipping) happen before the dead-store elimination optimization phase,
      so even when the automatic initializations are later elided in favor of
      direct initializations, the warnings remain.
      
      To avoid these problems, move such variables into the "case" where
      they're used or lift them up into the main function body.
      
      net/core/skbuff.c: In function ‘skb_checksum_setup_ip’:
      net/core/skbuff.c:4809:7: warning: statement will never be executed [-Wswitch-unreachable]
       4809 |   int err;
            |       ^~~
      
      [1] https://bugs.llvm.org/show_bug.cgi?id=44916Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      161d1792
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf · 41f57cfd
      David S. Miller authored
      Alexei Starovoitov says:
      
      ====================
      pull-request: bpf 2020-02-19
      
      The following pull-request contains BPF updates for your *net* tree.
      
      We've added 10 non-merge commits during the last 10 day(s) which contain
      a total of 10 files changed, 93 insertions(+), 31 deletions(-).
      
      The main changes are:
      
      1) batched bpf hashtab fixes from Brian and Yonghong.
      
      2) various selftests and libbpf fixes.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      41f57cfd
    • David S. Miller's avatar
      Merge branch '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue · fca07a93
      David S. Miller authored
      Jeff Kirsher says:
      
      ====================
      Intel Wired LAN Driver Updates 2020-02-19
      
      This series contains fixes to the ice driver.
      
      Brett fixes an issue where if a user sets an odd [tx|rx]-usecs value
      through ethtool, the request is denied because the hardware is set to
      have an ITR with 2us granularity.  Also fix an issue where the VF has
      not been completely removed/reset after being unbound from the host
      driver, so resolve this by waiting for the VF remove/reset process to
      happen before checking if the VF is disabled.
      
      Michal fixes an issue, where when the user changes flow control via
      ethtool, the OS is told the link is going down when that may not be the
      case.  Before the fix, the only way to get out of this state was to take
      the interface down and up again.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fca07a93
    • Willem de Bruijn's avatar
      udp: rehash on disconnect · 303d0403
      Willem de Bruijn authored
      As of the below commit, udp sockets bound to a specific address can
      coexist with one bound to the any addr for the same port.
      
      The commit also phased out the use of socket hashing based only on
      port (hslot), in favor of always hashing on {addr, port} (hslot2).
      
      The change broke the following behavior with disconnect (AF_UNSPEC):
      
          server binds to 0.0.0.0:1337
          server connects to 127.0.0.1:80
          server disconnects
          client connects to 127.0.0.1:1337
          client sends "hello"
          server reads "hello"	// times out, packet did not find sk
      
      On connect the server acquires a specific source addr suitable for
      routing to its destination. On disconnect it reverts to the any addr.
      
      The connect call triggers a rehash to a different hslot2. On
      disconnect, add the same to return to the original hslot2.
      
      Skip this step if the socket is going to be unhashed completely.
      
      Fixes: 4cdeeee9 ("net: udp: prefer listeners bound to an address")
      Reported-by: default avatarPavel Roskin <plroskin@gmail.com>
      Signed-off-by: default avatarWillem de Bruijn <willemb@google.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      303d0403
    • Rohit Maheshwari's avatar
      net/tls: Fix to avoid gettig invalid tls record · 06f5201c
      Rohit Maheshwari authored
      Current code doesn't check if tcp sequence number is starting from (/after)
      1st record's start sequnce number. It only checks if seq number is before
      1st record's end sequnce number. This problem will always be a possibility
      in re-transmit case. If a record which belongs to a requested seq number is
      already deleted, tls_get_record will start looking into list and as per the
      check it will look if seq number is before the end seq of 1st record, which
      will always be true and will return 1st record always, it should in fact
      return NULL.
      As part of the fix, start looking each record only if the sequence number
      lies in the list else return NULL.
      There is one more check added, driver look for the start marker record to
      handle tcp packets which are before the tls offload start sequence number,
      hence return 1st record if the record is tls start marker and seq number is
      before the 1st record's starting sequence number.
      
      Fixes: e8f69799 ("net/tls: Add generic NIC offload infrastructure")
      Signed-off-by: default avatarRohit Maheshwari <rohitm@chelsio.com>
      Reviewed-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      06f5201c
    • Yonghong Song's avatar
      bpf: Fix a potential deadlock with bpf_map_do_batch · b9aff38d
      Yonghong Song authored
      Commit 05799638 ("bpf: Add batch ops to all htab bpf map")
      added lookup_and_delete batch operation for hash table.
      The current implementation has bpf_lru_push_free() inside
      the bucket lock, which may cause a deadlock.
      
      syzbot reports:
         -> #2 (&htab->buckets[i].lock#2){....}:
             __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
             _raw_spin_lock_irqsave+0x95/0xcd kernel/locking/spinlock.c:159
             htab_lru_map_delete_node+0xce/0x2f0 kernel/bpf/hashtab.c:593
             __bpf_lru_list_shrink_inactive kernel/bpf/bpf_lru_list.c:220 [inline]
             __bpf_lru_list_shrink+0xf9/0x470 kernel/bpf/bpf_lru_list.c:266
             bpf_lru_list_pop_free_to_local kernel/bpf/bpf_lru_list.c:340 [inline]
             bpf_common_lru_pop_free kernel/bpf/bpf_lru_list.c:447 [inline]
             bpf_lru_pop_free+0x87c/0x1670 kernel/bpf/bpf_lru_list.c:499
             prealloc_lru_pop+0x2c/0xa0 kernel/bpf/hashtab.c:132
             __htab_lru_percpu_map_update_elem+0x67e/0xa90 kernel/bpf/hashtab.c:1069
             bpf_percpu_hash_update+0x16e/0x210 kernel/bpf/hashtab.c:1585
             bpf_map_update_value.isra.0+0x2d7/0x8e0 kernel/bpf/syscall.c:181
             generic_map_update_batch+0x41f/0x610 kernel/bpf/syscall.c:1319
             bpf_map_do_batch+0x3f5/0x510 kernel/bpf/syscall.c:3348
             __do_sys_bpf+0x9b7/0x41e0 kernel/bpf/syscall.c:3460
             __se_sys_bpf kernel/bpf/syscall.c:3355 [inline]
             __x64_sys_bpf+0x73/0xb0 kernel/bpf/syscall.c:3355
             do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294
             entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
         -> #0 (&loc_l->lock){....}:
             check_prev_add kernel/locking/lockdep.c:2475 [inline]
             check_prevs_add kernel/locking/lockdep.c:2580 [inline]
             validate_chain kernel/locking/lockdep.c:2970 [inline]
             __lock_acquire+0x2596/0x4a00 kernel/locking/lockdep.c:3954
             lock_acquire+0x190/0x410 kernel/locking/lockdep.c:4484
             __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
             _raw_spin_lock_irqsave+0x95/0xcd kernel/locking/spinlock.c:159
             bpf_common_lru_push_free kernel/bpf/bpf_lru_list.c:516 [inline]
             bpf_lru_push_free+0x250/0x5b0 kernel/bpf/bpf_lru_list.c:555
             __htab_map_lookup_and_delete_batch+0x8d4/0x1540 kernel/bpf/hashtab.c:1374
             htab_lru_map_lookup_and_delete_batch+0x34/0x40 kernel/bpf/hashtab.c:1491
             bpf_map_do_batch+0x3f5/0x510 kernel/bpf/syscall.c:3348
             __do_sys_bpf+0x1f7d/0x41e0 kernel/bpf/syscall.c:3456
             __se_sys_bpf kernel/bpf/syscall.c:3355 [inline]
             __x64_sys_bpf+0x73/0xb0 kernel/bpf/syscall.c:3355
             do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294
             entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
          Possible unsafe locking scenario:
      
                CPU0                    CPU2
                ----                    ----
           lock(&htab->buckets[i].lock#2);
                                        lock(&l->lock);
                                        lock(&htab->buckets[i].lock#2);
           lock(&loc_l->lock);
      
          *** DEADLOCK ***
      
      To fix the issue, for htab_lru_map_lookup_and_delete_batch() in CPU0,
      let us do bpf_lru_push_free() out of the htab bucket lock. This can
      avoid the above deadlock scenario.
      
      Fixes: 05799638 ("bpf: Add batch ops to all htab bpf map")
      Reported-by: syzbot+a38ff3d9356388f2fb83@syzkaller.appspotmail.com
      Reported-by: syzbot+122b5421d14e68f29cd1@syzkaller.appspotmail.com
      Suggested-by: default avatarHillf Danton <hdanton@sina.com>
      Suggested-by: default avatarMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: default avatarYonghong Song <yhs@fb.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Reviewed-by: default avatarJakub Sitnicki <jakub@cloudflare.com>
      Acked-by: default avatarBrian Vazquez <brianvv@google.com>
      Acked-by: default avatarMartin KaFai Lau <kafai@fb.com>
      Link: https://lore.kernel.org/bpf/20200219234757.3544014-1-yhs@fb.com
      b9aff38d
  2. 19 Feb, 2020 15 commits
  3. 18 Feb, 2020 19 commits