Re: CVE-2023-52592: libbpf: Fix NULL pointer dereference in bpf_object__collect_prog_relos

[Michal Hocko <mhocko@suse.com>]

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