1. 04 11月, 2022 1 次提交
    • B
      bpf, test_run: Fix alignment problem in bpf_prog_test_run_skb() · d3fd203f
      Baisong Zhong 提交于
      We got a syzkaller problem because of aarch64 alignment fault
      if KFENCE enabled. When the size from user bpf program is an odd
      number, like 399, 407, etc, it will cause the struct skb_shared_info's
      unaligned access. As seen below:
      
        BUG: KFENCE: use-after-free read in __skb_clone+0x23c/0x2a0 net/core/skbuff.c:1032
      
        Use-after-free read at 0xffff6254fffac077 (in kfence-#213):
         __lse_atomic_add arch/arm64/include/asm/atomic_lse.h:26 [inline]
         arch_atomic_add arch/arm64/include/asm/atomic.h:28 [inline]
         arch_atomic_inc include/linux/atomic-arch-fallback.h:270 [inline]
         atomic_inc include/asm-generic/atomic-instrumented.h:241 [inline]
         __skb_clone+0x23c/0x2a0 net/core/skbuff.c:1032
         skb_clone+0xf4/0x214 net/core/skbuff.c:1481
         ____bpf_clone_redirect net/core/filter.c:2433 [inline]
         bpf_clone_redirect+0x78/0x1c0 net/core/filter.c:2420
         bpf_prog_d3839dd9068ceb51+0x80/0x330
         bpf_dispatcher_nop_func include/linux/bpf.h:728 [inline]
         bpf_test_run+0x3c0/0x6c0 net/bpf/test_run.c:53
         bpf_prog_test_run_skb+0x638/0xa7c net/bpf/test_run.c:594
         bpf_prog_test_run kernel/bpf/syscall.c:3148 [inline]
         __do_sys_bpf kernel/bpf/syscall.c:4441 [inline]
         __se_sys_bpf+0xad0/0x1634 kernel/bpf/syscall.c:4381
      
        kfence-#213: 0xffff6254fffac000-0xffff6254fffac196, size=407, cache=kmalloc-512
      
        allocated by task 15074 on cpu 0 at 1342.585390s:
         kmalloc include/linux/slab.h:568 [inline]
         kzalloc include/linux/slab.h:675 [inline]
         bpf_test_init.isra.0+0xac/0x290 net/bpf/test_run.c:191
         bpf_prog_test_run_skb+0x11c/0xa7c net/bpf/test_run.c:512
         bpf_prog_test_run kernel/bpf/syscall.c:3148 [inline]
         __do_sys_bpf kernel/bpf/syscall.c:4441 [inline]
         __se_sys_bpf+0xad0/0x1634 kernel/bpf/syscall.c:4381
         __arm64_sys_bpf+0x50/0x60 kernel/bpf/syscall.c:4381
      
      To fix the problem, we adjust @size so that (@size + @hearoom) is a
      multiple of SMP_CACHE_BYTES. So we make sure the struct skb_shared_info
      is aligned to a cache line.
      
      Fixes: 1cf1cae9 ("bpf: introduce BPF_PROG_TEST_RUN command")
      Signed-off-by: NBaisong Zhong <zhongbaisong@huawei.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Cc: Eric Dumazet <edumazet@google.com>
      Link: https://lore.kernel.org/bpf/20221102081620.1465154-1-zhongbaisong@huawei.com
      d3fd203f
  2. 08 9月, 2022 2 次提交
  3. 24 8月, 2022 2 次提交
  4. 11 8月, 2022 1 次提交
  5. 10 8月, 2022 1 次提交
  6. 22 7月, 2022 2 次提交
  7. 20 7月, 2022 1 次提交
  8. 04 6月, 2022 1 次提交
  9. 16 5月, 2022 1 次提交
    • A
      net: allow gso_max_size to exceed 65536 · 7c4e983c
      Alexander Duyck 提交于
      The code for gso_max_size was added originally to allow for debugging and
      workaround of buggy devices that couldn't support TSO with blocks 64K in
      size. The original reason for limiting it to 64K was because that was the
      existing limits of IPv4 and non-jumbogram IPv6 length fields.
      
      With the addition of Big TCP we can remove this limit and allow the value
      to potentially go up to UINT_MAX and instead be limited by the tso_max_size
      value.
      
      So in order to support this we need to go through and clean up the
      remaining users of the gso_max_size value so that the values will cap at
      64K for non-TCPv6 flows. In addition we can clean up the GSO_MAX_SIZE value
      so that 64K becomes GSO_LEGACY_MAX_SIZE and UINT_MAX will now be the upper
      limit for GSO_MAX_SIZE.
      
      v6: (edumazet) fixed a compile error if CONFIG_IPV6=n,
                     in a new sk_trim_gso_size() helper.
                     netif_set_tso_max_size() caps the requested TSO size
                     with GSO_MAX_SIZE.
      Signed-off-by: NAlexander Duyck <alexanderduyck@fb.com>
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7c4e983c
  10. 12 5月, 2022 1 次提交
  11. 26 4月, 2022 2 次提交
  12. 11 4月, 2022 1 次提交
  13. 12 3月, 2022 1 次提交
    • T
      bpf, test_run: Fix packet size check for live packet mode · b6f1f780
      Toke Høiland-Jørgensen 提交于
      The live packet mode uses some extra space at the start of each page to
      cache data structures so they don't have to be rebuilt at every repetition.
      This space wasn't correctly accounted for in the size checking of the
      arguments supplied to userspace. In addition, the definition of the frame
      size should include the size of the skb_shared_info (as there is other
      logic that subtracts the size of this).
      
      Together, these mistakes resulted in userspace being able to trip the
      XDP_WARN() in xdp_update_frame_from_buff(), which syzbot discovered in
      short order. Fix this by changing the frame size define and adding the
      extra headroom to the bpf_prog_test_run_xdp() function. Also drop the
      max_len parameter to the page_pool init, since this is related to DMA which
      is not used for the page pool instance in PROG_TEST_RUN.
      
      Fixes: b530e9e1 ("bpf: Add "live packet" mode for XDP in BPF_PROG_RUN")
      Reported-by: syzbot+0e91362d99386dc5de99@syzkaller.appspotmail.com
      Signed-off-by: NToke Høiland-Jørgensen <toke@redhat.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: NMartin KaFai Lau <kafai@fb.com>
      Link: https://lore.kernel.org/bpf/20220310225621.53374-1-toke@redhat.com
      b6f1f780
  14. 10 3月, 2022 3 次提交
    • Y
      bpf, test_run: Use kvfree() for memory allocated with kvmalloc() · 743bec1b
      Yihao Han 提交于
      It is allocated with kvmalloc(), the corresponding release function
      should not be kfree(), use kvfree() instead.
      
      Generated by: scripts/coccinelle/api/kfree_mismatch.cocci
      
      Fixes: b530e9e1 ("bpf: Add "live packet" mode for XDP in BPF_PROG_RUN")
      Signed-off-by: NYihao Han <hanyihao@vivo.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Cc: Toke Høiland-Jørgensen <toke@redhat.com>
      Link: https://lore.kernel.org/bpf/20220310092828.13405-1-hanyihao@vivo.com
      743bec1b
    • T
      bpf: Initialise retval in bpf_prog_test_run_xdp() · eecbfd97
      Toke Høiland-Jørgensen 提交于
      The kernel test robot pointed out that the newly added
      bpf_test_run_xdp_live() runner doesn't set the retval in the caller (by
      design), which means that the variable can be passed unitialised to
      bpf_test_finish(). Fix this by initialising the variable properly.
      
      Fixes: b530e9e1 ("bpf: Add "live packet" mode for XDP in BPF_PROG_RUN")
      Reported-by: Nkernel test robot <lkp@intel.com>
      Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NToke Høiland-Jørgensen <toke@redhat.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Link: https://lore.kernel.org/bpf/20220310110228.161869-1-toke@redhat.com
      eecbfd97
    • T
      bpf: Add "live packet" mode for XDP in BPF_PROG_RUN · b530e9e1
      Toke Høiland-Jørgensen 提交于
      This adds support for running XDP programs through BPF_PROG_RUN in a mode
      that enables live packet processing of the resulting frames. Previous uses
      of BPF_PROG_RUN for XDP returned the XDP program return code and the
      modified packet data to userspace, which is useful for unit testing of XDP
      programs.
      
      The existing BPF_PROG_RUN for XDP allows userspace to set the ingress
      ifindex and RXQ number as part of the context object being passed to the
      kernel. This patch reuses that code, but adds a new mode with different
      semantics, which can be selected with the new BPF_F_TEST_XDP_LIVE_FRAMES
      flag.
      
      When running BPF_PROG_RUN in this mode, the XDP program return codes will
      be honoured: returning XDP_PASS will result in the frame being injected
      into the networking stack as if it came from the selected networking
      interface, while returning XDP_TX and XDP_REDIRECT will result in the frame
      being transmitted out that interface. XDP_TX is translated into an
      XDP_REDIRECT operation to the same interface, since the real XDP_TX action
      is only possible from within the network drivers themselves, not from the
      process context where BPF_PROG_RUN is executed.
      
      Internally, this new mode of operation creates a page pool instance while
      setting up the test run, and feeds pages from that into the XDP program.
      The setup cost of this is amortised over the number of repetitions
      specified by userspace.
      
      To support the performance testing use case, we further optimise the setup
      step so that all pages in the pool are pre-initialised with the packet
      data, and pre-computed context and xdp_frame objects stored at the start of
      each page. This makes it possible to entirely avoid touching the page
      content on each XDP program invocation, and enables sending up to 9
      Mpps/core on my test box.
      
      Because the data pages are recycled by the page pool, and the test runner
      doesn't re-initialise them for each run, subsequent invocations of the XDP
      program will see the packet data in the state it was after the last time it
      ran on that particular page. This means that an XDP program that modifies
      the packet before redirecting it has to be careful about which assumptions
      it makes about the packet content, but that is only an issue for the most
      naively written programs.
      
      Enabling the new flag is only allowed when not setting ctx_out and data_out
      in the test specification, since using it means frames will be redirected
      somewhere else, so they can't be returned.
      Signed-off-by: NToke Høiland-Jørgensen <toke@redhat.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Acked-by: NMartin KaFai Lau <kafai@fb.com>
      Link: https://lore.kernel.org/bpf/20220309105346.100053-2-toke@redhat.com
      b530e9e1
  15. 06 3月, 2022 2 次提交
  16. 02 3月, 2022 1 次提交
  17. 10 2月, 2022 1 次提交
  18. 08 2月, 2022 2 次提交
    • S
      bpf: test_run: Fix overflow in bpf_test_finish frags parsing · 5d1e9f43
      Stanislav Fomichev 提交于
      This place also uses signed min_t and passes this singed int to
      copy_to_user (which accepts unsigned argument). I don't think
      there is an issue, but let's be consistent.
      
      Fixes: 7855e0db ("bpf: test_run: add xdp_shared_info pointer in bpf_test_finish signature")
      Signed-off-by: NStanislav Fomichev <sdf@google.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Acked-by: NYonghong Song <yhs@fb.com>
      Link: https://lore.kernel.org/bpf/20220204235849.14658-2-sdf@google.com
      5d1e9f43
    • S
      bpf: test_run: Fix overflow in xdp frags parsing · 9d63b59d
      Stanislav Fomichev 提交于
      When kattr->test.data_size_in > INT_MAX, signed min_t will assign
      negative value to data_len. This negative value then gets passed
      over to copy_from_user where it is converted to (big) unsigned.
      
      Use unsigned min_t to avoid this overflow.
      
      usercopy: Kernel memory overwrite attempt detected to wrapped address
      (offset 0, size 18446612140539162846)!
      ------------[ cut here ]------------
      kernel BUG at mm/usercopy.c:102!
      invalid opcode: 0000 [#1] SMP KASAN
      Modules linked in:
      CPU: 0 PID: 3781 Comm: syz-executor226 Not tainted 4.15.0-syzkaller #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
      Google 01/01/2011
      RIP: 0010:usercopy_abort+0xbd/0xbf mm/usercopy.c:102
      RSP: 0018:ffff8801e9703a38 EFLAGS: 00010286
      RAX: 000000000000006c RBX: ffffffff84fc7040 RCX: 0000000000000000
      RDX: 0000000000000000 RSI: ffffffff816560a2 RDI: ffffed003d2e0739
      RBP: ffff8801e9703a90 R08: 000000000000006c R09: 0000000000000001
      R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff84fc73a0
      R13: ffffffff84fc7180 R14: ffffffff84fc7040 R15: ffffffff84fc7040
      FS:  00007f54e0bec300(0000) GS:ffff8801f6600000(0000)
      knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000020000280 CR3: 00000001e90ea000 CR4: 00000000003426f0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       check_bogus_address mm/usercopy.c:155 [inline]
       __check_object_size mm/usercopy.c:263 [inline]
       __check_object_size.cold+0x8c/0xad mm/usercopy.c:253
       check_object_size include/linux/thread_info.h:112 [inline]
       check_copy_size include/linux/thread_info.h:143 [inline]
       copy_from_user include/linux/uaccess.h:142 [inline]
       bpf_prog_test_run_xdp+0xe57/0x1240 net/bpf/test_run.c:989
       bpf_prog_test_run kernel/bpf/syscall.c:3377 [inline]
       __sys_bpf+0xdf2/0x4a50 kernel/bpf/syscall.c:4679
       SYSC_bpf kernel/bpf/syscall.c:4765 [inline]
       SyS_bpf+0x26/0x50 kernel/bpf/syscall.c:4763
       do_syscall_64+0x21a/0x3e0 arch/x86/entry/common.c:305
       entry_SYSCALL_64_after_hwframe+0x46/0xbb
      
      Fixes: 1c194998 ("bpf: introduce frags support to bpf_prog_test_run_xdp()")
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: NStanislav Fomichev <sdf@google.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Acked-by: NLorenzo Bianconi <lorenzo@kernel.org>
      Acked-by: NYonghong Song <yhs@fb.com>
      Link: https://lore.kernel.org/bpf/20220204235849.14658-1-sdf@google.com
      9d63b59d
  19. 04 2月, 2022 1 次提交
    • L
      bpf: test_run: Fix OOB access in bpf_prog_test_run_xdp · a6763080
      Lorenzo Bianconi 提交于
      Fix the following kasan issue reported by syzbot:
      
      BUG: KASAN: slab-out-of-bounds in __skb_frag_set_page include/linux/skbuff.h:3242 [inline]
      BUG: KASAN: slab-out-of-bounds in bpf_prog_test_run_xdp+0x10ac/0x1150 net/bpf/test_run.c:972
      Write of size 8 at addr ffff888048c75000 by task syz-executor.5/23405
      
      CPU: 1 PID: 23405 Comm: syz-executor.5 Not tainted 5.16.0-syzkaller #0
      Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       <TASK>
       __dump_stack lib/dump_stack.c:88 [inline]
       dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
       print_address_description.constprop.0.cold+0x8d/0x336 mm/kasan/report.c:255
       __kasan_report mm/kasan/report.c:442 [inline]
       kasan_report.cold+0x83/0xdf mm/kasan/report.c:459
       __skb_frag_set_page include/linux/skbuff.h:3242 [inline]
       bpf_prog_test_run_xdp+0x10ac/0x1150 net/bpf/test_run.c:972
       bpf_prog_test_run kernel/bpf/syscall.c:3356 [inline]
       __sys_bpf+0x1858/0x59a0 kernel/bpf/syscall.c:4658
       __do_sys_bpf kernel/bpf/syscall.c:4744 [inline]
       __se_sys_bpf kernel/bpf/syscall.c:4742 [inline]
       __x64_sys_bpf+0x75/0xb0 kernel/bpf/syscall.c:4742
       do_syscall_x64 arch/x86/entry/common.c:50 [inline]
       do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
       entry_SYSCALL_64_after_hwframe+0x44/0xae
      RIP: 0033:0x7f4ea30dd059
      RSP: 002b:00007f4ea1a52168 EFLAGS: 00000246 ORIG_RAX: 0000000000000141
      RAX: ffffffffffffffda RBX: 00007f4ea31eff60 RCX: 00007f4ea30dd059
      RDX: 0000000000000048 RSI: 0000000020000000 RDI: 000000000000000a
      RBP: 00007f4ea313708d R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
      R13: 00007ffc8367c5af R14: 00007f4ea1a52300 R15: 0000000000022000
       </TASK>
      
      Allocated by task 23405:
       kasan_save_stack+0x1e/0x50 mm/kasan/common.c:38
       kasan_set_track mm/kasan/common.c:46 [inline]
       set_alloc_info mm/kasan/common.c:437 [inline]
       ____kasan_kmalloc mm/kasan/common.c:516 [inline]
       ____kasan_kmalloc mm/kasan/common.c:475 [inline]
       __kasan_kmalloc+0xa9/0xd0 mm/kasan/common.c:525
       kmalloc include/linux/slab.h:586 [inline]
       kzalloc include/linux/slab.h:715 [inline]
       bpf_test_init.isra.0+0x9f/0x150 net/bpf/test_run.c:411
       bpf_prog_test_run_xdp+0x2f8/0x1150 net/bpf/test_run.c:941
       bpf_prog_test_run kernel/bpf/syscall.c:3356 [inline]
       __sys_bpf+0x1858/0x59a0 kernel/bpf/syscall.c:4658
       __do_sys_bpf kernel/bpf/syscall.c:4744 [inline]
       __se_sys_bpf kernel/bpf/syscall.c:4742 [inline]
       __x64_sys_bpf+0x75/0xb0 kernel/bpf/syscall.c:4742
       do_syscall_x64 arch/x86/entry/common.c:50 [inline]
       do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
       entry_SYSCALL_64_after_hwframe+0x44/0xae
      
      The buggy address belongs to the object at ffff888048c74000
       which belongs to the cache kmalloc-4k of size 4096
      The buggy address is located 0 bytes to the right of
       4096-byte region [ffff888048c74000, ffff888048c75000)
      The buggy address belongs to the page:
      page:ffffea0001231c00 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x48c70
      head:ffffea0001231c00 order:3 compound_mapcount:0 compound_pincount:0
      flags: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff)
      raw: 00fff00000010200 dead000000000100 dead000000000122 ffff888010c42140
      raw: 0000000000000000 0000000080040004 00000001ffffffff 0000000000000000
      page dumped because: kasan: bad access detected
      page_owner tracks the page as allocated
       prep_new_page mm/page_alloc.c:2434 [inline]
       get_page_from_freelist+0xa72/0x2f50 mm/page_alloc.c:4165
       __alloc_pages+0x1b2/0x500 mm/page_alloc.c:5389
       alloc_pages+0x1aa/0x310 mm/mempolicy.c:2271
       alloc_slab_page mm/slub.c:1799 [inline]
       allocate_slab mm/slub.c:1944 [inline]
       new_slab+0x28a/0x3b0 mm/slub.c:2004
       ___slab_alloc+0x87c/0xe90 mm/slub.c:3018
       __slab_alloc.constprop.0+0x4d/0xa0 mm/slub.c:3105
       slab_alloc_node mm/slub.c:3196 [inline]
       __kmalloc_node_track_caller+0x2cb/0x360 mm/slub.c:4957
       kmalloc_reserve net/core/skbuff.c:354 [inline]
       __alloc_skb+0xde/0x340 net/core/skbuff.c:426
       alloc_skb include/linux/skbuff.h:1159 [inline]
       nsim_dev_trap_skb_build drivers/net/netdevsim/dev.c:745 [inline]
       nsim_dev_trap_report drivers/net/netdevsim/dev.c:802 [inline]
       nsim_dev_trap_report_work+0x29a/0xbc0 drivers/net/netdevsim/dev.c:843
       process_one_work+0x9ac/0x1650 kernel/workqueue.c:2307
       worker_thread+0x657/0x1110 kernel/workqueue.c:2454
       kthread+0x2e9/0x3a0 kernel/kthread.c:377
       ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295
      page last free stack trace:
       reset_page_owner include/linux/page_owner.h:24 [inline]
       free_pages_prepare mm/page_alloc.c:1352 [inline]
       free_pcp_prepare+0x374/0x870 mm/page_alloc.c:1404
       free_unref_page_prepare mm/page_alloc.c:3325 [inline]
       free_unref_page+0x19/0x690 mm/page_alloc.c:3404
       qlink_free mm/kasan/quarantine.c:157 [inline]
       qlist_free_all+0x6d/0x160 mm/kasan/quarantine.c:176
       kasan_quarantine_reduce+0x180/0x200 mm/kasan/quarantine.c:283
       __kasan_slab_alloc+0xa2/0xc0 mm/kasan/common.c:447
       kasan_slab_alloc include/linux/kasan.h:260 [inline]
       slab_post_alloc_hook mm/slab.h:732 [inline]
       slab_alloc_node mm/slub.c:3230 [inline]
       slab_alloc mm/slub.c:3238 [inline]
       kmem_cache_alloc+0x202/0x3a0 mm/slub.c:3243
       getname_flags.part.0+0x50/0x4f0 fs/namei.c:138
       getname_flags include/linux/audit.h:323 [inline]
       getname+0x8e/0xd0 fs/namei.c:217
       do_sys_openat2+0xf5/0x4d0 fs/open.c:1208
       do_sys_open fs/open.c:1230 [inline]
       __do_sys_openat fs/open.c:1246 [inline]
       __se_sys_openat fs/open.c:1241 [inline]
       __x64_sys_openat+0x13f/0x1f0 fs/open.c:1241
       do_syscall_x64 arch/x86/entry/common.c:50 [inline]
       do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
       entry_SYSCALL_64_after_hwframe+0x44/0xae
      
      Memory state around the buggy address:
       ffff888048c74f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
       ffff888048c74f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
                         ^
       ffff888048c75080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
       ffff888048c75100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      ==================================================================
      
      Fixes: 1c194998 ("bpf: introduce frags support to bpf_prog_test_run_xdp()")
      Reported-by: syzbot+6d70ca7438345077c549@syzkaller.appspotmail.com
      Signed-off-by: NLorenzo Bianconi <lorenzo@kernel.org>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Link: https://lore.kernel.org/bpf/688c26f9dd6e885e58e8e834ede3f0139bb7fa95.1643835097.git.lorenzo@kernel.org
      a6763080
  20. 25 1月, 2022 1 次提交
  21. 22 1月, 2022 3 次提交
  22. 19 1月, 2022 3 次提交
    • K
      selftests/bpf: Add test for race in btf_try_get_module · 46565696
      Kumar Kartikeya Dwivedi 提交于
      This adds a complete test case to ensure we never take references to
      modules not in MODULE_STATE_LIVE, which can lead to UAF, and it also
      ensures we never access btf->kfunc_set_tab in an inconsistent state.
      
      The test uses userfaultfd to artificially widen the race.
      
      When run on an unpatched kernel, it leads to the following splat:
      
      [root@(none) bpf]# ./test_progs -t bpf_mod_race/ksym
      [   55.498171] BUG: unable to handle page fault for address: fffffbfff802548b
      [   55.499206] #PF: supervisor read access in kernel mode
      [   55.499855] #PF: error_code(0x0000) - not-present page
      [   55.500555] PGD a4fa9067 P4D a4fa9067 PUD a4fa5067 PMD 1b44067 PTE 0
      [   55.501499] Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI
      [   55.502195] CPU: 0 PID: 83 Comm: kworker/0:2 Tainted: G           OE     5.16.0-rc4+ #151
      [   55.503388] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ArchLinux 1.15.0-1 04/01/2014
      [   55.504777] Workqueue: events bpf_prog_free_deferred
      [   55.505563] RIP: 0010:kasan_check_range+0x184/0x1d0
      [   55.509140] RSP: 0018:ffff88800560fcf0 EFLAGS: 00010282
      [   55.509977] RAX: fffffbfff802548b RBX: fffffbfff802548c RCX: ffffffff9337b6ba
      [   55.511096] RDX: fffffbfff802548c RSI: 0000000000000004 RDI: ffffffffc012a458
      [   55.512143] RBP: fffffbfff802548b R08: 0000000000000001 R09: ffffffffc012a45b
      [   55.513228] R10: fffffbfff802548b R11: 0000000000000001 R12: ffff888001b5f598
      [   55.514332] R13: ffff888004f49ac8 R14: 0000000000000000 R15: ffff888092449400
      [   55.515418] FS:  0000000000000000(0000) GS:ffff888092400000(0000) knlGS:0000000000000000
      [   55.516705] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   55.517560] CR2: fffffbfff802548b CR3: 0000000007c10006 CR4: 0000000000770ef0
      [   55.518672] PKRU: 55555554
      [   55.519022] Call Trace:
      [   55.519483]  <TASK>
      [   55.519884]  module_put.part.0+0x2a/0x180
      [   55.520642]  bpf_prog_free_deferred+0x129/0x2e0
      [   55.521478]  process_one_work+0x4fa/0x9e0
      [   55.522122]  ? pwq_dec_nr_in_flight+0x100/0x100
      [   55.522878]  ? rwlock_bug.part.0+0x60/0x60
      [   55.523551]  worker_thread+0x2eb/0x700
      [   55.524176]  ? __kthread_parkme+0xd8/0xf0
      [   55.524853]  ? process_one_work+0x9e0/0x9e0
      [   55.525544]  kthread+0x23a/0x270
      [   55.526088]  ? set_kthread_struct+0x80/0x80
      [   55.526798]  ret_from_fork+0x1f/0x30
      [   55.527413]  </TASK>
      [   55.527813] Modules linked in: bpf_testmod(OE) [last unloaded: bpf_testmod]
      [   55.530846] CR2: fffffbfff802548b
      [   55.531341] ---[ end trace 1af41803c054ad6d ]---
      [   55.532136] RIP: 0010:kasan_check_range+0x184/0x1d0
      [   55.535887] RSP: 0018:ffff88800560fcf0 EFLAGS: 00010282
      [   55.536711] RAX: fffffbfff802548b RBX: fffffbfff802548c RCX: ffffffff9337b6ba
      [   55.537821] RDX: fffffbfff802548c RSI: 0000000000000004 RDI: ffffffffc012a458
      [   55.538899] RBP: fffffbfff802548b R08: 0000000000000001 R09: ffffffffc012a45b
      [   55.539928] R10: fffffbfff802548b R11: 0000000000000001 R12: ffff888001b5f598
      [   55.541021] R13: ffff888004f49ac8 R14: 0000000000000000 R15: ffff888092449400
      [   55.542108] FS:  0000000000000000(0000) GS:ffff888092400000(0000) knlGS:0000000000000000
      [   55.543260]CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   55.544136] CR2: fffffbfff802548b CR3: 0000000007c10006 CR4: 0000000000770ef0
      [   55.545317] PKRU: 55555554
      [   55.545671] note: kworker/0:2[83] exited with preempt_count 1
      Signed-off-by: NKumar Kartikeya Dwivedi <memxor@gmail.com>
      Link: https://lore.kernel.org/r/20220114163953.1455836-11-memxor@gmail.comSigned-off-by: NAlexei Starovoitov <ast@kernel.org>
      46565696
    • K
      selftests/bpf: Extend kfunc selftests · c1ff181f
      Kumar Kartikeya Dwivedi 提交于
      Use the prog_test kfuncs to test the referenced PTR_TO_BTF_ID kfunc
      support, and PTR_TO_CTX, PTR_TO_MEM argument passing support. Also
      testing the various failure cases for invalid kfunc prototypes.
      Signed-off-by: NKumar Kartikeya Dwivedi <memxor@gmail.com>
      Link: https://lore.kernel.org/r/20220114163953.1455836-10-memxor@gmail.comSigned-off-by: NAlexei Starovoitov <ast@kernel.org>
      c1ff181f
    • K
      bpf: Remove check_kfunc_call callback and old kfunc BTF ID API · b202d844
      Kumar Kartikeya Dwivedi 提交于
      Completely remove the old code for check_kfunc_call to help it work
      with modules, and also the callback itself.
      
      The previous commit adds infrastructure to register all sets and put
      them in vmlinux or module BTF, and concatenates all related sets
      organized by the hook and the type. Once populated, these sets remain
      immutable for the lifetime of the struct btf.
      
      Also, since we don't need the 'owner' module anywhere when doing
      check_kfunc_call, drop the 'btf_modp' module parameter from
      find_kfunc_desc_btf.
      Signed-off-by: NKumar Kartikeya Dwivedi <memxor@gmail.com>
      Link: https://lore.kernel.org/r/20220114163953.1455836-4-memxor@gmail.comSigned-off-by: NAlexei Starovoitov <ast@kernel.org>
      b202d844
  23. 21 10月, 2021 1 次提交
  24. 06 10月, 2021 2 次提交
    • K
      bpf: selftests: Add selftests for module kfunc support · c48e51c8
      Kumar Kartikeya Dwivedi 提交于
      This adds selftests that tests the success and failure path for modules
      kfuncs (in presence of invalid kfunc calls) for both libbpf and
      gen_loader. It also adds a prog_test kfunc_btf_id_list so that we can
      add module BTF ID set from bpf_testmod.
      
      This also introduces  a couple of test cases to verifier selftests for
      validating whether we get an error or not depending on if invalid kfunc
      call remains after elimination of unreachable instructions.
      Signed-off-by: NKumar Kartikeya Dwivedi <memxor@gmail.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Link: https://lore.kernel.org/bpf/20211002011757.311265-10-memxor@gmail.com
      c48e51c8
    • K
      bpf: Introduce BPF support for kernel module function calls · 2357672c
      Kumar Kartikeya Dwivedi 提交于
      This change adds support on the kernel side to allow for BPF programs to
      call kernel module functions. Userspace will prepare an array of module
      BTF fds that is passed in during BPF_PROG_LOAD using fd_array parameter.
      In the kernel, the module BTFs are placed in the auxilliary struct for
      bpf_prog, and loaded as needed.
      
      The verifier then uses insn->off to index into the fd_array. insn->off
      0 is reserved for vmlinux BTF (for backwards compat), so userspace must
      use an fd_array index > 0 for module kfunc support. kfunc_btf_tab is
      sorted based on offset in an array, and each offset corresponds to one
      descriptor, with a max limit up to 256 such module BTFs.
      
      We also change existing kfunc_tab to distinguish each element based on
      imm, off pair as each such call will now be distinct.
      
      Another change is to check_kfunc_call callback, which now include a
      struct module * pointer, this is to be used in later patch such that the
      kfunc_id and module pointer are matched for dynamically registered BTF
      sets from loadable modules, so that same kfunc_id in two modules doesn't
      lead to check_kfunc_call succeeding. For the duration of the
      check_kfunc_call, the reference to struct module exists, as it returns
      the pointer stored in kfunc_btf_tab.
      Signed-off-by: NKumar Kartikeya Dwivedi <memxor@gmail.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Link: https://lore.kernel.org/bpf/20211002011757.311265-2-memxor@gmail.com
      2357672c
  25. 30 9月, 2021 1 次提交
  26. 28 9月, 2021 1 次提交
    • D
      bpf, test, cgroup: Use sk_{alloc,free} for test cases · 435b08ec
      Daniel Borkmann 提交于
      BPF test infra has some hacks in place which kzalloc() a socket and perform
      minimum init via sock_net_set() and sock_init_data(). As a result, the sk's
      skcd->cgroup is NULL since it didn't go through proper initialization as it
      would have been the case from sk_alloc(). Rather than re-adding a NULL test
      in sock_cgroup_ptr() just for this, use sk_{alloc,free}() pair for the test
      socket. The latter also allows to get rid of the bpf_sk_storage_free() special
      case.
      
      Fixes: 8520e224 ("bpf, cgroups: Fix cgroup v2 fallback on v1/v2 mixed mode")
      Fixes: b7a1848e ("bpf: add BPF_PROG_TEST_RUN support for flow dissector")
      Fixes: 2cb494a3 ("bpf: add tests for direct packet access from CGROUP_SKB")
      Reported-by: syzbot+664b58e9a40fbb2cec71@syzkaller.appspotmail.com
      Reported-by: syzbot+33f36d0754d4c5c0e102@syzkaller.appspotmail.com
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Tested-by: syzbot+664b58e9a40fbb2cec71@syzkaller.appspotmail.com
      Tested-by: syzbot+33f36d0754d4c5c0e102@syzkaller.appspotmail.com
      Link: https://lore.kernel.org/bpf/20210927123921.21535-2-daniel@iogearbox.net
      435b08ec
  27. 11 9月, 2021 1 次提交