Closed
Conversation
Author
|
Master branch: bc0b5a0 patch https://patchwork.ozlabs.org/project/netdev/patch/20200908132201.184005-1-chenzhou10@huawei.com/ applied successfully |
09f078d to
982c1ad
Compare
Author
|
Master branch: e6054fc patch https://patchwork.ozlabs.org/project/netdev/patch/20200908132201.184005-1-chenzhou10@huawei.com/ applied successfully |
982c1ad to
919ede0
Compare
Signed-off-by: Chen Zhou <chenzhou10@huawei.com> --- net/core/bpf_sk_storage.c | 1 - 1 file changed, 1 deletion(-)
Author
|
Master branch: 8081ede patch https://patchwork.ozlabs.org/project/netdev/patch/20200908132201.184005-1-chenzhou10@huawei.com/ applied successfully |
919ede0 to
bd9a8d1
Compare
kernel-patches-bot
pushed a commit
that referenced
this pull request
Sep 10, 2020
fstat syscall code path, so fentry/vfs_getattr trampoline is not called. I'm not sure how to handle this in some generic way other than use some other function, but that might get inlined at some point as well. Adding flags that indicate trampolines were called and failing the test if neither of them got called. $ sudo ./test_progs -t d_path test_d_path:PASS:setup 0 nsec ... trigger_fstat_events:PASS:trigger 0 nsec test_d_path:FAIL:124 trampolines not called #22 d_path:FAIL Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED If only one trampoline is called, it's still enough to test the helper, so only warn about missing trampoline call and continue in test. $ sudo ./test_progs -t d_path -v test_d_path:PASS:setup 0 nsec ... trigger_fstat_events:PASS:trigger 0 nsec fentry/vfs_getattr not called #22 d_path:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Jiri Olsa <jolsa@redhat.com> --- .../testing/selftests/bpf/prog_tests/d_path.c | 25 +++++++++++++++---- .../testing/selftests/bpf/progs/test_d_path.c | 7 ++++++ 2 files changed, 27 insertions(+), 5 deletions(-)
Author
|
At least one diff in series https://patchwork.ozlabs.org/project/netdev/list/?series=200310 irrelevant now. Closing PR. |
kernel-patches-bot
pushed a commit
that referenced
this pull request
Sep 11, 2020
fstat syscall code path, so fentry/vfs_getattr trampoline is not called. I'm not sure how to handle this in some generic way other than use some other function, but that might get inlined at some point as well. Adding flags that indicate trampolines were called and failing the test if neither of them got called. $ sudo ./test_progs -t d_path test_d_path:PASS:setup 0 nsec ... trigger_fstat_events:PASS:trigger 0 nsec test_d_path:FAIL:124 trampolines not called #22 d_path:FAIL Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED If only one trampoline is called, it's still enough to test the helper, so only warn about missing trampoline call and continue in test. $ sudo ./test_progs -t d_path -v test_d_path:PASS:setup 0 nsec ... trigger_fstat_events:PASS:trigger 0 nsec fentry/vfs_getattr not called #22 d_path:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Jiri Olsa <jolsa@redhat.com> --- .../testing/selftests/bpf/prog_tests/d_path.c | 25 +++++++++++++++---- .../testing/selftests/bpf/progs/test_d_path.c | 7 ++++++ 2 files changed, 27 insertions(+), 5 deletions(-)
kernel-patches-bot
pushed a commit
that referenced
this pull request
Nov 20, 2020
This fix is for a failure that occurred in the DWARF unwind perf test.
Stack unwinders may probe memory when looking for frames.
Memory sanitizer will poison and track uninitialized memory on the
stack, and on the heap if the value is copied to the heap.
This can lead to false memory sanitizer failures for the use of an
uninitialized value.
Avoid this problem by removing the poison on the copied stack.
The full msan failure with track origins looks like:
==2168==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x559ceb10755b in handle_cfi elfutils/libdwfl/frame_unwind.c:648:8
#1 0x559ceb105448 in __libdwfl_frame_unwind elfutils/libdwfl/frame_unwind.c:741:4
#2 0x559ceb0ece90 in dwfl_thread_getframes elfutils/libdwfl/dwfl_frame.c:435:7
#3 0x559ceb0ec6b7 in get_one_thread_frames_cb elfutils/libdwfl/dwfl_frame.c:379:10
#4 0x559ceb0ec6b7 in get_one_thread_cb elfutils/libdwfl/dwfl_frame.c:308:17
#5 0x559ceb0ec6b7 in dwfl_getthreads elfutils/libdwfl/dwfl_frame.c:283:17
#6 0x559ceb0ec6b7 in getthread elfutils/libdwfl/dwfl_frame.c:354:14
#7 0x559ceb0ec6b7 in dwfl_getthread_frames elfutils/libdwfl/dwfl_frame.c:388:10
#8 0x559ceaff6ae6 in unwind__get_entries tools/perf/util/unwind-libdw.c:236:8
#9 0x559ceabc9dbc in test_dwarf_unwind__thread tools/perf/tests/dwarf-unwind.c:111:8
#10 0x559ceabca5cf in test_dwarf_unwind__compare tools/perf/tests/dwarf-unwind.c:138:26
#11 0x7f812a6865b0 in bsearch (libc.so.6+0x4e5b0)
#12 0x559ceabca871 in test_dwarf_unwind__krava_3 tools/perf/tests/dwarf-unwind.c:162:2
#13 0x559ceabca926 in test_dwarf_unwind__krava_2 tools/perf/tests/dwarf-unwind.c:169:9
#14 0x559ceabca946 in test_dwarf_unwind__krava_1 tools/perf/tests/dwarf-unwind.c:174:9
#15 0x559ceabcae12 in test__dwarf_unwind tools/perf/tests/dwarf-unwind.c:211:8
#16 0x559ceabbc4ab in run_test tools/perf/tests/builtin-test.c:418:9
#17 0x559ceabbc4ab in test_and_print tools/perf/tests/builtin-test.c:448:9
#18 0x559ceabbac70 in __cmd_test tools/perf/tests/builtin-test.c:669:4
#19 0x559ceabbac70 in cmd_test tools/perf/tests/builtin-test.c:815:9
#20 0x559cea960e30 in run_builtin tools/perf/perf.c:313:11
#21 0x559cea95fbce in handle_internal_command tools/perf/perf.c:365:8
#22 0x559cea95fbce in run_argv tools/perf/perf.c:409:2
#23 0x559cea95fbce in main tools/perf/perf.c:539:3
Uninitialized value was stored to memory at
#0 0x559ceb106acf in __libdwfl_frame_reg_set elfutils/libdwfl/frame_unwind.c:77:22
#1 0x559ceb106acf in handle_cfi elfutils/libdwfl/frame_unwind.c:627:13
#2 0x559ceb105448 in __libdwfl_frame_unwind elfutils/libdwfl/frame_unwind.c:741:4
#3 0x559ceb0ece90 in dwfl_thread_getframes elfutils/libdwfl/dwfl_frame.c:435:7
#4 0x559ceb0ec6b7 in get_one_thread_frames_cb elfutils/libdwfl/dwfl_frame.c:379:10
#5 0x559ceb0ec6b7 in get_one_thread_cb elfutils/libdwfl/dwfl_frame.c:308:17
#6 0x559ceb0ec6b7 in dwfl_getthreads elfutils/libdwfl/dwfl_frame.c:283:17
#7 0x559ceb0ec6b7 in getthread elfutils/libdwfl/dwfl_frame.c:354:14
#8 0x559ceb0ec6b7 in dwfl_getthread_frames elfutils/libdwfl/dwfl_frame.c:388:10
#9 0x559ceaff6ae6 in unwind__get_entries tools/perf/util/unwind-libdw.c:236:8
#10 0x559ceabc9dbc in test_dwarf_unwind__thread tools/perf/tests/dwarf-unwind.c:111:8
#11 0x559ceabca5cf in test_dwarf_unwind__compare tools/perf/tests/dwarf-unwind.c:138:26
#12 0x7f812a6865b0 in bsearch (libc.so.6+0x4e5b0)
#13 0x559ceabca871 in test_dwarf_unwind__krava_3 tools/perf/tests/dwarf-unwind.c:162:2
#14 0x559ceabca926 in test_dwarf_unwind__krava_2 tools/perf/tests/dwarf-unwind.c:169:9
#15 0x559ceabca946 in test_dwarf_unwind__krava_1 tools/perf/tests/dwarf-unwind.c:174:9
#16 0x559ceabcae12 in test__dwarf_unwind tools/perf/tests/dwarf-unwind.c:211:8
#17 0x559ceabbc4ab in run_test tools/perf/tests/builtin-test.c:418:9
#18 0x559ceabbc4ab in test_and_print tools/perf/tests/builtin-test.c:448:9
#19 0x559ceabbac70 in __cmd_test tools/perf/tests/builtin-test.c:669:4
#20 0x559ceabbac70 in cmd_test tools/perf/tests/builtin-test.c:815:9
#21 0x559cea960e30 in run_builtin tools/perf/perf.c:313:11
#22 0x559cea95fbce in handle_internal_command tools/perf/perf.c:365:8
#23 0x559cea95fbce in run_argv tools/perf/perf.c:409:2
#24 0x559cea95fbce in main tools/perf/perf.c:539:3
Uninitialized value was stored to memory at
#0 0x559ceb106a54 in handle_cfi elfutils/libdwfl/frame_unwind.c:613:9
#1 0x559ceb105448 in __libdwfl_frame_unwind elfutils/libdwfl/frame_unwind.c:741:4
#2 0x559ceb0ece90 in dwfl_thread_getframes elfutils/libdwfl/dwfl_frame.c:435:7
#3 0x559ceb0ec6b7 in get_one_thread_frames_cb elfutils/libdwfl/dwfl_frame.c:379:10
#4 0x559ceb0ec6b7 in get_one_thread_cb elfutils/libdwfl/dwfl_frame.c:308:17
#5 0x559ceb0ec6b7 in dwfl_getthreads elfutils/libdwfl/dwfl_frame.c:283:17
#6 0x559ceb0ec6b7 in getthread elfutils/libdwfl/dwfl_frame.c:354:14
#7 0x559ceb0ec6b7 in dwfl_getthread_frames elfutils/libdwfl/dwfl_frame.c:388:10
#8 0x559ceaff6ae6 in unwind__get_entries tools/perf/util/unwind-libdw.c:236:8
#9 0x559ceabc9dbc in test_dwarf_unwind__thread tools/perf/tests/dwarf-unwind.c:111:8
#10 0x559ceabca5cf in test_dwarf_unwind__compare tools/perf/tests/dwarf-unwind.c:138:26
#11 0x7f812a6865b0 in bsearch (libc.so.6+0x4e5b0)
#12 0x559ceabca871 in test_dwarf_unwind__krava_3 tools/perf/tests/dwarf-unwind.c:162:2
#13 0x559ceabca926 in test_dwarf_unwind__krava_2 tools/perf/tests/dwarf-unwind.c:169:9
#14 0x559ceabca946 in test_dwarf_unwind__krava_1 tools/perf/tests/dwarf-unwind.c:174:9
#15 0x559ceabcae12 in test__dwarf_unwind tools/perf/tests/dwarf-unwind.c:211:8
#16 0x559ceabbc4ab in run_test tools/perf/tests/builtin-test.c:418:9
#17 0x559ceabbc4ab in test_and_print tools/perf/tests/builtin-test.c:448:9
#18 0x559ceabbac70 in __cmd_test tools/perf/tests/builtin-test.c:669:4
#19 0x559ceabbac70 in cmd_test tools/perf/tests/builtin-test.c:815:9
#20 0x559cea960e30 in run_builtin tools/perf/perf.c:313:11
#21 0x559cea95fbce in handle_internal_command tools/perf/perf.c:365:8
#22 0x559cea95fbce in run_argv tools/perf/perf.c:409:2
#23 0x559cea95fbce in main tools/perf/perf.c:539:3
Uninitialized value was stored to memory at
#0 0x559ceaff8800 in memory_read tools/perf/util/unwind-libdw.c:156:10
#1 0x559ceb10f053 in expr_eval elfutils/libdwfl/frame_unwind.c:501:13
#2 0x559ceb1060cc in handle_cfi elfutils/libdwfl/frame_unwind.c:603:18
#3 0x559ceb105448 in __libdwfl_frame_unwind elfutils/libdwfl/frame_unwind.c:741:4
#4 0x559ceb0ece90 in dwfl_thread_getframes elfutils/libdwfl/dwfl_frame.c:435:7
#5 0x559ceb0ec6b7 in get_one_thread_frames_cb elfutils/libdwfl/dwfl_frame.c:379:10
#6 0x559ceb0ec6b7 in get_one_thread_cb elfutils/libdwfl/dwfl_frame.c:308:17
#7 0x559ceb0ec6b7 in dwfl_getthreads elfutils/libdwfl/dwfl_frame.c:283:17
#8 0x559ceb0ec6b7 in getthread elfutils/libdwfl/dwfl_frame.c:354:14
#9 0x559ceb0ec6b7 in dwfl_getthread_frames elfutils/libdwfl/dwfl_frame.c:388:10
#10 0x559ceaff6ae6 in unwind__get_entries tools/perf/util/unwind-libdw.c:236:8
#11 0x559ceabc9dbc in test_dwarf_unwind__thread tools/perf/tests/dwarf-unwind.c:111:8
#12 0x559ceabca5cf in test_dwarf_unwind__compare tools/perf/tests/dwarf-unwind.c:138:26
#13 0x7f812a6865b0 in bsearch (libc.so.6+0x4e5b0)
#14 0x559ceabca871 in test_dwarf_unwind__krava_3 tools/perf/tests/dwarf-unwind.c:162:2
#15 0x559ceabca926 in test_dwarf_unwind__krava_2 tools/perf/tests/dwarf-unwind.c:169:9
#16 0x559ceabca946 in test_dwarf_unwind__krava_1 tools/perf/tests/dwarf-unwind.c:174:9
#17 0x559ceabcae12 in test__dwarf_unwind tools/perf/tests/dwarf-unwind.c:211:8
#18 0x559ceabbc4ab in run_test tools/perf/tests/builtin-test.c:418:9
#19 0x559ceabbc4ab in test_and_print tools/perf/tests/builtin-test.c:448:9
#20 0x559ceabbac70 in __cmd_test tools/perf/tests/builtin-test.c:669:4
#21 0x559ceabbac70 in cmd_test tools/perf/tests/builtin-test.c:815:9
#22 0x559cea960e30 in run_builtin tools/perf/perf.c:313:11
#23 0x559cea95fbce in handle_internal_command tools/perf/perf.c:365:8
#24 0x559cea95fbce in run_argv tools/perf/perf.c:409:2
#25 0x559cea95fbce in main tools/perf/perf.c:539:3
Uninitialized value was stored to memory at
#0 0x559cea9027d9 in __msan_memcpy llvm/llvm-project/compiler-rt/lib/msan/msan_interceptors.cpp:1558:3
#1 0x559cea9d2185 in sample_ustack tools/perf/arch/x86/tests/dwarf-unwind.c:41:2
#2 0x559cea9d202c in test__arch_unwind_sample tools/perf/arch/x86/tests/dwarf-unwind.c:72:9
#3 0x559ceabc9cbd in test_dwarf_unwind__thread tools/perf/tests/dwarf-unwind.c:106:6
#4 0x559ceabca5cf in test_dwarf_unwind__compare tools/perf/tests/dwarf-unwind.c:138:26
#5 0x7f812a6865b0 in bsearch (libc.so.6+0x4e5b0)
#6 0x559ceabca871 in test_dwarf_unwind__krava_3 tools/perf/tests/dwarf-unwind.c:162:2
#7 0x559ceabca926 in test_dwarf_unwind__krava_2 tools/perf/tests/dwarf-unwind.c:169:9
#8 0x559ceabca946 in test_dwarf_unwind__krava_1 tools/perf/tests/dwarf-unwind.c:174:9
#9 0x559ceabcae12 in test__dwarf_unwind tools/perf/tests/dwarf-unwind.c:211:8
#10 0x559ceabbc4ab in run_test tools/perf/tests/builtin-test.c:418:9
#11 0x559ceabbc4ab in test_and_print tools/perf/tests/builtin-test.c:448:9
#12 0x559ceabbac70 in __cmd_test tools/perf/tests/builtin-test.c:669:4
#13 0x559ceabbac70 in cmd_test tools/perf/tests/builtin-test.c:815:9
#14 0x559cea960e30 in run_builtin tools/perf/perf.c:313:11
#15 0x559cea95fbce in handle_internal_command tools/perf/perf.c:365:8
#16 0x559cea95fbce in run_argv tools/perf/perf.c:409:2
#17 0x559cea95fbce in main tools/perf/perf.c:539:3
Uninitialized value was created by an allocation of 'bf' in the stack frame of function 'perf_event__synthesize_mmap_events'
#0 0x559ceafc5f60 in perf_event__synthesize_mmap_events tools/perf/util/synthetic-events.c:445
SUMMARY: MemorySanitizer: use-of-uninitialized-value elfutils/libdwfl/frame_unwind.c:648:8 in handle_cfi
Signed-off-by: Ian Rogers <irogers@google.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: clang-built-linux@googlegroups.com
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sandeep Dasgupta <sdasgup@google.com>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lore.kernel.org/lkml/20201113182053.754625-1-irogers@google.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Jan 7, 2021
When running in BE mode on LPAE hardware with a PA-to-VA translation that exceeds 4 GB, we patch bits 39:32 of the offset into the wrong byte of the opcode. So fix that, by rotating the offset in r0 to the right by 8 bits, which will put the 8-bit immediate in bits 31:24. Note that this will also move bit #22 in its correct place when applying the rotation to the constant #0x400000. Fixes: d9a790d ("ARM: 7883/1: fix mov to mvn conversion in case of 64 bit phys_addr_t and BE") Acked-by: Nicolas Pitre <nico@fluxnic.net> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Jul 8, 2021
The problem occurs between dev_get_by_index() and dev_xdp_attach_link(). At this point in time, the xdp link will not be released automatically when dev is deleted. In this way, when xdp link is released, dev will still be accessed, but dev has been released. [ 45.966867] BUG: KASAN: use-after-free in bpf_xdp_link_release+0x3b8/0x3d0 [ 45.967619] Read of size 8 at addr ffff00000f9980c8 by task a.out/732 [ 45.968297] [ 45.968502] CPU: 1 PID: 732 Comm: a.out Not tainted 5.13.0+ #22 [ 45.969222] Hardware name: linux,dummy-virt (DT) [ 45.969795] Call trace: [ 45.970106] dump_backtrace+0x0/0x4c8 [ 45.970564] show_stack+0x30/0x40 [ 45.970981] dump_stack_lvl+0x120/0x18c [ 45.971470] print_address_description.constprop.0+0x74/0x30c [ 45.972182] kasan_report+0x1e8/0x200 [ 45.972659] __asan_report_load8_noabort+0x2c/0x50 [ 45.973273] bpf_xdp_link_release+0x3b8/0x3d0 [ 45.973834] bpf_link_free+0xd0/0x188 [ 45.974315] bpf_link_put+0x1d0/0x218 [ 45.974790] bpf_link_release+0x3c/0x58 [ 45.975291] __fput+0x20c/0x7e8 [ 45.975706] ____fput+0x24/0x30 [ 45.976117] task_work_run+0x104/0x258 [ 45.976609] do_notify_resume+0x894/0xaf8 [ 45.977121] work_pending+0xc/0x328 [ 45.977575] [ 45.977775] The buggy address belongs to the page: [ 45.978369] page:fffffc00003e6600 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4f998 [ 45.979522] flags: 0x7fffe0000000000(node=0|zone=0|lastcpupid=0x3ffff) [ 45.980349] raw: 07fffe0000000000 fffffc00003e6708 ffff0000dac3c010 0000000000000000 [ 45.981309] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 [ 45.982259] page dumped because: kasan: bad access detected [ 45.982948] [ 45.983153] Memory state around the buggy address: [ 45.983753] ffff00000f997f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 45.984645] ffff00000f998000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 45.985533] >ffff00000f998080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 45.986419] ^ [ 45.987112] ffff00000f998100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 45.988006] ffff00000f998180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 45.988895] ================================================================== [ 45.989773] Disabling lock debugging due to kernel taint [ 45.990552] Kernel panic - not syncing: panic_on_warn set ... [ 45.991166] CPU: 1 PID: 732 Comm: a.out Tainted: G B 5.13.0+ #22 [ 45.991929] Hardware name: linux,dummy-virt (DT) [ 45.992448] Call trace: [ 45.992753] dump_backtrace+0x0/0x4c8 [ 45.993208] show_stack+0x30/0x40 [ 45.993627] dump_stack_lvl+0x120/0x18c [ 45.994113] dump_stack+0x1c/0x34 [ 45.994530] panic+0x3a4/0x7d8 [ 45.994930] end_report+0x194/0x198 [ 45.995380] kasan_report+0x134/0x200 [ 45.995850] __asan_report_load8_noabort+0x2c/0x50 [ 45.996453] bpf_xdp_link_release+0x3b8/0x3d0 [ 45.997007] bpf_link_free+0xd0/0x188 [ 45.997474] bpf_link_put+0x1d0/0x218 [ 45.997942] bpf_link_release+0x3c/0x58 [ 45.998429] __fput+0x20c/0x7e8 [ 45.998833] ____fput+0x24/0x30 [ 45.999247] task_work_run+0x104/0x258 [ 45.999731] do_notify_resume+0x894/0xaf8 [ 46.000236] work_pending+0xc/0x328 [ 46.000697] SMP: stopping secondary CPUs [ 46.001226] Dumping ftrace buffer: [ 46.001663] (ftrace buffer empty) [ 46.002110] Kernel Offset: disabled [ 46.002545] CPU features: 0x00000001,23202c00 [ 46.003080] Memory Limit: none Reported-by: Abaci <abaci@linux.alibaba.com> Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com> Reviewed-by: Dust Li <dust.li@linux.alibaba.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Jul 8, 2021
The problem occurs between dev_get_by_index() and dev_xdp_attach_link(). At this point in time, the xdp link will not be released automatically when dev is deleted. In this way, when xdp link is released, dev will still be accessed, but dev has been released. [ 45.966867] BUG: KASAN: use-after-free in bpf_xdp_link_release+0x3b8/0x3d0 [ 45.967619] Read of size 8 at addr ffff00000f9980c8 by task a.out/732 [ 45.968297] [ 45.968502] CPU: 1 PID: 732 Comm: a.out Not tainted 5.13.0+ #22 [ 45.969222] Hardware name: linux,dummy-virt (DT) [ 45.969795] Call trace: [ 45.970106] dump_backtrace+0x0/0x4c8 [ 45.970564] show_stack+0x30/0x40 [ 45.970981] dump_stack_lvl+0x120/0x18c [ 45.971470] print_address_description.constprop.0+0x74/0x30c [ 45.972182] kasan_report+0x1e8/0x200 [ 45.972659] __asan_report_load8_noabort+0x2c/0x50 [ 45.973273] bpf_xdp_link_release+0x3b8/0x3d0 [ 45.973834] bpf_link_free+0xd0/0x188 [ 45.974315] bpf_link_put+0x1d0/0x218 [ 45.974790] bpf_link_release+0x3c/0x58 [ 45.975291] __fput+0x20c/0x7e8 [ 45.975706] ____fput+0x24/0x30 [ 45.976117] task_work_run+0x104/0x258 [ 45.976609] do_notify_resume+0x894/0xaf8 [ 45.977121] work_pending+0xc/0x328 [ 45.977575] [ 45.977775] The buggy address belongs to the page: [ 45.978369] page:fffffc00003e6600 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4f998 [ 45.979522] flags: 0x7fffe0000000000(node=0|zone=0|lastcpupid=0x3ffff) [ 45.980349] raw: 07fffe0000000000 fffffc00003e6708 ffff0000dac3c010 0000000000000000 [ 45.981309] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 [ 45.982259] page dumped because: kasan: bad access detected [ 45.982948] [ 45.983153] Memory state around the buggy address: [ 45.983753] ffff00000f997f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 45.984645] ffff00000f998000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 45.985533] >ffff00000f998080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 45.986419] ^ [ 45.987112] ffff00000f998100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 45.988006] ffff00000f998180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 45.988895] ================================================================== [ 45.989773] Disabling lock debugging due to kernel taint [ 45.990552] Kernel panic - not syncing: panic_on_warn set ... [ 45.991166] CPU: 1 PID: 732 Comm: a.out Tainted: G B 5.13.0+ #22 [ 45.991929] Hardware name: linux,dummy-virt (DT) [ 45.992448] Call trace: [ 45.992753] dump_backtrace+0x0/0x4c8 [ 45.993208] show_stack+0x30/0x40 [ 45.993627] dump_stack_lvl+0x120/0x18c [ 45.994113] dump_stack+0x1c/0x34 [ 45.994530] panic+0x3a4/0x7d8 [ 45.994930] end_report+0x194/0x198 [ 45.995380] kasan_report+0x134/0x200 [ 45.995850] __asan_report_load8_noabort+0x2c/0x50 [ 45.996453] bpf_xdp_link_release+0x3b8/0x3d0 [ 45.997007] bpf_link_free+0xd0/0x188 [ 45.997474] bpf_link_put+0x1d0/0x218 [ 45.997942] bpf_link_release+0x3c/0x58 [ 45.998429] __fput+0x20c/0x7e8 [ 45.998833] ____fput+0x24/0x30 [ 45.999247] task_work_run+0x104/0x258 [ 45.999731] do_notify_resume+0x894/0xaf8 [ 46.000236] work_pending+0xc/0x328 [ 46.000697] SMP: stopping secondary CPUs [ 46.001226] Dumping ftrace buffer: [ 46.001663] (ftrace buffer empty) [ 46.002110] Kernel Offset: disabled [ 46.002545] CPU features: 0x00000001,23202c00 [ 46.003080] Memory Limit: none Reported-by: Abaci <abaci@linux.alibaba.com> Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com> Reviewed-by: Dust Li <dust.li@linux.alibaba.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Jul 9, 2021
The problem occurs between dev_get_by_index() and dev_xdp_attach_link().
At this point, dev_xdp_uninstall() is called. Then xdp link will not be
detached automatically when dev is released. But link->dev already
points to dev, when xdp link is released, dev will still be accessed,
but dev has been released.
dev_get_by_index() |
link->dev = dev |
| rtnl_lock()
| unregister_netdevice_many()
| dev_xdp_uninstall()
| rtnl_unlock()
rtnl_lock(); |
dev_xdp_attach_link() |
rtnl_unlock(); |
| netdev_run_todo() // dev released
bpf_xdp_link_release() |
/* access dev. |
use-after-free */ |
This patch adds a check of dev->reg_state in dev_xdp_attach_link(). If
dev has been called release, it will return -EINVAL.
[ 45.966867] BUG: KASAN: use-after-free in bpf_xdp_link_release+0x3b8/0x3d0
[ 45.967619] Read of size 8 at addr ffff00000f9980c8 by task a.out/732
[ 45.968297]
[ 45.968502] CPU: 1 PID: 732 Comm: a.out Not tainted 5.13.0+ #22
[ 45.969222] Hardware name: linux,dummy-virt (DT)
[ 45.969795] Call trace:
[ 45.970106] dump_backtrace+0x0/0x4c8
[ 45.970564] show_stack+0x30/0x40
[ 45.970981] dump_stack_lvl+0x120/0x18c
[ 45.971470] print_address_description.constprop.0+0x74/0x30c
[ 45.972182] kasan_report+0x1e8/0x200
[ 45.972659] __asan_report_load8_noabort+0x2c/0x50
[ 45.973273] bpf_xdp_link_release+0x3b8/0x3d0
[ 45.973834] bpf_link_free+0xd0/0x188
[ 45.974315] bpf_link_put+0x1d0/0x218
[ 45.974790] bpf_link_release+0x3c/0x58
[ 45.975291] __fput+0x20c/0x7e8
[ 45.975706] ____fput+0x24/0x30
[ 45.976117] task_work_run+0x104/0x258
[ 45.976609] do_notify_resume+0x894/0xaf8
[ 45.977121] work_pending+0xc/0x328
[ 45.977575]
[ 45.977775] The buggy address belongs to the page:
[ 45.978369] page:fffffc00003e6600 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4f998
[ 45.979522] flags: 0x7fffe0000000000(node=0|zone=0|lastcpupid=0x3ffff)
[ 45.980349] raw: 07fffe0000000000 fffffc00003e6708 ffff0000dac3c010 0000000000000000
[ 45.981309] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
[ 45.982259] page dumped because: kasan: bad access detected
[ 45.982948]
[ 45.983153] Memory state around the buggy address:
[ 45.983753] ffff00000f997f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 45.984645] ffff00000f998000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 45.985533] >ffff00000f998080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 45.986419] ^
[ 45.987112] ffff00000f998100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 45.988006] ffff00000f998180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 45.988895] ==================================================================
[ 45.989773] Disabling lock debugging due to kernel taint
[ 45.990552] Kernel panic - not syncing: panic_on_warn set ...
[ 45.991166] CPU: 1 PID: 732 Comm: a.out Tainted: G B 5.13.0+ #22
[ 45.991929] Hardware name: linux,dummy-virt (DT)
[ 45.992448] Call trace:
[ 45.992753] dump_backtrace+0x0/0x4c8
[ 45.993208] show_stack+0x30/0x40
[ 45.993627] dump_stack_lvl+0x120/0x18c
[ 45.994113] dump_stack+0x1c/0x34
[ 45.994530] panic+0x3a4/0x7d8
[ 45.994930] end_report+0x194/0x198
[ 45.995380] kasan_report+0x134/0x200
[ 45.995850] __asan_report_load8_noabort+0x2c/0x50
[ 45.996453] bpf_xdp_link_release+0x3b8/0x3d0
[ 45.997007] bpf_link_free+0xd0/0x188
[ 45.997474] bpf_link_put+0x1d0/0x218
[ 45.997942] bpf_link_release+0x3c/0x58
[ 45.998429] __fput+0x20c/0x7e8
[ 45.998833] ____fput+0x24/0x30
[ 45.999247] task_work_run+0x104/0x258
[ 45.999731] do_notify_resume+0x894/0xaf8
[ 46.000236] work_pending+0xc/0x328
[ 46.000697] SMP: stopping secondary CPUs
[ 46.001226] Dumping ftrace buffer:
[ 46.001663] (ftrace buffer empty)
[ 46.002110] Kernel Offset: disabled
[ 46.002545] CPU features: 0x00000001,23202c00
[ 46.003080] Memory Limit: none
Reported-by: Abaci <abaci@linux.alibaba.com>
Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Reviewed-by: Dust Li <dust.li@linux.alibaba.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Jul 9, 2021
The problem occurs between dev_get_by_index() and dev_xdp_attach_link().
At this point, dev_xdp_uninstall() is called. Then xdp link will not be
detached automatically when dev is released. But link->dev already
points to dev, when xdp link is released, dev will still be accessed,
but dev has been released.
dev_get_by_index() |
link->dev = dev |
| rtnl_lock()
| unregister_netdevice_many()
| dev_xdp_uninstall()
| rtnl_unlock()
rtnl_lock(); |
dev_xdp_attach_link() |
rtnl_unlock(); |
| netdev_run_todo() // dev released
bpf_xdp_link_release() |
/* access dev. |
use-after-free */ |
This patch adds a check of dev->reg_state in dev_xdp_attach_link(). If
dev has been called release, it will return -EINVAL.
[ 45.966867] BUG: KASAN: use-after-free in bpf_xdp_link_release+0x3b8/0x3d0
[ 45.967619] Read of size 8 at addr ffff00000f9980c8 by task a.out/732
[ 45.968297]
[ 45.968502] CPU: 1 PID: 732 Comm: a.out Not tainted 5.13.0+ #22
[ 45.969222] Hardware name: linux,dummy-virt (DT)
[ 45.969795] Call trace:
[ 45.970106] dump_backtrace+0x0/0x4c8
[ 45.970564] show_stack+0x30/0x40
[ 45.970981] dump_stack_lvl+0x120/0x18c
[ 45.971470] print_address_description.constprop.0+0x74/0x30c
[ 45.972182] kasan_report+0x1e8/0x200
[ 45.972659] __asan_report_load8_noabort+0x2c/0x50
[ 45.973273] bpf_xdp_link_release+0x3b8/0x3d0
[ 45.973834] bpf_link_free+0xd0/0x188
[ 45.974315] bpf_link_put+0x1d0/0x218
[ 45.974790] bpf_link_release+0x3c/0x58
[ 45.975291] __fput+0x20c/0x7e8
[ 45.975706] ____fput+0x24/0x30
[ 45.976117] task_work_run+0x104/0x258
[ 45.976609] do_notify_resume+0x894/0xaf8
[ 45.977121] work_pending+0xc/0x328
[ 45.977575]
[ 45.977775] The buggy address belongs to the page:
[ 45.978369] page:fffffc00003e6600 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4f998
[ 45.979522] flags: 0x7fffe0000000000(node=0|zone=0|lastcpupid=0x3ffff)
[ 45.980349] raw: 07fffe0000000000 fffffc00003e6708 ffff0000dac3c010 0000000000000000
[ 45.981309] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
[ 45.982259] page dumped because: kasan: bad access detected
[ 45.982948]
[ 45.983153] Memory state around the buggy address:
[ 45.983753] ffff00000f997f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 45.984645] ffff00000f998000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 45.985533] >ffff00000f998080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 45.986419] ^
[ 45.987112] ffff00000f998100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 45.988006] ffff00000f998180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 45.988895] ==================================================================
[ 45.989773] Disabling lock debugging due to kernel taint
[ 45.990552] Kernel panic - not syncing: panic_on_warn set ...
[ 45.991166] CPU: 1 PID: 732 Comm: a.out Tainted: G B 5.13.0+ #22
[ 45.991929] Hardware name: linux,dummy-virt (DT)
[ 45.992448] Call trace:
[ 45.992753] dump_backtrace+0x0/0x4c8
[ 45.993208] show_stack+0x30/0x40
[ 45.993627] dump_stack_lvl+0x120/0x18c
[ 45.994113] dump_stack+0x1c/0x34
[ 45.994530] panic+0x3a4/0x7d8
[ 45.994930] end_report+0x194/0x198
[ 45.995380] kasan_report+0x134/0x200
[ 45.995850] __asan_report_load8_noabort+0x2c/0x50
[ 45.996453] bpf_xdp_link_release+0x3b8/0x3d0
[ 45.997007] bpf_link_free+0xd0/0x188
[ 45.997474] bpf_link_put+0x1d0/0x218
[ 45.997942] bpf_link_release+0x3c/0x58
[ 45.998429] __fput+0x20c/0x7e8
[ 45.998833] ____fput+0x24/0x30
[ 45.999247] task_work_run+0x104/0x258
[ 45.999731] do_notify_resume+0x894/0xaf8
[ 46.000236] work_pending+0xc/0x328
[ 46.000697] SMP: stopping secondary CPUs
[ 46.001226] Dumping ftrace buffer:
[ 46.001663] (ftrace buffer empty)
[ 46.002110] Kernel Offset: disabled
[ 46.002545] CPU features: 0x00000001,23202c00
[ 46.003080] Memory Limit: none
Reported-by: Abaci <abaci@linux.alibaba.com>
Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Reviewed-by: Dust Li <dust.li@linux.alibaba.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Jul 9, 2021
The problem occurs between dev_get_by_index() and dev_xdp_attach_link().
At this point, dev_xdp_uninstall() is called. Then xdp link will not be
detached automatically when dev is released. But link->dev already
points to dev, when xdp link is released, dev will still be accessed,
but dev has been released.
dev_get_by_index() |
link->dev = dev |
| rtnl_lock()
| unregister_netdevice_many()
| dev_xdp_uninstall()
| rtnl_unlock()
rtnl_lock(); |
dev_xdp_attach_link() |
rtnl_unlock(); |
| netdev_run_todo() // dev released
bpf_xdp_link_release() |
/* access dev. |
use-after-free */ |
This patch adds a check of dev->reg_state in dev_xdp_attach_link(). If
dev has been called release, it will return -EINVAL.
[ 45.966867] BUG: KASAN: use-after-free in bpf_xdp_link_release+0x3b8/0x3d0
[ 45.967619] Read of size 8 at addr ffff00000f9980c8 by task a.out/732
[ 45.968297]
[ 45.968502] CPU: 1 PID: 732 Comm: a.out Not tainted 5.13.0+ #22
[ 45.969222] Hardware name: linux,dummy-virt (DT)
[ 45.969795] Call trace:
[ 45.970106] dump_backtrace+0x0/0x4c8
[ 45.970564] show_stack+0x30/0x40
[ 45.970981] dump_stack_lvl+0x120/0x18c
[ 45.971470] print_address_description.constprop.0+0x74/0x30c
[ 45.972182] kasan_report+0x1e8/0x200
[ 45.972659] __asan_report_load8_noabort+0x2c/0x50
[ 45.973273] bpf_xdp_link_release+0x3b8/0x3d0
[ 45.973834] bpf_link_free+0xd0/0x188
[ 45.974315] bpf_link_put+0x1d0/0x218
[ 45.974790] bpf_link_release+0x3c/0x58
[ 45.975291] __fput+0x20c/0x7e8
[ 45.975706] ____fput+0x24/0x30
[ 45.976117] task_work_run+0x104/0x258
[ 45.976609] do_notify_resume+0x894/0xaf8
[ 45.977121] work_pending+0xc/0x328
[ 45.977575]
[ 45.977775] The buggy address belongs to the page:
[ 45.978369] page:fffffc00003e6600 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4f998
[ 45.979522] flags: 0x7fffe0000000000(node=0|zone=0|lastcpupid=0x3ffff)
[ 45.980349] raw: 07fffe0000000000 fffffc00003e6708 ffff0000dac3c010 0000000000000000
[ 45.981309] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
[ 45.982259] page dumped because: kasan: bad access detected
[ 45.982948]
[ 45.983153] Memory state around the buggy address:
[ 45.983753] ffff00000f997f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 45.984645] ffff00000f998000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 45.985533] >ffff00000f998080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 45.986419] ^
[ 45.987112] ffff00000f998100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 45.988006] ffff00000f998180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 45.988895] ==================================================================
[ 45.989773] Disabling lock debugging due to kernel taint
[ 45.990552] Kernel panic - not syncing: panic_on_warn set ...
[ 45.991166] CPU: 1 PID: 732 Comm: a.out Tainted: G B 5.13.0+ #22
[ 45.991929] Hardware name: linux,dummy-virt (DT)
[ 45.992448] Call trace:
[ 45.992753] dump_backtrace+0x0/0x4c8
[ 45.993208] show_stack+0x30/0x40
[ 45.993627] dump_stack_lvl+0x120/0x18c
[ 45.994113] dump_stack+0x1c/0x34
[ 45.994530] panic+0x3a4/0x7d8
[ 45.994930] end_report+0x194/0x198
[ 45.995380] kasan_report+0x134/0x200
[ 45.995850] __asan_report_load8_noabort+0x2c/0x50
[ 45.996453] bpf_xdp_link_release+0x3b8/0x3d0
[ 45.997007] bpf_link_free+0xd0/0x188
[ 45.997474] bpf_link_put+0x1d0/0x218
[ 45.997942] bpf_link_release+0x3c/0x58
[ 45.998429] __fput+0x20c/0x7e8
[ 45.998833] ____fput+0x24/0x30
[ 45.999247] task_work_run+0x104/0x258
[ 45.999731] do_notify_resume+0x894/0xaf8
[ 46.000236] work_pending+0xc/0x328
[ 46.000697] SMP: stopping secondary CPUs
[ 46.001226] Dumping ftrace buffer:
[ 46.001663] (ftrace buffer empty)
[ 46.002110] Kernel Offset: disabled
[ 46.002545] CPU features: 0x00000001,23202c00
[ 46.003080] Memory Limit: none
Reported-by: Abaci <abaci@linux.alibaba.com>
Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Reviewed-by: Dust Li <dust.li@linux.alibaba.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Jul 9, 2021
The problem occurs between dev_get_by_index() and dev_xdp_attach_link().
At this point, dev_xdp_uninstall() is called. Then xdp link will not be
detached automatically when dev is released. But link->dev already
points to dev, when xdp link is released, dev will still be accessed,
but dev has been released.
dev_get_by_index() |
link->dev = dev |
| rtnl_lock()
| unregister_netdevice_many()
| dev_xdp_uninstall()
| rtnl_unlock()
rtnl_lock(); |
dev_xdp_attach_link() |
rtnl_unlock(); |
| netdev_run_todo() // dev released
bpf_xdp_link_release() |
/* access dev. |
use-after-free */ |
This patch adds a check of dev->reg_state in dev_xdp_attach_link(). If
dev has been called release, it will return -EINVAL.
[ 45.966867] BUG: KASAN: use-after-free in bpf_xdp_link_release+0x3b8/0x3d0
[ 45.967619] Read of size 8 at addr ffff00000f9980c8 by task a.out/732
[ 45.968297]
[ 45.968502] CPU: 1 PID: 732 Comm: a.out Not tainted 5.13.0+ #22
[ 45.969222] Hardware name: linux,dummy-virt (DT)
[ 45.969795] Call trace:
[ 45.970106] dump_backtrace+0x0/0x4c8
[ 45.970564] show_stack+0x30/0x40
[ 45.970981] dump_stack_lvl+0x120/0x18c
[ 45.971470] print_address_description.constprop.0+0x74/0x30c
[ 45.972182] kasan_report+0x1e8/0x200
[ 45.972659] __asan_report_load8_noabort+0x2c/0x50
[ 45.973273] bpf_xdp_link_release+0x3b8/0x3d0
[ 45.973834] bpf_link_free+0xd0/0x188
[ 45.974315] bpf_link_put+0x1d0/0x218
[ 45.974790] bpf_link_release+0x3c/0x58
[ 45.975291] __fput+0x20c/0x7e8
[ 45.975706] ____fput+0x24/0x30
[ 45.976117] task_work_run+0x104/0x258
[ 45.976609] do_notify_resume+0x894/0xaf8
[ 45.977121] work_pending+0xc/0x328
[ 45.977575]
[ 45.977775] The buggy address belongs to the page:
[ 45.978369] page:fffffc00003e6600 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4f998
[ 45.979522] flags: 0x7fffe0000000000(node=0|zone=0|lastcpupid=0x3ffff)
[ 45.980349] raw: 07fffe0000000000 fffffc00003e6708 ffff0000dac3c010 0000000000000000
[ 45.981309] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
[ 45.982259] page dumped because: kasan: bad access detected
[ 45.982948]
[ 45.983153] Memory state around the buggy address:
[ 45.983753] ffff00000f997f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 45.984645] ffff00000f998000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 45.985533] >ffff00000f998080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 45.986419] ^
[ 45.987112] ffff00000f998100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 45.988006] ffff00000f998180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 45.988895] ==================================================================
[ 45.989773] Disabling lock debugging due to kernel taint
[ 45.990552] Kernel panic - not syncing: panic_on_warn set ...
[ 45.991166] CPU: 1 PID: 732 Comm: a.out Tainted: G B 5.13.0+ #22
[ 45.991929] Hardware name: linux,dummy-virt (DT)
[ 45.992448] Call trace:
[ 45.992753] dump_backtrace+0x0/0x4c8
[ 45.993208] show_stack+0x30/0x40
[ 45.993627] dump_stack_lvl+0x120/0x18c
[ 45.994113] dump_stack+0x1c/0x34
[ 45.994530] panic+0x3a4/0x7d8
[ 45.994930] end_report+0x194/0x198
[ 45.995380] kasan_report+0x134/0x200
[ 45.995850] __asan_report_load8_noabort+0x2c/0x50
[ 45.996453] bpf_xdp_link_release+0x3b8/0x3d0
[ 45.997007] bpf_link_free+0xd0/0x188
[ 45.997474] bpf_link_put+0x1d0/0x218
[ 45.997942] bpf_link_release+0x3c/0x58
[ 45.998429] __fput+0x20c/0x7e8
[ 45.998833] ____fput+0x24/0x30
[ 45.999247] task_work_run+0x104/0x258
[ 45.999731] do_notify_resume+0x894/0xaf8
[ 46.000236] work_pending+0xc/0x328
[ 46.000697] SMP: stopping secondary CPUs
[ 46.001226] Dumping ftrace buffer:
[ 46.001663] (ftrace buffer empty)
[ 46.002110] Kernel Offset: disabled
[ 46.002545] CPU features: 0x00000001,23202c00
[ 46.003080] Memory Limit: none
Reported-by: Abaci <abaci@linux.alibaba.com>
Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Reviewed-by: Dust Li <dust.li@linux.alibaba.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Jul 10, 2021
The problem occurs between dev_get_by_index() and dev_xdp_attach_link().
At this point, dev_xdp_uninstall() is called. Then xdp link will not be
detached automatically when dev is released. But link->dev already
points to dev, when xdp link is released, dev will still be accessed,
but dev has been released.
dev_get_by_index() |
link->dev = dev |
| rtnl_lock()
| unregister_netdevice_many()
| dev_xdp_uninstall()
| rtnl_unlock()
rtnl_lock(); |
dev_xdp_attach_link() |
rtnl_unlock(); |
| netdev_run_todo() // dev released
bpf_xdp_link_release() |
/* access dev. |
use-after-free */ |
[ 45.966867] BUG: KASAN: use-after-free in bpf_xdp_link_release+0x3b8/0x3d0
[ 45.967619] Read of size 8 at addr ffff00000f9980c8 by task a.out/732
[ 45.968297]
[ 45.968502] CPU: 1 PID: 732 Comm: a.out Not tainted 5.13.0+ #22
[ 45.969222] Hardware name: linux,dummy-virt (DT)
[ 45.969795] Call trace:
[ 45.970106] dump_backtrace+0x0/0x4c8
[ 45.970564] show_stack+0x30/0x40
[ 45.970981] dump_stack_lvl+0x120/0x18c
[ 45.971470] print_address_description.constprop.0+0x74/0x30c
[ 45.972182] kasan_report+0x1e8/0x200
[ 45.972659] __asan_report_load8_noabort+0x2c/0x50
[ 45.973273] bpf_xdp_link_release+0x3b8/0x3d0
[ 45.973834] bpf_link_free+0xd0/0x188
[ 45.974315] bpf_link_put+0x1d0/0x218
[ 45.974790] bpf_link_release+0x3c/0x58
[ 45.975291] __fput+0x20c/0x7e8
[ 45.975706] ____fput+0x24/0x30
[ 45.976117] task_work_run+0x104/0x258
[ 45.976609] do_notify_resume+0x894/0xaf8
[ 45.977121] work_pending+0xc/0x328
[ 45.977575]
[ 45.977775] The buggy address belongs to the page:
[ 45.978369] page:fffffc00003e6600 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4f998
[ 45.979522] flags: 0x7fffe0000000000(node=0|zone=0|lastcpupid=0x3ffff)
[ 45.980349] raw: 07fffe0000000000 fffffc00003e6708 ffff0000dac3c010 0000000000000000
[ 45.981309] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
[ 45.982259] page dumped because: kasan: bad access detected
[ 45.982948]
[ 45.983153] Memory state around the buggy address:
[ 45.983753] ffff00000f997f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 45.984645] ffff00000f998000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 45.985533] >ffff00000f998080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 45.986419] ^
[ 45.987112] ffff00000f998100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 45.988006] ffff00000f998180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 45.988895] ==================================================================
[ 45.989773] Disabling lock debugging due to kernel taint
[ 45.990552] Kernel panic - not syncing: panic_on_warn set ...
[ 45.991166] CPU: 1 PID: 732 Comm: a.out Tainted: G B 5.13.0+ #22
[ 45.991929] Hardware name: linux,dummy-virt (DT)
[ 45.992448] Call trace:
[ 45.992753] dump_backtrace+0x0/0x4c8
[ 45.993208] show_stack+0x30/0x40
[ 45.993627] dump_stack_lvl+0x120/0x18c
[ 45.994113] dump_stack+0x1c/0x34
[ 45.994530] panic+0x3a4/0x7d8
[ 45.994930] end_report+0x194/0x198
[ 45.995380] kasan_report+0x134/0x200
[ 45.995850] __asan_report_load8_noabort+0x2c/0x50
[ 45.996453] bpf_xdp_link_release+0x3b8/0x3d0
[ 45.997007] bpf_link_free+0xd0/0x188
[ 45.997474] bpf_link_put+0x1d0/0x218
[ 45.997942] bpf_link_release+0x3c/0x58
[ 45.998429] __fput+0x20c/0x7e8
[ 45.998833] ____fput+0x24/0x30
[ 45.999247] task_work_run+0x104/0x258
[ 45.999731] do_notify_resume+0x894/0xaf8
[ 46.000236] work_pending+0xc/0x328
[ 46.000697] SMP: stopping secondary CPUs
[ 46.001226] Dumping ftrace buffer:
[ 46.001663] (ftrace buffer empty)
[ 46.002110] Kernel Offset: disabled
[ 46.002545] CPU features: 0x00000001,23202c00
[ 46.003080] Memory Limit: none
Fixes: aa8d3a7 ("bpf, xdp: Add bpf_link-based XDP attachment API")
Reported-by: Abaci <abaci@linux.alibaba.com>
Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Reviewed-by: Dust Li <dust.li@linux.alibaba.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Jul 10, 2021
The problem occurs between dev_get_by_index() and dev_xdp_attach_link().
At this point, dev_xdp_uninstall() is called. Then xdp link will not be
detached automatically when dev is released. But link->dev already
points to dev, when xdp link is released, dev will still be accessed,
but dev has been released.
dev_get_by_index() |
link->dev = dev |
| rtnl_lock()
| unregister_netdevice_many()
| dev_xdp_uninstall()
| rtnl_unlock()
rtnl_lock(); |
dev_xdp_attach_link() |
rtnl_unlock(); |
| netdev_run_todo() // dev released
bpf_xdp_link_release() |
/* access dev. |
use-after-free */ |
[ 45.966867] BUG: KASAN: use-after-free in bpf_xdp_link_release+0x3b8/0x3d0
[ 45.967619] Read of size 8 at addr ffff00000f9980c8 by task a.out/732
[ 45.968297]
[ 45.968502] CPU: 1 PID: 732 Comm: a.out Not tainted 5.13.0+ #22
[ 45.969222] Hardware name: linux,dummy-virt (DT)
[ 45.969795] Call trace:
[ 45.970106] dump_backtrace+0x0/0x4c8
[ 45.970564] show_stack+0x30/0x40
[ 45.970981] dump_stack_lvl+0x120/0x18c
[ 45.971470] print_address_description.constprop.0+0x74/0x30c
[ 45.972182] kasan_report+0x1e8/0x200
[ 45.972659] __asan_report_load8_noabort+0x2c/0x50
[ 45.973273] bpf_xdp_link_release+0x3b8/0x3d0
[ 45.973834] bpf_link_free+0xd0/0x188
[ 45.974315] bpf_link_put+0x1d0/0x218
[ 45.974790] bpf_link_release+0x3c/0x58
[ 45.975291] __fput+0x20c/0x7e8
[ 45.975706] ____fput+0x24/0x30
[ 45.976117] task_work_run+0x104/0x258
[ 45.976609] do_notify_resume+0x894/0xaf8
[ 45.977121] work_pending+0xc/0x328
[ 45.977575]
[ 45.977775] The buggy address belongs to the page:
[ 45.978369] page:fffffc00003e6600 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4f998
[ 45.979522] flags: 0x7fffe0000000000(node=0|zone=0|lastcpupid=0x3ffff)
[ 45.980349] raw: 07fffe0000000000 fffffc00003e6708 ffff0000dac3c010 0000000000000000
[ 45.981309] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
[ 45.982259] page dumped because: kasan: bad access detected
[ 45.982948]
[ 45.983153] Memory state around the buggy address:
[ 45.983753] ffff00000f997f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 45.984645] ffff00000f998000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 45.985533] >ffff00000f998080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 45.986419] ^
[ 45.987112] ffff00000f998100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 45.988006] ffff00000f998180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 45.988895] ==================================================================
[ 45.989773] Disabling lock debugging due to kernel taint
[ 45.990552] Kernel panic - not syncing: panic_on_warn set ...
[ 45.991166] CPU: 1 PID: 732 Comm: a.out Tainted: G B 5.13.0+ #22
[ 45.991929] Hardware name: linux,dummy-virt (DT)
[ 45.992448] Call trace:
[ 45.992753] dump_backtrace+0x0/0x4c8
[ 45.993208] show_stack+0x30/0x40
[ 45.993627] dump_stack_lvl+0x120/0x18c
[ 45.994113] dump_stack+0x1c/0x34
[ 45.994530] panic+0x3a4/0x7d8
[ 45.994930] end_report+0x194/0x198
[ 45.995380] kasan_report+0x134/0x200
[ 45.995850] __asan_report_load8_noabort+0x2c/0x50
[ 45.996453] bpf_xdp_link_release+0x3b8/0x3d0
[ 45.997007] bpf_link_free+0xd0/0x188
[ 45.997474] bpf_link_put+0x1d0/0x218
[ 45.997942] bpf_link_release+0x3c/0x58
[ 45.998429] __fput+0x20c/0x7e8
[ 45.998833] ____fput+0x24/0x30
[ 45.999247] task_work_run+0x104/0x258
[ 45.999731] do_notify_resume+0x894/0xaf8
[ 46.000236] work_pending+0xc/0x328
[ 46.000697] SMP: stopping secondary CPUs
[ 46.001226] Dumping ftrace buffer:
[ 46.001663] (ftrace buffer empty)
[ 46.002110] Kernel Offset: disabled
[ 46.002545] CPU features: 0x00000001,23202c00
[ 46.003080] Memory Limit: none
Fixes: aa8d3a7 ("bpf, xdp: Add bpf_link-based XDP attachment API")
Reported-by: Abaci <abaci@linux.alibaba.com>
Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Reviewed-by: Dust Li <dust.li@linux.alibaba.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Jul 12, 2021
The problem occurs between dev_get_by_index() and dev_xdp_attach_link().
At this point, dev_xdp_uninstall() is called. Then xdp link will not be
detached automatically when dev is released. But link->dev already
points to dev, when xdp link is released, dev will still be accessed,
but dev has been released.
dev_get_by_index() |
link->dev = dev |
| rtnl_lock()
| unregister_netdevice_many()
| dev_xdp_uninstall()
| rtnl_unlock()
rtnl_lock(); |
dev_xdp_attach_link() |
rtnl_unlock(); |
| netdev_run_todo() // dev released
bpf_xdp_link_release() |
/* access dev. |
use-after-free */ |
[ 45.966867] BUG: KASAN: use-after-free in bpf_xdp_link_release+0x3b8/0x3d0
[ 45.967619] Read of size 8 at addr ffff00000f9980c8 by task a.out/732
[ 45.968297]
[ 45.968502] CPU: 1 PID: 732 Comm: a.out Not tainted 5.13.0+ #22
[ 45.969222] Hardware name: linux,dummy-virt (DT)
[ 45.969795] Call trace:
[ 45.970106] dump_backtrace+0x0/0x4c8
[ 45.970564] show_stack+0x30/0x40
[ 45.970981] dump_stack_lvl+0x120/0x18c
[ 45.971470] print_address_description.constprop.0+0x74/0x30c
[ 45.972182] kasan_report+0x1e8/0x200
[ 45.972659] __asan_report_load8_noabort+0x2c/0x50
[ 45.973273] bpf_xdp_link_release+0x3b8/0x3d0
[ 45.973834] bpf_link_free+0xd0/0x188
[ 45.974315] bpf_link_put+0x1d0/0x218
[ 45.974790] bpf_link_release+0x3c/0x58
[ 45.975291] __fput+0x20c/0x7e8
[ 45.975706] ____fput+0x24/0x30
[ 45.976117] task_work_run+0x104/0x258
[ 45.976609] do_notify_resume+0x894/0xaf8
[ 45.977121] work_pending+0xc/0x328
[ 45.977575]
[ 45.977775] The buggy address belongs to the page:
[ 45.978369] page:fffffc00003e6600 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4f998
[ 45.979522] flags: 0x7fffe0000000000(node=0|zone=0|lastcpupid=0x3ffff)
[ 45.980349] raw: 07fffe0000000000 fffffc00003e6708 ffff0000dac3c010 0000000000000000
[ 45.981309] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
[ 45.982259] page dumped because: kasan: bad access detected
[ 45.982948]
[ 45.983153] Memory state around the buggy address:
[ 45.983753] ffff00000f997f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 45.984645] ffff00000f998000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 45.985533] >ffff00000f998080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 45.986419] ^
[ 45.987112] ffff00000f998100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 45.988006] ffff00000f998180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 45.988895] ==================================================================
[ 45.989773] Disabling lock debugging due to kernel taint
[ 45.990552] Kernel panic - not syncing: panic_on_warn set ...
[ 45.991166] CPU: 1 PID: 732 Comm: a.out Tainted: G B 5.13.0+ #22
[ 45.991929] Hardware name: linux,dummy-virt (DT)
[ 45.992448] Call trace:
[ 45.992753] dump_backtrace+0x0/0x4c8
[ 45.993208] show_stack+0x30/0x40
[ 45.993627] dump_stack_lvl+0x120/0x18c
[ 45.994113] dump_stack+0x1c/0x34
[ 45.994530] panic+0x3a4/0x7d8
[ 45.994930] end_report+0x194/0x198
[ 45.995380] kasan_report+0x134/0x200
[ 45.995850] __asan_report_load8_noabort+0x2c/0x50
[ 45.996453] bpf_xdp_link_release+0x3b8/0x3d0
[ 45.997007] bpf_link_free+0xd0/0x188
[ 45.997474] bpf_link_put+0x1d0/0x218
[ 45.997942] bpf_link_release+0x3c/0x58
[ 45.998429] __fput+0x20c/0x7e8
[ 45.998833] ____fput+0x24/0x30
[ 45.999247] task_work_run+0x104/0x258
[ 45.999731] do_notify_resume+0x894/0xaf8
[ 46.000236] work_pending+0xc/0x328
[ 46.000697] SMP: stopping secondary CPUs
[ 46.001226] Dumping ftrace buffer:
[ 46.001663] (ftrace buffer empty)
[ 46.002110] Kernel Offset: disabled
[ 46.002545] CPU features: 0x00000001,23202c00
[ 46.003080] Memory Limit: none
Fixes: aa8d3a7 ("bpf, xdp: Add bpf_link-based XDP attachment API")
Reported-by: Abaci <abaci@linux.alibaba.com>
Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Reviewed-by: Dust Li <dust.li@linux.alibaba.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Jul 12, 2021
The problem occurs between dev_get_by_index() and dev_xdp_attach_link().
At this point, dev_xdp_uninstall() is called. Then xdp link will not be
detached automatically when dev is released. But link->dev already
points to dev, when xdp link is released, dev will still be accessed,
but dev has been released.
dev_get_by_index() |
link->dev = dev |
| rtnl_lock()
| unregister_netdevice_many()
| dev_xdp_uninstall()
| rtnl_unlock()
rtnl_lock(); |
dev_xdp_attach_link() |
rtnl_unlock(); |
| netdev_run_todo() // dev released
bpf_xdp_link_release() |
/* access dev. |
use-after-free */ |
[ 45.966867] BUG: KASAN: use-after-free in bpf_xdp_link_release+0x3b8/0x3d0
[ 45.967619] Read of size 8 at addr ffff00000f9980c8 by task a.out/732
[ 45.968297]
[ 45.968502] CPU: 1 PID: 732 Comm: a.out Not tainted 5.13.0+ #22
[ 45.969222] Hardware name: linux,dummy-virt (DT)
[ 45.969795] Call trace:
[ 45.970106] dump_backtrace+0x0/0x4c8
[ 45.970564] show_stack+0x30/0x40
[ 45.970981] dump_stack_lvl+0x120/0x18c
[ 45.971470] print_address_description.constprop.0+0x74/0x30c
[ 45.972182] kasan_report+0x1e8/0x200
[ 45.972659] __asan_report_load8_noabort+0x2c/0x50
[ 45.973273] bpf_xdp_link_release+0x3b8/0x3d0
[ 45.973834] bpf_link_free+0xd0/0x188
[ 45.974315] bpf_link_put+0x1d0/0x218
[ 45.974790] bpf_link_release+0x3c/0x58
[ 45.975291] __fput+0x20c/0x7e8
[ 45.975706] ____fput+0x24/0x30
[ 45.976117] task_work_run+0x104/0x258
[ 45.976609] do_notify_resume+0x894/0xaf8
[ 45.977121] work_pending+0xc/0x328
[ 45.977575]
[ 45.977775] The buggy address belongs to the page:
[ 45.978369] page:fffffc00003e6600 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4f998
[ 45.979522] flags: 0x7fffe0000000000(node=0|zone=0|lastcpupid=0x3ffff)
[ 45.980349] raw: 07fffe0000000000 fffffc00003e6708 ffff0000dac3c010 0000000000000000
[ 45.981309] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
[ 45.982259] page dumped because: kasan: bad access detected
[ 45.982948]
[ 45.983153] Memory state around the buggy address:
[ 45.983753] ffff00000f997f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 45.984645] ffff00000f998000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 45.985533] >ffff00000f998080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 45.986419] ^
[ 45.987112] ffff00000f998100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 45.988006] ffff00000f998180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[ 45.988895] ==================================================================
[ 45.989773] Disabling lock debugging due to kernel taint
[ 45.990552] Kernel panic - not syncing: panic_on_warn set ...
[ 45.991166] CPU: 1 PID: 732 Comm: a.out Tainted: G B 5.13.0+ #22
[ 45.991929] Hardware name: linux,dummy-virt (DT)
[ 45.992448] Call trace:
[ 45.992753] dump_backtrace+0x0/0x4c8
[ 45.993208] show_stack+0x30/0x40
[ 45.993627] dump_stack_lvl+0x120/0x18c
[ 45.994113] dump_stack+0x1c/0x34
[ 45.994530] panic+0x3a4/0x7d8
[ 45.994930] end_report+0x194/0x198
[ 45.995380] kasan_report+0x134/0x200
[ 45.995850] __asan_report_load8_noabort+0x2c/0x50
[ 45.996453] bpf_xdp_link_release+0x3b8/0x3d0
[ 45.997007] bpf_link_free+0xd0/0x188
[ 45.997474] bpf_link_put+0x1d0/0x218
[ 45.997942] bpf_link_release+0x3c/0x58
[ 45.998429] __fput+0x20c/0x7e8
[ 45.998833] ____fput+0x24/0x30
[ 45.999247] task_work_run+0x104/0x258
[ 45.999731] do_notify_resume+0x894/0xaf8
[ 46.000236] work_pending+0xc/0x328
[ 46.000697] SMP: stopping secondary CPUs
[ 46.001226] Dumping ftrace buffer:
[ 46.001663] (ftrace buffer empty)
[ 46.002110] Kernel Offset: disabled
[ 46.002545] CPU features: 0x00000001,23202c00
[ 46.003080] Memory Limit: none
Fixes: aa8d3a7 ("bpf, xdp: Add bpf_link-based XDP attachment API")
Reported-by: Abaci <abaci@linux.alibaba.com>
Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
Reviewed-by: Dust Li <dust.li@linux.alibaba.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Dec 13, 2021
Added a selftest with two __user usages: a __user pointer-type argument and a __user pointer-type struct member. In both cases, directly accessing the user memory will result verification failure. $ ./test_progs -v -n 22/3 ... libbpf: load bpf program failed: Permission denied libbpf: -- BEGIN DUMP LOG --- libbpf: R1 type=ctx expected=fp ; int BPF_PROG(test_user1, struct bpf_testmod_btf_type_tag_1 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_1' arg0 has btf_id 143948 addr_space 1 type STRUCT 'bpf_testmod_btf_type_tag_1' ; g = arg->a; 1: (61) r1 = *(u32 *)(r1 +0) R1 is ptr_bpf_testmod_btf_type_tag_1 access user memory: off=0 ... #22/3 btf_tag/btf_type_tag_user_1:OK $ ./test_progs -v -n 22/4 ... libbpf: load bpf program failed: Permission denied libbpf: -- BEGIN DUMP LOG --- libbpf: R1 type=ctx expected=fp ; int BPF_PROG(test_user2, struct bpf_testmod_btf_type_tag_2 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_2' arg0 has btf_id 143950 addr_space 0 type STRUCT 'bpf_testmod_btf_type_tag_2' ; g = arg->p->a; 1: (79) r1 = *(u64 *)(r1 +0) ; g = arg->p->a; 2: (61) r1 = *(u32 *)(r1 +0) R1 is ptr_bpf_testmod_btf_type_tag_1 access user memory: off=0 ... #22/4 btf_tag/btf_type_tag_user_2:OK Signed-off-by: Yonghong Song <yhs@fb.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Dec 13, 2021
Added a selftest with two __user usages: a __user pointer-type argument and a __user pointer-type struct member. In both cases, directly accessing the user memory will result verification failure. $ ./test_progs -v -n 22/3 ... libbpf: load bpf program failed: Permission denied libbpf: -- BEGIN DUMP LOG --- libbpf: R1 type=ctx expected=fp ; int BPF_PROG(test_user1, struct bpf_testmod_btf_type_tag_1 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_1' arg0 has btf_id 143948 addr_space 1 type STRUCT 'bpf_testmod_btf_type_tag_1' ; g = arg->a; 1: (61) r1 = *(u32 *)(r1 +0) R1 is ptr_bpf_testmod_btf_type_tag_1 access user memory: off=0 ... #22/3 btf_tag/btf_type_tag_user_1:OK $ ./test_progs -v -n 22/4 ... libbpf: load bpf program failed: Permission denied libbpf: -- BEGIN DUMP LOG --- libbpf: R1 type=ctx expected=fp ; int BPF_PROG(test_user2, struct bpf_testmod_btf_type_tag_2 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_2' arg0 has btf_id 143950 addr_space 0 type STRUCT 'bpf_testmod_btf_type_tag_2' ; g = arg->p->a; 1: (79) r1 = *(u64 *)(r1 +0) ; g = arg->p->a; 2: (61) r1 = *(u32 *)(r1 +0) R1 is ptr_bpf_testmod_btf_type_tag_1 access user memory: off=0 ... #22/4 btf_tag/btf_type_tag_user_2:OK Signed-off-by: Yonghong Song <yhs@fb.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Dec 13, 2021
Added a selftest with two __user usages: a __user pointer-type argument and a __user pointer-type struct member. In both cases, directly accessing the user memory will result verification failure. $ ./test_progs -v -n 22/3 ... libbpf: load bpf program failed: Permission denied libbpf: -- BEGIN DUMP LOG --- libbpf: R1 type=ctx expected=fp ; int BPF_PROG(test_user1, struct bpf_testmod_btf_type_tag_1 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_1' arg0 has btf_id 143948 addr_space 1 type STRUCT 'bpf_testmod_btf_type_tag_1' ; g = arg->a; 1: (61) r1 = *(u32 *)(r1 +0) R1 is ptr_bpf_testmod_btf_type_tag_1 access user memory: off=0 ... #22/3 btf_tag/btf_type_tag_user_1:OK $ ./test_progs -v -n 22/4 ... libbpf: load bpf program failed: Permission denied libbpf: -- BEGIN DUMP LOG --- libbpf: R1 type=ctx expected=fp ; int BPF_PROG(test_user2, struct bpf_testmod_btf_type_tag_2 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_2' arg0 has btf_id 143950 addr_space 0 type STRUCT 'bpf_testmod_btf_type_tag_2' ; g = arg->p->a; 1: (79) r1 = *(u64 *)(r1 +0) ; g = arg->p->a; 2: (61) r1 = *(u32 *)(r1 +0) R1 is ptr_bpf_testmod_btf_type_tag_1 access user memory: off=0 ... #22/4 btf_tag/btf_type_tag_user_2:OK Signed-off-by: Yonghong Song <yhs@fb.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Dec 13, 2021
Added a selftest with two __user usages: a __user pointer-type argument and a __user pointer-type struct member. In both cases, directly accessing the user memory will result verification failure. $ ./test_progs -v -n 22/3 ... libbpf: load bpf program failed: Permission denied libbpf: -- BEGIN DUMP LOG --- libbpf: R1 type=ctx expected=fp ; int BPF_PROG(test_user1, struct bpf_testmod_btf_type_tag_1 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_1' arg0 has btf_id 143948 addr_space 1 type STRUCT 'bpf_testmod_btf_type_tag_1' ; g = arg->a; 1: (61) r1 = *(u32 *)(r1 +0) R1 is ptr_bpf_testmod_btf_type_tag_1 access user memory: off=0 ... #22/3 btf_tag/btf_type_tag_user_1:OK $ ./test_progs -v -n 22/4 ... libbpf: load bpf program failed: Permission denied libbpf: -- BEGIN DUMP LOG --- libbpf: R1 type=ctx expected=fp ; int BPF_PROG(test_user2, struct bpf_testmod_btf_type_tag_2 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_2' arg0 has btf_id 143950 addr_space 0 type STRUCT 'bpf_testmod_btf_type_tag_2' ; g = arg->p->a; 1: (79) r1 = *(u64 *)(r1 +0) ; g = arg->p->a; 2: (61) r1 = *(u32 *)(r1 +0) R1 is ptr_bpf_testmod_btf_type_tag_1 access user memory: off=0 ... #22/4 btf_tag/btf_type_tag_user_2:OK Signed-off-by: Yonghong Song <yhs@fb.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Dec 13, 2021
Added a selftest with two __user usages: a __user pointer-type argument and a __user pointer-type struct member. In both cases, directly accessing the user memory will result verification failure. $ ./test_progs -v -n 22/3 ... libbpf: load bpf program failed: Permission denied libbpf: -- BEGIN DUMP LOG --- libbpf: R1 type=ctx expected=fp ; int BPF_PROG(test_user1, struct bpf_testmod_btf_type_tag_1 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_1' arg0 has btf_id 143948 addr_space 1 type STRUCT 'bpf_testmod_btf_type_tag_1' ; g = arg->a; 1: (61) r1 = *(u32 *)(r1 +0) R1 is ptr_bpf_testmod_btf_type_tag_1 access user memory: off=0 ... #22/3 btf_tag/btf_type_tag_user_1:OK $ ./test_progs -v -n 22/4 ... libbpf: load bpf program failed: Permission denied libbpf: -- BEGIN DUMP LOG --- libbpf: R1 type=ctx expected=fp ; int BPF_PROG(test_user2, struct bpf_testmod_btf_type_tag_2 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_2' arg0 has btf_id 143950 addr_space 0 type STRUCT 'bpf_testmod_btf_type_tag_2' ; g = arg->p->a; 1: (79) r1 = *(u64 *)(r1 +0) ; g = arg->p->a; 2: (61) r1 = *(u32 *)(r1 +0) R1 is ptr_bpf_testmod_btf_type_tag_1 access user memory: off=0 ... #22/4 btf_tag/btf_type_tag_user_2:OK Signed-off-by: Yonghong Song <yhs@fb.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Dec 13, 2021
Added a selftest with two __user usages: a __user pointer-type argument and a __user pointer-type struct member. In both cases, directly accessing the user memory will result verification failure. $ ./test_progs -v -n 22/3 ... libbpf: load bpf program failed: Permission denied libbpf: -- BEGIN DUMP LOG --- libbpf: R1 type=ctx expected=fp ; int BPF_PROG(test_user1, struct bpf_testmod_btf_type_tag_1 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_1' arg0 has btf_id 143948 addr_space 1 type STRUCT 'bpf_testmod_btf_type_tag_1' ; g = arg->a; 1: (61) r1 = *(u32 *)(r1 +0) R1 is ptr_bpf_testmod_btf_type_tag_1 access user memory: off=0 ... #22/3 btf_tag/btf_type_tag_user_1:OK $ ./test_progs -v -n 22/4 ... libbpf: load bpf program failed: Permission denied libbpf: -- BEGIN DUMP LOG --- libbpf: R1 type=ctx expected=fp ; int BPF_PROG(test_user2, struct bpf_testmod_btf_type_tag_2 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_2' arg0 has btf_id 143950 addr_space 0 type STRUCT 'bpf_testmod_btf_type_tag_2' ; g = arg->p->a; 1: (79) r1 = *(u64 *)(r1 +0) ; g = arg->p->a; 2: (61) r1 = *(u32 *)(r1 +0) R1 is ptr_bpf_testmod_btf_type_tag_1 access user memory: off=0 ... #22/4 btf_tag/btf_type_tag_user_2:OK Signed-off-by: Yonghong Song <yhs@fb.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Dec 13, 2021
Added a selftest with two __user usages: a __user pointer-type argument and a __user pointer-type struct member. In both cases, directly accessing the user memory will result verification failure. $ ./test_progs -v -n 22/3 ... libbpf: load bpf program failed: Permission denied libbpf: -- BEGIN DUMP LOG --- libbpf: R1 type=ctx expected=fp ; int BPF_PROG(test_user1, struct bpf_testmod_btf_type_tag_1 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_1' arg0 has btf_id 143948 addr_space 1 type STRUCT 'bpf_testmod_btf_type_tag_1' ; g = arg->a; 1: (61) r1 = *(u32 *)(r1 +0) R1 is ptr_bpf_testmod_btf_type_tag_1 access user memory: off=0 ... #22/3 btf_tag/btf_type_tag_user_1:OK $ ./test_progs -v -n 22/4 ... libbpf: load bpf program failed: Permission denied libbpf: -- BEGIN DUMP LOG --- libbpf: R1 type=ctx expected=fp ; int BPF_PROG(test_user2, struct bpf_testmod_btf_type_tag_2 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_2' arg0 has btf_id 143950 addr_space 0 type STRUCT 'bpf_testmod_btf_type_tag_2' ; g = arg->p->a; 1: (79) r1 = *(u64 *)(r1 +0) ; g = arg->p->a; 2: (61) r1 = *(u32 *)(r1 +0) R1 is ptr_bpf_testmod_btf_type_tag_1 access user memory: off=0 ... #22/4 btf_tag/btf_type_tag_user_2:OK Signed-off-by: Yonghong Song <yhs@fb.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Dec 14, 2021
Added a selftest with two __user usages: a __user pointer-type argument and a __user pointer-type struct member. In both cases, directly accessing the user memory will result verification failure. $ ./test_progs -v -n 22/3 ... libbpf: load bpf program failed: Permission denied libbpf: -- BEGIN DUMP LOG --- libbpf: R1 type=ctx expected=fp ; int BPF_PROG(test_user1, struct bpf_testmod_btf_type_tag_1 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_1' arg0 has btf_id 143948 addr_space 1 type STRUCT 'bpf_testmod_btf_type_tag_1' ; g = arg->a; 1: (61) r1 = *(u32 *)(r1 +0) R1 is ptr_bpf_testmod_btf_type_tag_1 access user memory: off=0 ... #22/3 btf_tag/btf_type_tag_user_1:OK $ ./test_progs -v -n 22/4 ... libbpf: load bpf program failed: Permission denied libbpf: -- BEGIN DUMP LOG --- libbpf: R1 type=ctx expected=fp ; int BPF_PROG(test_user2, struct bpf_testmod_btf_type_tag_2 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_2' arg0 has btf_id 143950 addr_space 0 type STRUCT 'bpf_testmod_btf_type_tag_2' ; g = arg->p->a; 1: (79) r1 = *(u64 *)(r1 +0) ; g = arg->p->a; 2: (61) r1 = *(u32 *)(r1 +0) R1 is ptr_bpf_testmod_btf_type_tag_1 access user memory: off=0 ... #22/4 btf_tag/btf_type_tag_user_2:OK Signed-off-by: Yonghong Song <yhs@fb.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Dec 14, 2021
Added a selftest with two __user usages: a __user pointer-type argument and a __user pointer-type struct member. In both cases, directly accessing the user memory will result verification failure. $ ./test_progs -v -n 22/3 ... libbpf: load bpf program failed: Permission denied libbpf: -- BEGIN DUMP LOG --- libbpf: R1 type=ctx expected=fp ; int BPF_PROG(test_user1, struct bpf_testmod_btf_type_tag_1 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_1' arg0 has btf_id 143948 addr_space 1 type STRUCT 'bpf_testmod_btf_type_tag_1' ; g = arg->a; 1: (61) r1 = *(u32 *)(r1 +0) R1 is ptr_bpf_testmod_btf_type_tag_1 access user memory: off=0 ... #22/3 btf_tag/btf_type_tag_user_1:OK $ ./test_progs -v -n 22/4 ... libbpf: load bpf program failed: Permission denied libbpf: -- BEGIN DUMP LOG --- libbpf: R1 type=ctx expected=fp ; int BPF_PROG(test_user2, struct bpf_testmod_btf_type_tag_2 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_2' arg0 has btf_id 143950 addr_space 0 type STRUCT 'bpf_testmod_btf_type_tag_2' ; g = arg->p->a; 1: (79) r1 = *(u64 *)(r1 +0) ; g = arg->p->a; 2: (61) r1 = *(u32 *)(r1 +0) R1 is ptr_bpf_testmod_btf_type_tag_1 access user memory: off=0 ... #22/4 btf_tag/btf_type_tag_user_2:OK Signed-off-by: Yonghong Song <yhs@fb.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Dec 14, 2021
Added a selftest with two __user usages: a __user pointer-type argument and a __user pointer-type struct member. In both cases, directly accessing the user memory will result verification failure. $ ./test_progs -v -n 22/3 ... libbpf: load bpf program failed: Permission denied libbpf: -- BEGIN DUMP LOG --- libbpf: R1 type=ctx expected=fp ; int BPF_PROG(test_user1, struct bpf_testmod_btf_type_tag_1 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_1' arg0 has btf_id 143948 addr_space 1 type STRUCT 'bpf_testmod_btf_type_tag_1' ; g = arg->a; 1: (61) r1 = *(u32 *)(r1 +0) R1 is ptr_bpf_testmod_btf_type_tag_1 access user memory: off=0 ... #22/3 btf_tag/btf_type_tag_user_1:OK $ ./test_progs -v -n 22/4 ... libbpf: load bpf program failed: Permission denied libbpf: -- BEGIN DUMP LOG --- libbpf: R1 type=ctx expected=fp ; int BPF_PROG(test_user2, struct bpf_testmod_btf_type_tag_2 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_2' arg0 has btf_id 143950 addr_space 0 type STRUCT 'bpf_testmod_btf_type_tag_2' ; g = arg->p->a; 1: (79) r1 = *(u64 *)(r1 +0) ; g = arg->p->a; 2: (61) r1 = *(u32 *)(r1 +0) R1 is ptr_bpf_testmod_btf_type_tag_1 access user memory: off=0 ... #22/4 btf_tag/btf_type_tag_user_2:OK Signed-off-by: Yonghong Song <yhs@fb.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Dec 14, 2021
Added a selftest with two __user usages: a __user pointer-type argument and a __user pointer-type struct member. In both cases, directly accessing the user memory will result verification failure. $ ./test_progs -v -n 22/3 ... libbpf: load bpf program failed: Permission denied libbpf: -- BEGIN DUMP LOG --- libbpf: R1 type=ctx expected=fp ; int BPF_PROG(test_user1, struct bpf_testmod_btf_type_tag_1 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_1' arg0 has btf_id 143948 addr_space 1 type STRUCT 'bpf_testmod_btf_type_tag_1' ; g = arg->a; 1: (61) r1 = *(u32 *)(r1 +0) R1 is ptr_bpf_testmod_btf_type_tag_1 access user memory: off=0 ... #22/3 btf_tag/btf_type_tag_user_1:OK $ ./test_progs -v -n 22/4 ... libbpf: load bpf program failed: Permission denied libbpf: -- BEGIN DUMP LOG --- libbpf: R1 type=ctx expected=fp ; int BPF_PROG(test_user2, struct bpf_testmod_btf_type_tag_2 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_2' arg0 has btf_id 143950 addr_space 0 type STRUCT 'bpf_testmod_btf_type_tag_2' ; g = arg->p->a; 1: (79) r1 = *(u64 *)(r1 +0) ; g = arg->p->a; 2: (61) r1 = *(u32 *)(r1 +0) R1 is ptr_bpf_testmod_btf_type_tag_1 access user memory: off=0 ... #22/4 btf_tag/btf_type_tag_user_2:OK Signed-off-by: Yonghong Song <yhs@fb.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Dec 15, 2021
Added a selftest with two __user usages: a __user pointer-type argument and a __user pointer-type struct member. In both cases, directly accessing the user memory will result verification failure. $ ./test_progs -v -n 22/3 ... libbpf: load bpf program failed: Permission denied libbpf: -- BEGIN DUMP LOG --- libbpf: R1 type=ctx expected=fp ; int BPF_PROG(test_user1, struct bpf_testmod_btf_type_tag_1 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_1' arg0 has btf_id 143948 addr_space 1 type STRUCT 'bpf_testmod_btf_type_tag_1' ; g = arg->a; 1: (61) r1 = *(u32 *)(r1 +0) R1 is ptr_bpf_testmod_btf_type_tag_1 access user memory: off=0 ... #22/3 btf_tag/btf_type_tag_user_1:OK $ ./test_progs -v -n 22/4 ... libbpf: load bpf program failed: Permission denied libbpf: -- BEGIN DUMP LOG --- libbpf: R1 type=ctx expected=fp ; int BPF_PROG(test_user2, struct bpf_testmod_btf_type_tag_2 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_2' arg0 has btf_id 143950 addr_space 0 type STRUCT 'bpf_testmod_btf_type_tag_2' ; g = arg->p->a; 1: (79) r1 = *(u64 *)(r1 +0) ; g = arg->p->a; 2: (61) r1 = *(u32 *)(r1 +0) R1 is ptr_bpf_testmod_btf_type_tag_1 access user memory: off=0 ... #22/4 btf_tag/btf_type_tag_user_2:OK Signed-off-by: Yonghong Song <yhs@fb.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Dec 16, 2021
Added a selftest with two __user usages: a __user pointer-type argument and a __user pointer-type struct member. In both cases, directly accessing the user memory will result verification failure. $ ./test_progs -v -n 22/3 ... libbpf: load bpf program failed: Permission denied libbpf: -- BEGIN DUMP LOG --- libbpf: R1 type=ctx expected=fp ; int BPF_PROG(test_user1, struct bpf_testmod_btf_type_tag_1 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_1' arg0 has btf_id 143948 addr_space 1 type STRUCT 'bpf_testmod_btf_type_tag_1' ; g = arg->a; 1: (61) r1 = *(u32 *)(r1 +0) R1 is ptr_bpf_testmod_btf_type_tag_1 access user memory: off=0 ... #22/3 btf_tag/btf_type_tag_user_1:OK $ ./test_progs -v -n 22/4 ... libbpf: load bpf program failed: Permission denied libbpf: -- BEGIN DUMP LOG --- libbpf: R1 type=ctx expected=fp ; int BPF_PROG(test_user2, struct bpf_testmod_btf_type_tag_2 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_2' arg0 has btf_id 143950 addr_space 0 type STRUCT 'bpf_testmod_btf_type_tag_2' ; g = arg->p->a; 1: (79) r1 = *(u64 *)(r1 +0) ; g = arg->p->a; 2: (61) r1 = *(u32 *)(r1 +0) R1 is ptr_bpf_testmod_btf_type_tag_1 access user memory: off=0 ... #22/4 btf_tag/btf_type_tag_user_2:OK Signed-off-by: Yonghong Song <yhs@fb.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Dec 16, 2021
Added a selftest with two __user usages: a __user pointer-type argument and a __user pointer-type struct member. In both cases, directly accessing the user memory will result verification failure. $ ./test_progs -v -n 22/3 ... libbpf: load bpf program failed: Permission denied libbpf: -- BEGIN DUMP LOG --- libbpf: R1 type=ctx expected=fp ; int BPF_PROG(test_user1, struct bpf_testmod_btf_type_tag_1 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_1' arg0 has btf_id 143948 addr_space 1 type STRUCT 'bpf_testmod_btf_type_tag_1' ; g = arg->a; 1: (61) r1 = *(u32 *)(r1 +0) R1 is ptr_bpf_testmod_btf_type_tag_1 access user memory: off=0 ... #22/3 btf_tag/btf_type_tag_user_1:OK $ ./test_progs -v -n 22/4 ... libbpf: load bpf program failed: Permission denied libbpf: -- BEGIN DUMP LOG --- libbpf: R1 type=ctx expected=fp ; int BPF_PROG(test_user2, struct bpf_testmod_btf_type_tag_2 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_2' arg0 has btf_id 143950 addr_space 0 type STRUCT 'bpf_testmod_btf_type_tag_2' ; g = arg->p->a; 1: (79) r1 = *(u64 *)(r1 +0) ; g = arg->p->a; 2: (61) r1 = *(u32 *)(r1 +0) R1 is ptr_bpf_testmod_btf_type_tag_1 access user memory: off=0 ... #22/4 btf_tag/btf_type_tag_user_2:OK Signed-off-by: Yonghong Song <yhs@fb.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Dec 16, 2021
Added a selftest with two __user usages: a __user pointer-type argument and a __user pointer-type struct member. In both cases, directly accessing the user memory will result verification failure. $ ./test_progs -v -n 22/3 ... libbpf: load bpf program failed: Permission denied libbpf: -- BEGIN DUMP LOG --- libbpf: R1 type=ctx expected=fp ; int BPF_PROG(test_user1, struct bpf_testmod_btf_type_tag_1 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_1' arg0 has btf_id 143948 addr_space 1 type STRUCT 'bpf_testmod_btf_type_tag_1' ; g = arg->a; 1: (61) r1 = *(u32 *)(r1 +0) R1 is ptr_bpf_testmod_btf_type_tag_1 access user memory: off=0 ... #22/3 btf_tag/btf_type_tag_user_1:OK $ ./test_progs -v -n 22/4 ... libbpf: load bpf program failed: Permission denied libbpf: -- BEGIN DUMP LOG --- libbpf: R1 type=ctx expected=fp ; int BPF_PROG(test_user2, struct bpf_testmod_btf_type_tag_2 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_2' arg0 has btf_id 143950 addr_space 0 type STRUCT 'bpf_testmod_btf_type_tag_2' ; g = arg->p->a; 1: (79) r1 = *(u64 *)(r1 +0) ; g = arg->p->a; 2: (61) r1 = *(u32 *)(r1 +0) R1 is ptr_bpf_testmod_btf_type_tag_1 access user memory: off=0 ... #22/4 btf_tag/btf_type_tag_user_2:OK Signed-off-by: Yonghong Song <yhs@fb.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Dec 17, 2021
Added a selftest with two __user usages: a __user pointer-type argument and a __user pointer-type struct member. In both cases, directly accessing the user memory will result verification failure. $ ./test_progs -v -n 22/3 ... libbpf: load bpf program failed: Permission denied libbpf: -- BEGIN DUMP LOG --- libbpf: R1 type=ctx expected=fp ; int BPF_PROG(test_user1, struct bpf_testmod_btf_type_tag_1 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_1' arg0 has btf_id 143948 addr_space 1 type STRUCT 'bpf_testmod_btf_type_tag_1' ; g = arg->a; 1: (61) r1 = *(u32 *)(r1 +0) R1 is ptr_bpf_testmod_btf_type_tag_1 access user memory: off=0 ... #22/3 btf_tag/btf_type_tag_user_1:OK $ ./test_progs -v -n 22/4 ... libbpf: load bpf program failed: Permission denied libbpf: -- BEGIN DUMP LOG --- libbpf: R1 type=ctx expected=fp ; int BPF_PROG(test_user2, struct bpf_testmod_btf_type_tag_2 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_2' arg0 has btf_id 143950 addr_space 0 type STRUCT 'bpf_testmod_btf_type_tag_2' ; g = arg->p->a; 1: (79) r1 = *(u64 *)(r1 +0) ; g = arg->p->a; 2: (61) r1 = *(u32 *)(r1 +0) R1 is ptr_bpf_testmod_btf_type_tag_1 access user memory: off=0 ... #22/4 btf_tag/btf_type_tag_user_2:OK Signed-off-by: Yonghong Song <yhs@fb.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Dec 17, 2021
Added a selftest with two __user usages: a __user pointer-type argument and a __user pointer-type struct member. In both cases, directly accessing the user memory will result verification failure. $ ./test_progs -v -n 22/3 ... libbpf: load bpf program failed: Permission denied libbpf: -- BEGIN DUMP LOG --- libbpf: R1 type=ctx expected=fp ; int BPF_PROG(test_user1, struct bpf_testmod_btf_type_tag_1 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_1' arg0 has btf_id 143948 addr_space 1 type STRUCT 'bpf_testmod_btf_type_tag_1' ; g = arg->a; 1: (61) r1 = *(u32 *)(r1 +0) R1 is ptr_bpf_testmod_btf_type_tag_1 access user memory: off=0 ... #22/3 btf_tag/btf_type_tag_user_1:OK $ ./test_progs -v -n 22/4 ... libbpf: load bpf program failed: Permission denied libbpf: -- BEGIN DUMP LOG --- libbpf: R1 type=ctx expected=fp ; int BPF_PROG(test_user2, struct bpf_testmod_btf_type_tag_2 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_2' arg0 has btf_id 143950 addr_space 0 type STRUCT 'bpf_testmod_btf_type_tag_2' ; g = arg->p->a; 1: (79) r1 = *(u64 *)(r1 +0) ; g = arg->p->a; 2: (61) r1 = *(u32 *)(r1 +0) R1 is ptr_bpf_testmod_btf_type_tag_1 access user memory: off=0 ... #22/4 btf_tag/btf_type_tag_user_2:OK Signed-off-by: Yonghong Song <yhs@fb.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Jan 1, 2022
…port_id() The array param[] in elantech_change_report_id() must be at least 3 bytes, because elantech_read_reg_params() is calling ps2_command() with PSMOUSE_CMD_GETINFO, that is going to access 3 bytes from param[], but it's defined in the stack as an array of 2 bytes, therefore we have a potential stack out-of-bounds access here, also confirmed by KASAN: [ 6.512374] BUG: KASAN: stack-out-of-bounds in __ps2_command+0x372/0x7e0 [ 6.512397] Read of size 1 at addr ffff8881024d77c2 by task kworker/2:1/118 [ 6.512416] CPU: 2 PID: 118 Comm: kworker/2:1 Not tainted 5.13.0-22-generic #22+arighi20211110 [ 6.512428] Hardware name: LENOVO 20T8000QGE/20T8000QGE, BIOS R1AET32W (1.08 ) 08/14/2020 [ 6.512436] Workqueue: events_long serio_handle_event [ 6.512453] Call Trace: [ 6.512462] show_stack+0x52/0x58 [ 6.512474] dump_stack+0xa1/0xd3 [ 6.512487] print_address_description.constprop.0+0x1d/0x140 [ 6.512502] ? __ps2_command+0x372/0x7e0 [ 6.512516] __kasan_report.cold+0x7d/0x112 [ 6.512527] ? _raw_write_lock_irq+0x20/0xd0 [ 6.512539] ? __ps2_command+0x372/0x7e0 [ 6.512552] kasan_report+0x3c/0x50 [ 6.512564] __asan_load1+0x6a/0x70 [ 6.512575] __ps2_command+0x372/0x7e0 [ 6.512589] ? ps2_drain+0x240/0x240 [ 6.512601] ? dev_printk_emit+0xa2/0xd3 [ 6.512612] ? dev_vprintk_emit+0xc5/0xc5 [ 6.512621] ? __kasan_check_write+0x14/0x20 [ 6.512634] ? mutex_lock+0x8f/0xe0 [ 6.512643] ? __mutex_lock_slowpath+0x20/0x20 [ 6.512655] ps2_command+0x52/0x90 [ 6.512670] elantech_ps2_command+0x4f/0xc0 [psmouse] [ 6.512734] elantech_change_report_id+0x1e6/0x256 [psmouse] [ 6.512799] ? elantech_report_trackpoint.constprop.0.cold+0xd/0xd [psmouse] [ 6.512863] ? ps2_command+0x7f/0x90 [ 6.512877] elantech_query_info.cold+0x6bd/0x9ed [psmouse] [ 6.512943] ? elantech_setup_ps2+0x460/0x460 [psmouse] [ 6.513005] ? psmouse_reset+0x69/0xb0 [psmouse] [ 6.513064] ? psmouse_attr_set_helper+0x2a0/0x2a0 [psmouse] [ 6.513122] ? phys_pmd_init+0x30e/0x521 [ 6.513137] elantech_init+0x8a/0x200 [psmouse] [ 6.513200] ? elantech_init_ps2+0xf0/0xf0 [psmouse] [ 6.513249] ? elantech_query_info+0x440/0x440 [psmouse] [ 6.513296] ? synaptics_send_cmd+0x60/0x60 [psmouse] [ 6.513342] ? elantech_query_info+0x440/0x440 [psmouse] [ 6.513388] ? psmouse_try_protocol+0x11e/0x170 [psmouse] [ 6.513432] psmouse_extensions+0x65d/0x6e0 [psmouse] [ 6.513476] ? psmouse_try_protocol+0x170/0x170 [psmouse] [ 6.513519] ? mutex_unlock+0x22/0x40 [ 6.513526] ? ps2_command+0x7f/0x90 [ 6.513536] ? psmouse_probe+0xa3/0xf0 [psmouse] [ 6.513580] psmouse_switch_protocol+0x27d/0x2e0 [psmouse] [ 6.513624] psmouse_connect+0x272/0x530 [psmouse] [ 6.513669] serio_driver_probe+0x55/0x70 [ 6.513679] really_probe+0x190/0x720 [ 6.513689] driver_probe_device+0x160/0x1f0 [ 6.513697] device_driver_attach+0x119/0x130 [ 6.513705] ? device_driver_attach+0x130/0x130 [ 6.513713] __driver_attach+0xe7/0x1a0 [ 6.513720] ? device_driver_attach+0x130/0x130 [ 6.513728] bus_for_each_dev+0xfb/0x150 [ 6.513738] ? subsys_dev_iter_exit+0x10/0x10 [ 6.513748] ? _raw_write_unlock_bh+0x30/0x30 [ 6.513757] driver_attach+0x2d/0x40 [ 6.513764] serio_handle_event+0x199/0x3d0 [ 6.513775] process_one_work+0x471/0x740 [ 6.513785] worker_thread+0x2d2/0x790 [ 6.513794] ? process_one_work+0x740/0x740 [ 6.513802] kthread+0x1b4/0x1e0 [ 6.513809] ? set_kthread_struct+0x80/0x80 [ 6.513816] ret_from_fork+0x22/0x30 [ 6.513832] The buggy address belongs to the page: [ 6.513838] page:00000000bc35e189 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1024d7 [ 6.513847] flags: 0x17ffffc0000000(node=0|zone=2|lastcpupid=0x1fffff) [ 6.513860] raw: 0017ffffc0000000 dead000000000100 dead000000000122 0000000000000000 [ 6.513867] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 [ 6.513872] page dumped because: kasan: bad access detected [ 6.513879] addr ffff8881024d77c2 is located in stack of task kworker/2:1/118 at offset 34 in frame: [ 6.513887] elantech_change_report_id+0x0/0x256 [psmouse] [ 6.513941] this frame has 1 object: [ 6.513947] [32, 34) 'param' [ 6.513956] Memory state around the buggy address: [ 6.513962] ffff8881024d7680: f2 f2 f2 f2 f2 00 00 f3 f3 00 00 00 00 00 00 00 [ 6.513969] ffff8881024d7700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 6.513976] >ffff8881024d7780: 00 00 00 00 f1 f1 f1 f1 02 f3 f3 f3 00 00 00 00 [ 6.513982] ^ [ 6.513988] ffff8881024d7800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 6.513995] ffff8881024d7880: 00 f1 f1 f1 f1 03 f2 03 f2 03 f3 f3 f3 00 00 00 [ 6.514000] ================================================================== Define param[] in elantech_change_report_id() as an array of 3 bytes to prevent the out-of-bounds access in the stack. Fixes: e4c9062 ("Input: elantech - fix protocol errors for some trackpoints in SMBus mode") BugLink: https://bugs.launchpad.net/bugs/1945590 Signed-off-by: Andrea Righi <andrea.righi@canonical.com> Reviewed-by: Wolfram Sang <wsa@kernel.org> Link: https://lore.kernel.org/r/20211116095559.24395-1-andrea.righi@canonical.com Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Jan 12, 2022
Added a selftest with three__user usages: a __user pointer-type argument in bpf_testmod, a __user pointer-type struct member in bpf_testmod, and a __user pointer-type struct member in vmlinux. In all cases, directly accessing the user memory will result verification failure. $ ./test_progs -v -n 22/3 ... libbpf: prog 'test_user1': BPF program load failed: Permission denied libbpf: prog 'test_user1': -- BEGIN PROG LOAD LOG -- R1 type=ctx expected=fp 0: R1=ctx(id=0,off=0,imm=0) R10=fp0 ; int BPF_PROG(test_user1, struct bpf_testmod_btf_type_tag_1 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_1' arg0 has btf_id 136561 type STRUCT 'bpf_testmod_btf_type_tag_1' 1: R1_w=user_ptr_bpf_testmod_btf_type_tag_1(id=0,off=0,imm=0) ; g = arg->a; 1: (61) r1 = *(u32 *)(r1 +0) R1 invalid mem access 'user_ptr_' ... #22/3 btf_tag/btf_type_tag_user_mod1:OK $ ./test_progs -v -n 22/4 ... libbpf: prog 'test_user2': BPF program load failed: Permission denied libbpf: prog 'test_user2': -- BEGIN PROG LOAD LOG -- R1 type=ctx expected=fp 0: R1=ctx(id=0,off=0,imm=0) R10=fp0 ; int BPF_PROG(test_user2, struct bpf_testmod_btf_type_tag_2 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_2' arg0 has btf_id 136563 type STRUCT 'bpf_testmod_btf_type_tag_2' 1: R1_w=ptr_bpf_testmod_btf_type_tag_2(id=0,off=0,imm=0) ; g = arg->p->a; 1: (79) r1 = *(u64 *)(r1 +0) ; R1_w=user_ptr_bpf_testmod_btf_type_tag_1(id=0,off=0,imm=0) ; g = arg->p->a; 2: (61) r1 = *(u32 *)(r1 +0) R1 invalid mem access 'user_ptr_' ... #22/4 btf_tag/btf_type_tag_user_mod2:OK $ ./test_progs -v -n 22/5 ... libbpf: prog 'test_sys_getsockname': BPF program load failed: Permission denied libbpf: prog 'test_sys_getsockname': -- BEGIN PROG LOAD LOG -- R1 type=ctx expected=fp 0: R1=ctx(id=0,off=0,imm=0) R10=fp0 ; int BPF_PROG(test_sys_getsockname, int fd, struct sockaddr *usockaddr, 0: (79) r1 = *(u64 *)(r1 +8) func '__sys_getsockname' arg1 has btf_id 2319 type STRUCT 'sockaddr' 1: R1_w=user_ptr_sockaddr(id=0,off=0,imm=0) ; g = usockaddr->sa_family; 1: (69) r1 = *(u16 *)(r1 +0) R1 invalid mem access 'user_ptr_' ... #22/5 btf_tag/btf_type_tag_user_vmlinux:OK Signed-off-by: Yonghong Song <yhs@fb.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Jan 13, 2022
Added a selftest with three__user usages: a __user pointer-type argument in bpf_testmod, a __user pointer-type struct member in bpf_testmod, and a __user pointer-type struct member in vmlinux. In all cases, directly accessing the user memory will result verification failure. $ ./test_progs -v -n 22/3 ... libbpf: prog 'test_user1': BPF program load failed: Permission denied libbpf: prog 'test_user1': -- BEGIN PROG LOAD LOG -- R1 type=ctx expected=fp 0: R1=ctx(id=0,off=0,imm=0) R10=fp0 ; int BPF_PROG(test_user1, struct bpf_testmod_btf_type_tag_1 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_1' arg0 has btf_id 136561 type STRUCT 'bpf_testmod_btf_type_tag_1' 1: R1_w=user_ptr_bpf_testmod_btf_type_tag_1(id=0,off=0,imm=0) ; g = arg->a; 1: (61) r1 = *(u32 *)(r1 +0) R1 invalid mem access 'user_ptr_' ... #22/3 btf_tag/btf_type_tag_user_mod1:OK $ ./test_progs -v -n 22/4 ... libbpf: prog 'test_user2': BPF program load failed: Permission denied libbpf: prog 'test_user2': -- BEGIN PROG LOAD LOG -- R1 type=ctx expected=fp 0: R1=ctx(id=0,off=0,imm=0) R10=fp0 ; int BPF_PROG(test_user2, struct bpf_testmod_btf_type_tag_2 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_2' arg0 has btf_id 136563 type STRUCT 'bpf_testmod_btf_type_tag_2' 1: R1_w=ptr_bpf_testmod_btf_type_tag_2(id=0,off=0,imm=0) ; g = arg->p->a; 1: (79) r1 = *(u64 *)(r1 +0) ; R1_w=user_ptr_bpf_testmod_btf_type_tag_1(id=0,off=0,imm=0) ; g = arg->p->a; 2: (61) r1 = *(u32 *)(r1 +0) R1 invalid mem access 'user_ptr_' ... #22/4 btf_tag/btf_type_tag_user_mod2:OK $ ./test_progs -v -n 22/5 ... libbpf: prog 'test_sys_getsockname': BPF program load failed: Permission denied libbpf: prog 'test_sys_getsockname': -- BEGIN PROG LOAD LOG -- R1 type=ctx expected=fp 0: R1=ctx(id=0,off=0,imm=0) R10=fp0 ; int BPF_PROG(test_sys_getsockname, int fd, struct sockaddr *usockaddr, 0: (79) r1 = *(u64 *)(r1 +8) func '__sys_getsockname' arg1 has btf_id 2319 type STRUCT 'sockaddr' 1: R1_w=user_ptr_sockaddr(id=0,off=0,imm=0) ; g = usockaddr->sa_family; 1: (69) r1 = *(u16 *)(r1 +0) R1 invalid mem access 'user_ptr_' ... #22/5 btf_tag/btf_type_tag_user_vmlinux:OK Signed-off-by: Yonghong Song <yhs@fb.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Jan 15, 2022
Added a selftest with three__user usages: a __user pointer-type argument in bpf_testmod, a __user pointer-type struct member in bpf_testmod, and a __user pointer-type struct member in vmlinux. In all cases, directly accessing the user memory will result verification failure. $ ./test_progs -v -n 22/3 ... libbpf: prog 'test_user1': BPF program load failed: Permission denied libbpf: prog 'test_user1': -- BEGIN PROG LOAD LOG -- R1 type=ctx expected=fp 0: R1=ctx(id=0,off=0,imm=0) R10=fp0 ; int BPF_PROG(test_user1, struct bpf_testmod_btf_type_tag_1 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_1' arg0 has btf_id 136561 type STRUCT 'bpf_testmod_btf_type_tag_1' 1: R1_w=user_ptr_bpf_testmod_btf_type_tag_1(id=0,off=0,imm=0) ; g = arg->a; 1: (61) r1 = *(u32 *)(r1 +0) R1 invalid mem access 'user_ptr_' ... #22/3 btf_tag/btf_type_tag_user_mod1:OK $ ./test_progs -v -n 22/4 ... libbpf: prog 'test_user2': BPF program load failed: Permission denied libbpf: prog 'test_user2': -- BEGIN PROG LOAD LOG -- R1 type=ctx expected=fp 0: R1=ctx(id=0,off=0,imm=0) R10=fp0 ; int BPF_PROG(test_user2, struct bpf_testmod_btf_type_tag_2 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_2' arg0 has btf_id 136563 type STRUCT 'bpf_testmod_btf_type_tag_2' 1: R1_w=ptr_bpf_testmod_btf_type_tag_2(id=0,off=0,imm=0) ; g = arg->p->a; 1: (79) r1 = *(u64 *)(r1 +0) ; R1_w=user_ptr_bpf_testmod_btf_type_tag_1(id=0,off=0,imm=0) ; g = arg->p->a; 2: (61) r1 = *(u32 *)(r1 +0) R1 invalid mem access 'user_ptr_' ... #22/4 btf_tag/btf_type_tag_user_mod2:OK $ ./test_progs -v -n 22/5 ... libbpf: prog 'test_sys_getsockname': BPF program load failed: Permission denied libbpf: prog 'test_sys_getsockname': -- BEGIN PROG LOAD LOG -- R1 type=ctx expected=fp 0: R1=ctx(id=0,off=0,imm=0) R10=fp0 ; int BPF_PROG(test_sys_getsockname, int fd, struct sockaddr *usockaddr, 0: (79) r1 = *(u64 *)(r1 +8) func '__sys_getsockname' arg1 has btf_id 2319 type STRUCT 'sockaddr' 1: R1_w=user_ptr_sockaddr(id=0,off=0,imm=0) ; g = usockaddr->sa_family; 1: (69) r1 = *(u16 *)(r1 +0) R1 invalid mem access 'user_ptr_' ... #22/5 btf_tag/btf_type_tag_user_vmlinux:OK Signed-off-by: Yonghong Song <yhs@fb.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Jan 15, 2022
Added a selftest with three__user usages: a __user pointer-type argument in bpf_testmod, a __user pointer-type struct member in bpf_testmod, and a __user pointer-type struct member in vmlinux. In all cases, directly accessing the user memory will result verification failure. $ ./test_progs -v -n 22/3 ... libbpf: prog 'test_user1': BPF program load failed: Permission denied libbpf: prog 'test_user1': -- BEGIN PROG LOAD LOG -- R1 type=ctx expected=fp 0: R1=ctx(id=0,off=0,imm=0) R10=fp0 ; int BPF_PROG(test_user1, struct bpf_testmod_btf_type_tag_1 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_1' arg0 has btf_id 136561 type STRUCT 'bpf_testmod_btf_type_tag_1' 1: R1_w=user_ptr_bpf_testmod_btf_type_tag_1(id=0,off=0,imm=0) ; g = arg->a; 1: (61) r1 = *(u32 *)(r1 +0) R1 invalid mem access 'user_ptr_' ... #22/3 btf_tag/btf_type_tag_user_mod1:OK $ ./test_progs -v -n 22/4 ... libbpf: prog 'test_user2': BPF program load failed: Permission denied libbpf: prog 'test_user2': -- BEGIN PROG LOAD LOG -- R1 type=ctx expected=fp 0: R1=ctx(id=0,off=0,imm=0) R10=fp0 ; int BPF_PROG(test_user2, struct bpf_testmod_btf_type_tag_2 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_2' arg0 has btf_id 136563 type STRUCT 'bpf_testmod_btf_type_tag_2' 1: R1_w=ptr_bpf_testmod_btf_type_tag_2(id=0,off=0,imm=0) ; g = arg->p->a; 1: (79) r1 = *(u64 *)(r1 +0) ; R1_w=user_ptr_bpf_testmod_btf_type_tag_1(id=0,off=0,imm=0) ; g = arg->p->a; 2: (61) r1 = *(u32 *)(r1 +0) R1 invalid mem access 'user_ptr_' ... #22/4 btf_tag/btf_type_tag_user_mod2:OK $ ./test_progs -v -n 22/5 ... libbpf: prog 'test_sys_getsockname': BPF program load failed: Permission denied libbpf: prog 'test_sys_getsockname': -- BEGIN PROG LOAD LOG -- R1 type=ctx expected=fp 0: R1=ctx(id=0,off=0,imm=0) R10=fp0 ; int BPF_PROG(test_sys_getsockname, int fd, struct sockaddr *usockaddr, 0: (79) r1 = *(u64 *)(r1 +8) func '__sys_getsockname' arg1 has btf_id 2319 type STRUCT 'sockaddr' 1: R1_w=user_ptr_sockaddr(id=0,off=0,imm=0) ; g = usockaddr->sa_family; 1: (69) r1 = *(u16 *)(r1 +0) R1 invalid mem access 'user_ptr_' ... #22/5 btf_tag/btf_type_tag_user_vmlinux:OK Signed-off-by: Yonghong Song <yhs@fb.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Jan 15, 2022
Added a selftest with three__user usages: a __user pointer-type argument in bpf_testmod, a __user pointer-type struct member in bpf_testmod, and a __user pointer-type struct member in vmlinux. In all cases, directly accessing the user memory will result verification failure. $ ./test_progs -v -n 22/3 ... libbpf: prog 'test_user1': BPF program load failed: Permission denied libbpf: prog 'test_user1': -- BEGIN PROG LOAD LOG -- R1 type=ctx expected=fp 0: R1=ctx(id=0,off=0,imm=0) R10=fp0 ; int BPF_PROG(test_user1, struct bpf_testmod_btf_type_tag_1 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_1' arg0 has btf_id 136561 type STRUCT 'bpf_testmod_btf_type_tag_1' 1: R1_w=user_ptr_bpf_testmod_btf_type_tag_1(id=0,off=0,imm=0) ; g = arg->a; 1: (61) r1 = *(u32 *)(r1 +0) R1 invalid mem access 'user_ptr_' ... #22/3 btf_tag/btf_type_tag_user_mod1:OK $ ./test_progs -v -n 22/4 ... libbpf: prog 'test_user2': BPF program load failed: Permission denied libbpf: prog 'test_user2': -- BEGIN PROG LOAD LOG -- R1 type=ctx expected=fp 0: R1=ctx(id=0,off=0,imm=0) R10=fp0 ; int BPF_PROG(test_user2, struct bpf_testmod_btf_type_tag_2 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_2' arg0 has btf_id 136563 type STRUCT 'bpf_testmod_btf_type_tag_2' 1: R1_w=ptr_bpf_testmod_btf_type_tag_2(id=0,off=0,imm=0) ; g = arg->p->a; 1: (79) r1 = *(u64 *)(r1 +0) ; R1_w=user_ptr_bpf_testmod_btf_type_tag_1(id=0,off=0,imm=0) ; g = arg->p->a; 2: (61) r1 = *(u32 *)(r1 +0) R1 invalid mem access 'user_ptr_' ... #22/4 btf_tag/btf_type_tag_user_mod2:OK $ ./test_progs -v -n 22/5 ... libbpf: prog 'test_sys_getsockname': BPF program load failed: Permission denied libbpf: prog 'test_sys_getsockname': -- BEGIN PROG LOAD LOG -- R1 type=ctx expected=fp 0: R1=ctx(id=0,off=0,imm=0) R10=fp0 ; int BPF_PROG(test_sys_getsockname, int fd, struct sockaddr *usockaddr, 0: (79) r1 = *(u64 *)(r1 +8) func '__sys_getsockname' arg1 has btf_id 2319 type STRUCT 'sockaddr' 1: R1_w=user_ptr_sockaddr(id=0,off=0,imm=0) ; g = usockaddr->sa_family; 1: (69) r1 = *(u16 *)(r1 +0) R1 invalid mem access 'user_ptr_' ... #22/5 btf_tag/btf_type_tag_user_vmlinux:OK Signed-off-by: Yonghong Song <yhs@fb.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Jan 15, 2022
Added a selftest with three__user usages: a __user pointer-type argument in bpf_testmod, a __user pointer-type struct member in bpf_testmod, and a __user pointer-type struct member in vmlinux. In all cases, directly accessing the user memory will result verification failure. $ ./test_progs -v -n 22/3 ... libbpf: prog 'test_user1': BPF program load failed: Permission denied libbpf: prog 'test_user1': -- BEGIN PROG LOAD LOG -- R1 type=ctx expected=fp 0: R1=ctx(id=0,off=0,imm=0) R10=fp0 ; int BPF_PROG(test_user1, struct bpf_testmod_btf_type_tag_1 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_1' arg0 has btf_id 136561 type STRUCT 'bpf_testmod_btf_type_tag_1' 1: R1_w=user_ptr_bpf_testmod_btf_type_tag_1(id=0,off=0,imm=0) ; g = arg->a; 1: (61) r1 = *(u32 *)(r1 +0) R1 invalid mem access 'user_ptr_' ... #22/3 btf_tag/btf_type_tag_user_mod1:OK $ ./test_progs -v -n 22/4 ... libbpf: prog 'test_user2': BPF program load failed: Permission denied libbpf: prog 'test_user2': -- BEGIN PROG LOAD LOG -- R1 type=ctx expected=fp 0: R1=ctx(id=0,off=0,imm=0) R10=fp0 ; int BPF_PROG(test_user2, struct bpf_testmod_btf_type_tag_2 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_2' arg0 has btf_id 136563 type STRUCT 'bpf_testmod_btf_type_tag_2' 1: R1_w=ptr_bpf_testmod_btf_type_tag_2(id=0,off=0,imm=0) ; g = arg->p->a; 1: (79) r1 = *(u64 *)(r1 +0) ; R1_w=user_ptr_bpf_testmod_btf_type_tag_1(id=0,off=0,imm=0) ; g = arg->p->a; 2: (61) r1 = *(u32 *)(r1 +0) R1 invalid mem access 'user_ptr_' ... #22/4 btf_tag/btf_type_tag_user_mod2:OK $ ./test_progs -v -n 22/5 ... libbpf: prog 'test_sys_getsockname': BPF program load failed: Permission denied libbpf: prog 'test_sys_getsockname': -- BEGIN PROG LOAD LOG -- R1 type=ctx expected=fp 0: R1=ctx(id=0,off=0,imm=0) R10=fp0 ; int BPF_PROG(test_sys_getsockname, int fd, struct sockaddr *usockaddr, 0: (79) r1 = *(u64 *)(r1 +8) func '__sys_getsockname' arg1 has btf_id 2319 type STRUCT 'sockaddr' 1: R1_w=user_ptr_sockaddr(id=0,off=0,imm=0) ; g = usockaddr->sa_family; 1: (69) r1 = *(u16 *)(r1 +0) R1 invalid mem access 'user_ptr_' ... #22/5 btf_tag/btf_type_tag_user_vmlinux:OK Signed-off-by: Yonghong Song <yhs@fb.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Jan 27, 2022
Added a selftest with three__user usages: a __user pointer-type argument in bpf_testmod, a __user pointer-type struct member in bpf_testmod, and a __user pointer-type struct member in vmlinux. In all cases, directly accessing the user memory will result verification failure. $ ./test_progs -v -n 22/3 ... libbpf: prog 'test_user1': BPF program load failed: Permission denied libbpf: prog 'test_user1': -- BEGIN PROG LOAD LOG -- R1 type=ctx expected=fp 0: R1=ctx(id=0,off=0,imm=0) R10=fp0 ; int BPF_PROG(test_user1, struct bpf_testmod_btf_type_tag_1 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_1' arg0 has btf_id 136561 type STRUCT 'bpf_testmod_btf_type_tag_1' 1: R1_w=user_ptr_bpf_testmod_btf_type_tag_1(id=0,off=0,imm=0) ; g = arg->a; 1: (61) r1 = *(u32 *)(r1 +0) R1 invalid mem access 'user_ptr_' ... #22/3 btf_tag/btf_type_tag_user_mod1:OK $ ./test_progs -v -n 22/4 ... libbpf: prog 'test_user2': BPF program load failed: Permission denied libbpf: prog 'test_user2': -- BEGIN PROG LOAD LOG -- R1 type=ctx expected=fp 0: R1=ctx(id=0,off=0,imm=0) R10=fp0 ; int BPF_PROG(test_user2, struct bpf_testmod_btf_type_tag_2 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_2' arg0 has btf_id 136563 type STRUCT 'bpf_testmod_btf_type_tag_2' 1: R1_w=ptr_bpf_testmod_btf_type_tag_2(id=0,off=0,imm=0) ; g = arg->p->a; 1: (79) r1 = *(u64 *)(r1 +0) ; R1_w=user_ptr_bpf_testmod_btf_type_tag_1(id=0,off=0,imm=0) ; g = arg->p->a; 2: (61) r1 = *(u32 *)(r1 +0) R1 invalid mem access 'user_ptr_' ... #22/4 btf_tag/btf_type_tag_user_mod2:OK $ ./test_progs -v -n 22/5 ... libbpf: prog 'test_sys_getsockname': BPF program load failed: Permission denied libbpf: prog 'test_sys_getsockname': -- BEGIN PROG LOAD LOG -- R1 type=ctx expected=fp 0: R1=ctx(id=0,off=0,imm=0) R10=fp0 ; int BPF_PROG(test_sys_getsockname, int fd, struct sockaddr *usockaddr, 0: (79) r1 = *(u64 *)(r1 +8) func '__sys_getsockname' arg1 has btf_id 2319 type STRUCT 'sockaddr' 1: R1_w=user_ptr_sockaddr(id=0,off=0,imm=0) ; g = usockaddr->sa_family; 1: (69) r1 = *(u16 *)(r1 +0) R1 invalid mem access 'user_ptr_' ... #22/5 btf_tag/btf_type_tag_user_vmlinux:OK Signed-off-by: Yonghong Song <yhs@fb.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Jan 27, 2022
Added a selftest with three__user usages: a __user pointer-type argument in bpf_testmod, a __user pointer-type struct member in bpf_testmod, and a __user pointer-type struct member in vmlinux. In all cases, directly accessing the user memory will result verification failure. $ ./test_progs -v -n 22/3 ... libbpf: prog 'test_user1': BPF program load failed: Permission denied libbpf: prog 'test_user1': -- BEGIN PROG LOAD LOG -- R1 type=ctx expected=fp 0: R1=ctx(id=0,off=0,imm=0) R10=fp0 ; int BPF_PROG(test_user1, struct bpf_testmod_btf_type_tag_1 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_1' arg0 has btf_id 136561 type STRUCT 'bpf_testmod_btf_type_tag_1' 1: R1_w=user_ptr_bpf_testmod_btf_type_tag_1(id=0,off=0,imm=0) ; g = arg->a; 1: (61) r1 = *(u32 *)(r1 +0) R1 invalid mem access 'user_ptr_' ... #22/3 btf_tag/btf_type_tag_user_mod1:OK $ ./test_progs -v -n 22/4 ... libbpf: prog 'test_user2': BPF program load failed: Permission denied libbpf: prog 'test_user2': -- BEGIN PROG LOAD LOG -- R1 type=ctx expected=fp 0: R1=ctx(id=0,off=0,imm=0) R10=fp0 ; int BPF_PROG(test_user2, struct bpf_testmod_btf_type_tag_2 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_2' arg0 has btf_id 136563 type STRUCT 'bpf_testmod_btf_type_tag_2' 1: R1_w=ptr_bpf_testmod_btf_type_tag_2(id=0,off=0,imm=0) ; g = arg->p->a; 1: (79) r1 = *(u64 *)(r1 +0) ; R1_w=user_ptr_bpf_testmod_btf_type_tag_1(id=0,off=0,imm=0) ; g = arg->p->a; 2: (61) r1 = *(u32 *)(r1 +0) R1 invalid mem access 'user_ptr_' ... #22/4 btf_tag/btf_type_tag_user_mod2:OK $ ./test_progs -v -n 22/5 ... libbpf: prog 'test_sys_getsockname': BPF program load failed: Permission denied libbpf: prog 'test_sys_getsockname': -- BEGIN PROG LOAD LOG -- R1 type=ctx expected=fp 0: R1=ctx(id=0,off=0,imm=0) R10=fp0 ; int BPF_PROG(test_sys_getsockname, int fd, struct sockaddr *usockaddr, 0: (79) r1 = *(u64 *)(r1 +8) func '__sys_getsockname' arg1 has btf_id 2319 type STRUCT 'sockaddr' 1: R1_w=user_ptr_sockaddr(id=0,off=0,imm=0) ; g = usockaddr->sa_family; 1: (69) r1 = *(u16 *)(r1 +0) R1 invalid mem access 'user_ptr_' ... #22/5 btf_tag/btf_type_tag_user_vmlinux:OK Signed-off-by: Yonghong Song <yhs@fb.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Jan 27, 2022
Added a selftest with three__user usages: a __user pointer-type argument in bpf_testmod, a __user pointer-type struct member in bpf_testmod, and a __user pointer-type struct member in vmlinux. In all cases, directly accessing the user memory will result verification failure. $ ./test_progs -v -n 22/3 ... libbpf: prog 'test_user1': BPF program load failed: Permission denied libbpf: prog 'test_user1': -- BEGIN PROG LOAD LOG -- R1 type=ctx expected=fp 0: R1=ctx(id=0,off=0,imm=0) R10=fp0 ; int BPF_PROG(test_user1, struct bpf_testmod_btf_type_tag_1 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_1' arg0 has btf_id 136561 type STRUCT 'bpf_testmod_btf_type_tag_1' 1: R1_w=user_ptr_bpf_testmod_btf_type_tag_1(id=0,off=0,imm=0) ; g = arg->a; 1: (61) r1 = *(u32 *)(r1 +0) R1 invalid mem access 'user_ptr_' ... #22/3 btf_tag/btf_type_tag_user_mod1:OK $ ./test_progs -v -n 22/4 ... libbpf: prog 'test_user2': BPF program load failed: Permission denied libbpf: prog 'test_user2': -- BEGIN PROG LOAD LOG -- R1 type=ctx expected=fp 0: R1=ctx(id=0,off=0,imm=0) R10=fp0 ; int BPF_PROG(test_user2, struct bpf_testmod_btf_type_tag_2 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_2' arg0 has btf_id 136563 type STRUCT 'bpf_testmod_btf_type_tag_2' 1: R1_w=ptr_bpf_testmod_btf_type_tag_2(id=0,off=0,imm=0) ; g = arg->p->a; 1: (79) r1 = *(u64 *)(r1 +0) ; R1_w=user_ptr_bpf_testmod_btf_type_tag_1(id=0,off=0,imm=0) ; g = arg->p->a; 2: (61) r1 = *(u32 *)(r1 +0) R1 invalid mem access 'user_ptr_' ... #22/4 btf_tag/btf_type_tag_user_mod2:OK $ ./test_progs -v -n 22/5 ... libbpf: prog 'test_sys_getsockname': BPF program load failed: Permission denied libbpf: prog 'test_sys_getsockname': -- BEGIN PROG LOAD LOG -- R1 type=ctx expected=fp 0: R1=ctx(id=0,off=0,imm=0) R10=fp0 ; int BPF_PROG(test_sys_getsockname, int fd, struct sockaddr *usockaddr, 0: (79) r1 = *(u64 *)(r1 +8) func '__sys_getsockname' arg1 has btf_id 2319 type STRUCT 'sockaddr' 1: R1_w=user_ptr_sockaddr(id=0,off=0,imm=0) ; g = usockaddr->sa_family; 1: (69) r1 = *(u16 *)(r1 +0) R1 invalid mem access 'user_ptr_' ... #22/5 btf_tag/btf_type_tag_user_vmlinux:OK Signed-off-by: Yonghong Song <yhs@fb.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Jan 27, 2022
Added a selftest with three__user usages: a __user pointer-type argument in bpf_testmod, a __user pointer-type struct member in bpf_testmod, and a __user pointer-type struct member in vmlinux. In all cases, directly accessing the user memory will result verification failure. $ ./test_progs -v -n 22/3 ... libbpf: prog 'test_user1': BPF program load failed: Permission denied libbpf: prog 'test_user1': -- BEGIN PROG LOAD LOG -- R1 type=ctx expected=fp 0: R1=ctx(id=0,off=0,imm=0) R10=fp0 ; int BPF_PROG(test_user1, struct bpf_testmod_btf_type_tag_1 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_1' arg0 has btf_id 136561 type STRUCT 'bpf_testmod_btf_type_tag_1' 1: R1_w=user_ptr_bpf_testmod_btf_type_tag_1(id=0,off=0,imm=0) ; g = arg->a; 1: (61) r1 = *(u32 *)(r1 +0) R1 invalid mem access 'user_ptr_' ... #22/3 btf_tag/btf_type_tag_user_mod1:OK $ ./test_progs -v -n 22/4 ... libbpf: prog 'test_user2': BPF program load failed: Permission denied libbpf: prog 'test_user2': -- BEGIN PROG LOAD LOG -- R1 type=ctx expected=fp 0: R1=ctx(id=0,off=0,imm=0) R10=fp0 ; int BPF_PROG(test_user2, struct bpf_testmod_btf_type_tag_2 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_2' arg0 has btf_id 136563 type STRUCT 'bpf_testmod_btf_type_tag_2' 1: R1_w=ptr_bpf_testmod_btf_type_tag_2(id=0,off=0,imm=0) ; g = arg->p->a; 1: (79) r1 = *(u64 *)(r1 +0) ; R1_w=user_ptr_bpf_testmod_btf_type_tag_1(id=0,off=0,imm=0) ; g = arg->p->a; 2: (61) r1 = *(u32 *)(r1 +0) R1 invalid mem access 'user_ptr_' ... #22/4 btf_tag/btf_type_tag_user_mod2:OK $ ./test_progs -v -n 22/5 ... libbpf: prog 'test_sys_getsockname': BPF program load failed: Permission denied libbpf: prog 'test_sys_getsockname': -- BEGIN PROG LOAD LOG -- R1 type=ctx expected=fp 0: R1=ctx(id=0,off=0,imm=0) R10=fp0 ; int BPF_PROG(test_sys_getsockname, int fd, struct sockaddr *usockaddr, 0: (79) r1 = *(u64 *)(r1 +8) func '__sys_getsockname' arg1 has btf_id 2319 type STRUCT 'sockaddr' 1: R1_w=user_ptr_sockaddr(id=0,off=0,imm=0) ; g = usockaddr->sa_family; 1: (69) r1 = *(u16 *)(r1 +0) R1 invalid mem access 'user_ptr_' ... #22/5 btf_tag/btf_type_tag_user_vmlinux:OK Signed-off-by: Yonghong Song <yhs@fb.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Jan 27, 2022
Added a selftest with three__user usages: a __user pointer-type argument in bpf_testmod, a __user pointer-type struct member in bpf_testmod, and a __user pointer-type struct member in vmlinux. In all cases, directly accessing the user memory will result verification failure. $ ./test_progs -v -n 22/3 ... libbpf: prog 'test_user1': BPF program load failed: Permission denied libbpf: prog 'test_user1': -- BEGIN PROG LOAD LOG -- R1 type=ctx expected=fp 0: R1=ctx(id=0,off=0,imm=0) R10=fp0 ; int BPF_PROG(test_user1, struct bpf_testmod_btf_type_tag_1 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_1' arg0 has btf_id 136561 type STRUCT 'bpf_testmod_btf_type_tag_1' 1: R1_w=user_ptr_bpf_testmod_btf_type_tag_1(id=0,off=0,imm=0) ; g = arg->a; 1: (61) r1 = *(u32 *)(r1 +0) R1 invalid mem access 'user_ptr_' ... #22/3 btf_tag/btf_type_tag_user_mod1:OK $ ./test_progs -v -n 22/4 ... libbpf: prog 'test_user2': BPF program load failed: Permission denied libbpf: prog 'test_user2': -- BEGIN PROG LOAD LOG -- R1 type=ctx expected=fp 0: R1=ctx(id=0,off=0,imm=0) R10=fp0 ; int BPF_PROG(test_user2, struct bpf_testmod_btf_type_tag_2 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_2' arg0 has btf_id 136563 type STRUCT 'bpf_testmod_btf_type_tag_2' 1: R1_w=ptr_bpf_testmod_btf_type_tag_2(id=0,off=0,imm=0) ; g = arg->p->a; 1: (79) r1 = *(u64 *)(r1 +0) ; R1_w=user_ptr_bpf_testmod_btf_type_tag_1(id=0,off=0,imm=0) ; g = arg->p->a; 2: (61) r1 = *(u32 *)(r1 +0) R1 invalid mem access 'user_ptr_' ... #22/4 btf_tag/btf_type_tag_user_mod2:OK $ ./test_progs -v -n 22/5 ... libbpf: prog 'test_sys_getsockname': BPF program load failed: Permission denied libbpf: prog 'test_sys_getsockname': -- BEGIN PROG LOAD LOG -- R1 type=ctx expected=fp 0: R1=ctx(id=0,off=0,imm=0) R10=fp0 ; int BPF_PROG(test_sys_getsockname, int fd, struct sockaddr *usockaddr, 0: (79) r1 = *(u64 *)(r1 +8) func '__sys_getsockname' arg1 has btf_id 2319 type STRUCT 'sockaddr' 1: R1_w=user_ptr_sockaddr(id=0,off=0,imm=0) ; g = usockaddr->sa_family; 1: (69) r1 = *(u16 *)(r1 +0) R1 invalid mem access 'user_ptr_' ... #22/5 btf_tag/btf_type_tag_user_vmlinux:OK Signed-off-by: Yonghong Song <yhs@fb.com>
kernel-patches-bot
pushed a commit
that referenced
this pull request
Jan 27, 2022
Added a selftest with three__user usages: a __user pointer-type argument in bpf_testmod, a __user pointer-type struct member in bpf_testmod, and a __user pointer-type struct member in vmlinux. In all cases, directly accessing the user memory will result verification failure. $ ./test_progs -v -n 22/3 ... libbpf: prog 'test_user1': BPF program load failed: Permission denied libbpf: prog 'test_user1': -- BEGIN PROG LOAD LOG -- R1 type=ctx expected=fp 0: R1=ctx(id=0,off=0,imm=0) R10=fp0 ; int BPF_PROG(test_user1, struct bpf_testmod_btf_type_tag_1 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_1' arg0 has btf_id 136561 type STRUCT 'bpf_testmod_btf_type_tag_1' 1: R1_w=user_ptr_bpf_testmod_btf_type_tag_1(id=0,off=0,imm=0) ; g = arg->a; 1: (61) r1 = *(u32 *)(r1 +0) R1 invalid mem access 'user_ptr_' ... #22/3 btf_tag/btf_type_tag_user_mod1:OK $ ./test_progs -v -n 22/4 ... libbpf: prog 'test_user2': BPF program load failed: Permission denied libbpf: prog 'test_user2': -- BEGIN PROG LOAD LOG -- R1 type=ctx expected=fp 0: R1=ctx(id=0,off=0,imm=0) R10=fp0 ; int BPF_PROG(test_user2, struct bpf_testmod_btf_type_tag_2 *arg) 0: (79) r1 = *(u64 *)(r1 +0) func 'bpf_testmod_test_btf_type_tag_user_2' arg0 has btf_id 136563 type STRUCT 'bpf_testmod_btf_type_tag_2' 1: R1_w=ptr_bpf_testmod_btf_type_tag_2(id=0,off=0,imm=0) ; g = arg->p->a; 1: (79) r1 = *(u64 *)(r1 +0) ; R1_w=user_ptr_bpf_testmod_btf_type_tag_1(id=0,off=0,imm=0) ; g = arg->p->a; 2: (61) r1 = *(u32 *)(r1 +0) R1 invalid mem access 'user_ptr_' ... #22/4 btf_tag/btf_type_tag_user_mod2:OK $ ./test_progs -v -n 22/5 ... libbpf: prog 'test_sys_getsockname': BPF program load failed: Permission denied libbpf: prog 'test_sys_getsockname': -- BEGIN PROG LOAD LOG -- R1 type=ctx expected=fp 0: R1=ctx(id=0,off=0,imm=0) R10=fp0 ; int BPF_PROG(test_sys_getsockname, int fd, struct sockaddr *usockaddr, 0: (79) r1 = *(u64 *)(r1 +8) func '__sys_getsockname' arg1 has btf_id 2319 type STRUCT 'sockaddr' 1: R1_w=user_ptr_sockaddr(id=0,off=0,imm=0) ; g = usockaddr->sa_family; 1: (69) r1 = *(u16 *)(r1 +0) R1 invalid mem access 'user_ptr_' ... #22/5 btf_tag/btf_type_tag_user_vmlinux:OK Signed-off-by: Yonghong Song <yhs@fb.com> Link: https://lore.kernel.org/r/20220127154616.659314-1-yhs@fb.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pull request for series with
subject: bpf: Remove duplicate headers
version: 1
url: https://patchwork.ozlabs.org/project/netdev/list/?series=200310