1. 24 Aug, 2019 1 commit
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf · 211c4624
      David S. Miller authored
      Daniel Borkmann says:
      
      ====================
      pull-request: bpf 2019-08-24
      
      The following pull-request contains BPF updates for your *net* tree.
      
      The main changes are:
      
      1) Fix verifier precision tracking with BPF-to-BPF calls, from Alexei.
      
      2) Fix a use-after-free in prog symbol exposure, from Daniel.
      
      3) Several s390x JIT fixes plus BE related fixes in BPF kselftests, from Ilya.
      
      4) Fix memory leak by unpinning XDP umem pages in error path, from Ivan.
      
      5) Fix a potential use-after-free on flow dissector detach, from Jakub.
      
      6) Fix bpftool to close prog fd after showing metadata, from Quentin.
      
      7) BPF kselftest config and TEST_PROGS_EXTENDED fixes, from Anders.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      211c4624
  2. 23 Aug, 2019 7 commits
    • Ilya Leoshkevich's avatar
      bpf: allow narrow loads of some sk_reuseport_md fields with offset > 0 · 2c238177
      Ilya Leoshkevich authored
      test_select_reuseport fails on s390 due to verifier rejecting
      test_select_reuseport_kern.o with the following message:
      
      	; data_check.eth_protocol = reuse_md->eth_protocol;
      	18: (69) r1 = *(u16 *)(r6 +22)
      	invalid bpf_context access off=22 size=2
      
      This is because on big-endian machines casts from __u32 to __u16 are
      generated by referencing the respective variable as __u16 with an offset
      of 2 (as opposed to 0 on little-endian machines).
      
      The verifier already has all the infrastructure in place to allow such
      accesses, it's just that they are not explicitly enabled for
      eth_protocol field. Enable them for eth_protocol field by using
      bpf_ctx_range instead of offsetof.
      
      Ditto for ip_protocol, bind_inany and len, since they already allow
      narrowing, and the same problem can arise when working with them.
      
      Fixes: 2dbb9b9e ("bpf: Introduce BPF_PROG_TYPE_SK_REUSEPORT")
      Signed-off-by: default avatarIlya Leoshkevich <iii@linux.ibm.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      2c238177
    • Daniel Borkmann's avatar
      bpf: fix use after free in prog symbol exposure · c751798a
      Daniel Borkmann authored
      syzkaller managed to trigger the warning in bpf_jit_free() which checks via
      bpf_prog_kallsyms_verify_off() for potentially unlinked JITed BPF progs
      in kallsyms, and subsequently trips over GPF when walking kallsyms entries:
      
        [...]
        8021q: adding VLAN 0 to HW filter on device batadv0
        8021q: adding VLAN 0 to HW filter on device batadv0
        WARNING: CPU: 0 PID: 9869 at kernel/bpf/core.c:810 bpf_jit_free+0x1e8/0x2a0
        Kernel panic - not syncing: panic_on_warn set ...
        CPU: 0 PID: 9869 Comm: kworker/0:7 Not tainted 5.0.0-rc8+ #1
        Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
        Workqueue: events bpf_prog_free_deferred
        Call Trace:
         __dump_stack lib/dump_stack.c:77 [inline]
         dump_stack+0x113/0x167 lib/dump_stack.c:113
         panic+0x212/0x40b kernel/panic.c:214
         __warn.cold.8+0x1b/0x38 kernel/panic.c:571
         report_bug+0x1a4/0x200 lib/bug.c:186
         fixup_bug arch/x86/kernel/traps.c:178 [inline]
         do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:271
         do_invalid_op+0x36/0x40 arch/x86/kernel/traps.c:290
         invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:973
        RIP: 0010:bpf_jit_free+0x1e8/0x2a0
        Code: 02 4c 89 e2 83 e2 07 38 d0 7f 08 84 c0 0f 85 86 00 00 00 48 ba 00 02 00 00 00 00 ad de 0f b6 43 02 49 39 d6 0f 84 5f fe ff ff <0f> 0b e9 58 fe ff ff 48 b8 00 00 00 00 00 fc ff df 4c 89 e2 48 c1
        RSP: 0018:ffff888092f67cd8 EFLAGS: 00010202
        RAX: 0000000000000007 RBX: ffffc90001947000 RCX: ffffffff816e9d88
        RDX: dead000000000200 RSI: 0000000000000008 RDI: ffff88808769f7f0
        RBP: ffff888092f67d00 R08: fffffbfff1394059 R09: fffffbfff1394058
        R10: fffffbfff1394058 R11: ffffffff89ca02c7 R12: ffffc90001947002
        R13: ffffc90001947020 R14: ffffffff881eca80 R15: ffff88808769f7e8
        BUG: unable to handle kernel paging request at fffffbfff400d000
        #PF error: [normal kernel read fault]
        PGD 21ffee067 P4D 21ffee067 PUD 21ffed067 PMD 9f942067 PTE 0
        Oops: 0000 [#1] PREEMPT SMP KASAN
        CPU: 0 PID: 9869 Comm: kworker/0:7 Not tainted 5.0.0-rc8+ #1
        Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
        Workqueue: events bpf_prog_free_deferred
        RIP: 0010:bpf_get_prog_addr_region kernel/bpf/core.c:495 [inline]
        RIP: 0010:bpf_tree_comp kernel/bpf/core.c:558 [inline]
        RIP: 0010:__lt_find include/linux/rbtree_latch.h:115 [inline]
        RIP: 0010:latch_tree_find include/linux/rbtree_latch.h:208 [inline]
        RIP: 0010:bpf_prog_kallsyms_find+0x107/0x2e0 kernel/bpf/core.c:632
        Code: 00 f0 ff ff 44 38 c8 7f 08 84 c0 0f 85 fa 00 00 00 41 f6 45 02 01 75 02 0f 0b 48 39 da 0f 82 92 00 00 00 48 89 d8 48 c1 e8 03 <42> 0f b6 04 30 84 c0 74 08 3c 03 0f 8e 45 01 00 00 8b 03 48 c1 e0
        [...]
      
      Upon further debugging, it turns out that whenever we trigger this
      issue, the kallsyms removal in bpf_prog_ksym_node_del() was /skipped/
      but yet bpf_jit_free() reported that the entry is /in use/.
      
      Problem is that symbol exposure via bpf_prog_kallsyms_add() but also
      perf_event_bpf_event() were done /after/ bpf_prog_new_fd(). Once the
      fd is exposed to the public, a parallel close request came in right
      before we attempted to do the bpf_prog_kallsyms_add().
      
      Given at this time the prog reference count is one, we start to rip
      everything underneath us via bpf_prog_release() -> bpf_prog_put().
      The memory is eventually released via deferred free, so we're seeing
      that bpf_jit_free() has a kallsym entry because we added it from
      bpf_prog_load() but /after/ bpf_prog_put() from the remote CPU.
      
      Therefore, move both notifications /before/ we install the fd. The
      issue was never seen between bpf_prog_alloc_id() and bpf_prog_new_fd()
      because upon bpf_prog_get_fd_by_id() we'll take another reference to
      the BPF prog, so we're still holding the original reference from the
      bpf_prog_load().
      
      Fixes: 6ee52e2a ("perf, bpf: Introduce PERF_RECORD_BPF_EVENT")
      Fixes: 74451e66 ("bpf: make jited programs visible in traces")
      Reported-by: syzbot+bd3bba6ff3fcea7a6ec6@syzkaller.appspotmail.com
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Cc: Song Liu <songliubraving@fb.com>
      c751798a
    • Alexei Starovoitov's avatar
      bpf: fix precision tracking in presence of bpf2bpf calls · 6754172c
      Alexei Starovoitov authored
      While adding extra tests for precision tracking and extra infra
      to adjust verifier heuristics the existing test
      "calls: cross frame pruning - liveness propagation" started to fail.
      The root cause is the same as described in verifer.c comment:
      
       * Also if parent's curframe > frame where backtracking started,
       * the verifier need to mark registers in both frames, otherwise callees
       * may incorrectly prune callers. This is similar to
       * commit 7640ead9 ("bpf: verifier: make sure callees don't prune with caller differences")
       * For now backtracking falls back into conservative marking.
      
      Turned out though that returning -ENOTSUPP from backtrack_insn() and
      doing mark_all_scalars_precise() in the current parentage chain is not enough.
      Depending on how is_state_visited() heuristic is creating parentage chain
      it's possible that callee will incorrectly prune caller.
      Fix the issue by setting precise=true earlier and more aggressively.
      Before this fix the precision tracking _within_ functions that don't do
      bpf2bpf calls would still work. Whereas now precision tracking is completely
      disabled when bpf2bpf calls are present anywhere in the program.
      
      No difference in cilium tests (they don't have bpf2bpf calls).
      No difference in test_progs though some of them have bpf2bpf calls,
      but precision tracking wasn't effective there.
      
      Fixes: b5dc0163 ("bpf: precise scalar_value tracking")
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      6754172c
    • Jakub Sitnicki's avatar
      flow_dissector: Fix potential use-after-free on BPF_PROG_DETACH · db38de39
      Jakub Sitnicki authored
      Call to bpf_prog_put(), with help of call_rcu(), queues an RCU-callback to
      free the program once a grace period has elapsed. The callback can run
      together with new RCU readers that started after the last grace period.
      New RCU readers can potentially see the "old" to-be-freed or already-freed
      pointer to the program object before the RCU update-side NULLs it.
      
      Reorder the operations so that the RCU update-side resets the protected
      pointer before the end of the grace period after which the program will be
      freed.
      
      Fixes: d58e468b ("flow_dissector: implements flow dissector BPF hook")
      Reported-by: default avatarLorenz Bauer <lmb@cloudflare.com>
      Signed-off-by: default avatarJakub Sitnicki <jakub@cloudflare.com>
      Acked-by: default avatarPetar Penkov <ppenkov@google.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      db38de39
    • Heiner Kallweit's avatar
      Revert "r8169: remove not needed call to dma_sync_single_for_device" · 345b9326
      Heiner Kallweit authored
      This reverts commit f072218c.
      
      As reported by Aaro this patch causes network problems on
      MIPS Loongson platform. Therefore revert it.
      
      Fixes: f072218c ("r8169: remove not needed call to dma_sync_single_for_device")
      Signed-off-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Reported-by: default avatarAaro Koskinen <aaro.koskinen@iki.fi>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      345b9326
    • Sabrina Dubroca's avatar
      ipv6: propagate ipv6_add_dev's error returns out of ipv6_find_idev · db0b99f5
      Sabrina Dubroca authored
      Currently, ipv6_find_idev returns NULL when ipv6_add_dev fails,
      ignoring the specific error value. This results in addrconf_add_dev
      returning ENOBUFS in all cases, which is unfortunate in cases such as:
      
          # ip link add dummyX type dummy
          # ip link set dummyX mtu 1200 up
          # ip addr add 2000::/64 dev dummyX
          RTNETLINK answers: No buffer space available
      
      Commit a317a2f1 ("ipv6: fail early when creating netdev named all
      or default") introduced error returns in ipv6_add_dev. Before that,
      that function would simply return NULL for all failures.
      Signed-off-by: default avatarSabrina Dubroca <sd@queasysnail.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      db0b99f5
    • Justin.Lee1@Dell.com's avatar
      net/ncsi: Fix the payload copying for the request coming from Netlink · f6edbf2d
      Justin.Lee1@Dell.com authored
      The request coming from Netlink should use the OEM generic handler.
      
      The standard command handler expects payload in bytes/words/dwords
      but the actual payload is stored in data if the request is coming from Netlink.
      Signed-off-by: default avatarJustin Lee <justin.lee1@dell.com>
      Reviewed-by: default avatarVijay Khemka <vijaykhemka@fb.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f6edbf2d
  3. 22 Aug, 2019 7 commits
  4. 21 Aug, 2019 11 commits
  5. 20 Aug, 2019 14 commits