linux-kernel - Re: [PATCH bpf] bpf/btf: Accept function names that contain dots

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]

Date:   Thu, 15 Jun 2023 17:44:18 +0200
From:   Florent Revest <revest@...omium.org>
To:     bpf@...r.kernel.org, linux-kernel@...r.kernel.org,
        llvm@...ts.linux.dev
Cc:     martin.lau@...ux.dev, ast@...nel.org, daniel@...earbox.net,
        andrii@...nel.org, song@...nel.org, yhs@...com,
        john.fastabend@...il.com, kpsingh@...nel.org, sdf@...gle.com,
        haoluo@...gle.com, jolsa@...nel.org, nathan@...nel.org,
        ndesaulniers@...gle.com, trix@...hat.com, stable@...r.kernel.org
Subject: Re: [PATCH bpf] bpf/btf: Accept function names that contain dots

On Thu, Jun 15, 2023 at 4:56 PM Florent Revest <revest@...omium.org> wrote:
>
> When building a kernel with LLVM=1, LLVM_IAS=0 and CONFIG_KASAN=y, LLVM
> leaves DWARF tags for the "asan.module_ctor" & co symbols.

To be fair I can't tell if this is an LLVM bug. It's sort of curious
that with LLVM_IAS=1, these debugging symbols are not kept and they
are with LLVM_IAS=0 but I don't know what the expected behavior should
be and how BTF should deal with it. I'll let people with more context
comment on this! :)

An easy reproducer is:

$ touch pwet.c

$ clang -g -fsanitize=kernel-address -c -o pwet.o pwet.c
$ llvm-dwarfdump pwet.o | grep module_ctor

$ clang -fno-integrated-as -g -fsanitize=kernel-address -c -o pwet.o pwet.c
$ llvm-dwarfdump pwet.o | grep module_ctor
                DW_AT_name      ("asan.module_ctor")

> In a dramatic turn of event, this BTF verification failure can cause
> the netfilter_bpf initialization to fail, causing netfilter_core to
> free the netfilter_helper hashmap and netfilter_ftp to trigger a
> use-after-free. The risk of u-a-f in netfilter will be addressed
> separately

To be precise, I meant "netfilter conntrack".

I sent the following patch as a more targeted mitigation for the uaf
https://lore.kernel.org/netfilter-devel/20230615152918.3484699-1-revest@chromium.org/T/#u