netdev - Re: [PATCH v5 bpf-next 1/2] bpf: introduce helper bpf_find

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0ee9be06-6552-d8e3-74c7-7a96a46c8888@gmail.com>
Date:   Mon, 8 Nov 2021 10:36:19 -0800
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     Song Liu <songliubraving@...com>, bpf@...r.kernel.org,
        netdev@...r.kernel.org
Cc:     ast@...nel.org, daniel@...earbox.net, andrii@...nel.org,
        kernel-team@...com, kpsingh@...nel.org, hengqi.chen@...il.com,
        Yonghong Song <yhs@...com>
Subject: Re: [PATCH v5 bpf-next 1/2] bpf: introduce helper bpf_find_vma



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@...com>
> Tested-by: Hengqi Chen <hengqi.chen@...il.com>
> Signed-off-by: Song Liu <songliubraving@...com>
> ---

...

> 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.

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