> On Nov 8, 2021, at 10:36 AM, Eric Dumazet <eric.dumazet@xxxxxxxxx> wrote:
>
>
>
> On 11/5/21 4:23 PM, Song Liu wrote:
>> In some profiler use cases, it is necessary to map an address to the
>> backing file, e.g., a shared library. bpf_find_vma helper provides a
>> flexible way to achieve this. bpf_find_vma maps an address of a task to
>> the vma (vm_area_struct) for this address, and feed the vma to an callback
>> BPF function. The callback function is necessary here, as we need to
>> ensure mmap_sem is unlocked.
>>
>> It is necessary to lock mmap_sem for find_vma. To lock and unlock mmap_sem
>> safely when irqs are disable, we use the same mechanism as stackmap with
>> build_id. Specifically, when irqs are disabled, the unlocked is postponed
>> in an irq_work. Refactor stackmap.c so that the irq_work is shared among
>> bpf_find_vma and stackmap helpers.
>>
>> Acked-by: Yonghong Song <yhs@xxxxxx>
>> Tested-by: Hengqi Chen <hengqi.chen@xxxxxxxxx>
>> Signed-off-by: Song Liu <songliubraving@xxxxxx>
>> ---
>
> ...
>
>> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
>> index dbc3ad07e21b6..cdb0fba656006 100644
>> --- a/kernel/bpf/btf.c
>> +++ b/kernel/bpf/btf.c
>> @@ -6342,7 +6342,10 @@ const struct bpf_func_proto bpf_btf_find_by_name_kind_proto = {
>> .arg4_type = ARG_ANYTHING,
>> };
>>
>> -BTF_ID_LIST_GLOBAL_SINGLE(btf_task_struct_ids, struct, task_struct)
>> +BTF_ID_LIST_GLOBAL(btf_task_struct_ids)
>> +BTF_ID(struct, task_struct)
>> +BTF_ID(struct, file)
>> +BTF_ID(struct, vm_area_struct)
>
> $ nm -v vmlinux |grep -A3 btf_task_struct_ids
> ffffffff82adfd9c R btf_task_struct_ids
> ffffffff82adfda0 r __BTF_ID__struct__file__715
> ffffffff82adfda4 r __BTF_ID__struct__vm_area_struct__716
> ffffffff82adfda8 r bpf_skb_output_btf_ids
>
> KASAN thinks btf_task_struct_ids has 4 bytes only.
I have KASAN enabled, but couldn't repro this issue. I think
btf_task_struct_ids looks correct:
nm -v vmlinux | grep -A3 -B1 btf_task_struct_ids
ffffffff83cf8260 r __BTF_ID__struct__task_struct__1026
ffffffff83cf8260 R btf_task_struct_ids
ffffffff83cf8264 r __BTF_ID__struct__file__1027
ffffffff83cf8268 r __BTF_ID__struct__vm_area_struct__1028
ffffffff83cf826c r bpf_skb_output_btf_ids
Did I miss something?
Thanks,
Song
>
> BUG: KASAN: global-out-of-bounds in task_iter_init+0x212/0x2e7 kernel/bpf/task_iter.c:661
> Read of size 4 at addr ffffffff90297404 by task swapper/0/1
>
> CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.15.0-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> Call Trace:
> <TASK>
> __dump_stack lib/dump_stack.c:88 [inline]
> dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
> print_address_description.constprop.0.cold+0xf/0x309 mm/kasan/report.c:256
> __kasan_report mm/kasan/report.c:442 [inline]
> kasan_report.cold+0x83/0xdf mm/kasan/report.c:459
> task_iter_init+0x212/0x2e7 kernel/bpf/task_iter.c:661
> do_one_initcall+0x103/0x650 init/main.c:1295
> do_initcall_level init/main.c:1368 [inline]
> do_initcalls init/main.c:1384 [inline]
> do_basic_setup init/main.c:1403 [inline]
> kernel_init_freeable+0x6b1/0x73a init/main.c:1606
> kernel_init+0x1a/0x1d0 init/main.c:1497
> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295
> </TASK>
>
> The buggy address belongs to the variable:
> btf_task_struct_ids+0x4/0x40
