From: Quentin Monnet <qmo@kernel.org>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Andrii Nakryiko <andrii@kernel.org>,
Eduard Zingerman <eddyz87@gmail.com>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Martin KaFai Lau <martin.lau@linux.dev>,
Song Liu <song@kernel.org>,
Yonghong Song <yonghong.song@linux.dev>,
John Fastabend <john.fastabend@gmail.com>,
KP Singh <kpsingh@kernel.org>,
Stanislav Fomichev <sdf@fomichev.me>, Hao Luo <haoluo@google.com>,
Jiri Olsa <jolsa@kernel.org>,
bpf@vger.kernel.org, Rong Tao <rtoax@foxmail.com>
Subject: Re: [PATCH bpf-next] libbpf: Fix segfault due to libelf functions not setting errno
Date: Thu, 5 Dec 2024 21:56:58 +0000 [thread overview]
Message-ID: <e82fc551-752d-4596-9ab4-135a3720ecbd@kernel.org> (raw)
In-Reply-To: <CAEf4BzazrH+QrzJP+honiLWACSheQVuJpj7asdKFvx-rcQB+1w@mail.gmail.com>
2024-12-05 13:46 UTC-0800 ~ Andrii Nakryiko <andrii.nakryiko@gmail.com>
> On Thu, Dec 5, 2024 at 5:59 AM Quentin Monnet <qmo@kernel.org> wrote:
>>
>> Libelf functions do not set errno on failure. Instead, it relies on its
>> internal _elf_errno value, that can be retrieved via elf_errno (or the
>> corresponding message via elf_errmsg()). From "man libelf":
>>
>> If a libelf function encounters an error it will set an internal
>> error code that can be retrieved with elf_errno. Each thread
>> maintains its own separate error code. The meaning of each error
>> code can be determined with elf_errmsg, which returns a string
>> describing the error.
>>
>> As a consequence, libbpf should not return -errno when a function from
>> libelf fails, because an empty value will not be interpreted as an error
>> and won't prevent the program to stop. This is visible in
>> bpf_linker__add_file(), for example, where we call a succession of
>> functions that rely on libelf:
>>
>> err = err ?: linker_load_obj_file(linker, filename, opts, &obj);
>> err = err ?: linker_append_sec_data(linker, &obj);
>> err = err ?: linker_append_elf_syms(linker, &obj);
>> err = err ?: linker_append_elf_relos(linker, &obj);
>> err = err ?: linker_append_btf(linker, &obj);
>> err = err ?: linker_append_btf_ext(linker, &obj);
>>
>> If the object file that we try to process is not, in fact, a correct
>> object file, linker_load_obj_file() may fail with errno not being set,
>> and return 0. In this case we attempt to run linker_append_elf_sysms()
>> and may segfault.
>>
>> This can happen (and was discovered) with bpftool:
>>
>> $ bpftool gen object output.o sample_ret0.bpf.c
>> libbpf: failed to get ELF header for sample_ret0.bpf.c: invalid `Elf' handle
>> zsh: segmentation fault (core dumped) bpftool gen object output.o sample_ret0.bpf.c
>>
>> Fix the issue by returning a non-null error code (-EINVAL) when libelf
>> functions fail.
>>
>> Fixes: faf6ed321cf6 ("libbpf: Add BPF static linker APIs")
>> Signed-off-by: Quentin Monnet <qmo@kernel.org>
>> ---
>> tools/lib/bpf/linker.c | 22 ++++++++--------------
>> 1 file changed, 8 insertions(+), 14 deletions(-)
>>
>
> Ok, so *this* is the real issue with SIGSEGV that we were trying to
> "prevent" by file path comparison in that bpftool-specific patch,
> right? LGTM, I'll apply to bpf-next.
Correct, I wanted to find where that segfault was coming from, too :).
Thanks!
next prev parent reply other threads:[~2024-12-05 21:57 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-05 13:59 [PATCH bpf-next] libbpf: Fix segfault due to libelf functions not setting errno Quentin Monnet
2024-12-05 21:46 ` Andrii Nakryiko
2024-12-05 21:56 ` Quentin Monnet [this message]
2024-12-05 23:30 ` patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e82fc551-752d-4596-9ab4-135a3720ecbd@kernel.org \
--to=qmo@kernel.org \
--cc=andrii.nakryiko@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=martin.lau@linux.dev \
--cc=rtoax@foxmail.com \
--cc=sdf@fomichev.me \
--cc=song@kernel.org \
--cc=yonghong.song@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.