[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZenVkY9ZM1yPbVKC@tiehlicka>
Date: Thu, 7 Mar 2024 15:56:17 +0100
From: Michal Hocko <mhocko@...e.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: cve@...nel.org, linux-kernel@...r.kernel.org,
Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Andrii Nakryiko <andrii@...nel.org>,
Martin KaFai Lau <martin.lau@...ux.dev>, Song Liu <song@...nel.org>,
Yonghong Song <yonghong.song@...ux.dev>,
John Fastabend <john.fastabend@...il.com>,
KP Singh <kpsingh@...nel.org>, Stanislav Fomichev <sdf@...gle.com>,
Hao Luo <haoluo@...gle.com>, Jiri Olsa <jolsa@...nel.org>
Subject: Re: CVE-2023-52592: libbpf: Fix NULL pointer dereference in
bpf_object__collect_prog_relos
On Thu 07-03-24 13:16:26, Greg KH wrote:
[...]
> > OK, so this one is quite interesting. This is a userspace tooling
> > gaining a kernel CVE. Is this just an omission or is this really
> > expected.
>
> "omission"? I don't understand the question.
>
> We are responsible for assigning CVEs to stuff that is in the "Linux
> kernel source tree" (some have tried to get us to assign CVEs to
> programs like git that are just hosted on kernel.org), so for now, yes,
> this includes libbpf as well as stuff like perf.
I really do not want to nit pick here but the documentation doesn't talk
about tools:
: The Linux kernel developer team does have the ability to assign CVEs for
: potential Linux kernel security issues.
[...]
: Process
: =======
:
: As part of the normal stable release process, kernel changes that are
: potentially security issues are identified by the developers responsible
: for CVE number assignments and have CVE numbers automatically assigned
: to them.
So it is quite natural to ask whether this has been a patern matching
not working properly.
> > Also what is the security threat model here? If a malformed ELF file is
> > loaded then the process gets SEGV which is perfectly reasonable thing to
> > do.
>
> Again, we do not do "threat modeling", we do "does this fix a weakness",
> and I think this does as causing SEGV might not be a good thing, right?
Well, is it? It surely makes the code more robust but that would be the
case for almost any bug fix. Killing a misbheaving application (whether it
uses libbpf or any other library) is an expected behavior. But maybe BPF
developers can give us some useful insight.
--
Michal Hocko
SUSE Labs
Powered by blists - more mailing lists