On 4/15/25 11:30, Shung-Hsi Yu wrote:
On Mon, Apr 14, 2025 at 06:59:31AM +0200, Viktor Malik wrote:
On 4/11/25 18:22, Andrii Nakryiko wrote:
On Thu, Apr 10, 2025 at 2:55 AM Viktor Malik vmalik@redhat.com wrote:
As reported by CVE-2025-29481 [1], it is possible to corrupt a BPF ELF file such that arbitrary BPF instructions are loaded by libbpf. This can be done by setting a symbol (BPF program) section offset to a large (unsigned) number such that <section start + symbol offset> overflows and points before the section data in the memory.
...
Cc: stable@vger.kernel.org
Libbpf is packaged and consumed from Github mirror, which is produced from latest bpf-next and bpf trees, so there is no point in backporting fixes like this to stable kernel branches. Please drop the CC: stable in the next revision.
Ack, will drop it.
Sorry for blindly suggesting the CC. I'll keep that in mind.
Fixes: 6245947c1b3c ("libbpf: Allow gaps in BPF program sections to support overriden weak functions") Link: https://github.com/lmarch2/poc/blob/main/libbpf/libbpf.md Link: https://www.cve.org/CVERecord?id=CVE-2025-29481
libbpf is meant to load BPF programs under root. It's a highly-privileged operation, and libbpf is not meant, designed, and actually explicitly discouraged from loading untrusted ELF files. As such, this is just a normal bug fix, like lots of others. So let's drop the CVE link as well.
Again, no one in their sane mind should be passing untrusted ELF files into libbpf while running under root. Period.
All production use cases load ELF that they generated and control (usually embedded into their memory through BPF skeleton header). And if that ELF file is corrupted, you have problems somewhere else, libbpf is not a culprit.
While I couldn't agree more, I'm a bit on the fence here. On one hand, unless the CVE is revoked (see the other thread), people may still run across it and, without sufficient knowledge of libbpf, think that they are vulnerable. Having a CVE reference in the patch could help them recognize that they are using a patched version of libbpf or at least read an explanation why the vulnerability is not real.
On the other hand, since it's just a bug, I agree that it doesn't make much sense to reference a CVE from it. So, I'm ok both ways. I can reference the CVE and provide some better explanation why this should not be considered a vulnerability.
While I also see other colleagues that reference CVE number in the commit message in other subsystems, personally I would drop CVE reference here. This CVE entry doesn't have techinical detail in itself beside mentioning that the issue being buffer overflow, and is disputed/on the way to being rejected as far as this thread is concerned.
Good point, I agree that dropping the reference is probably the best approach here. It will allow us to merge this fix while we discuss the next steps wrt. the CVE in the other thread.
I'll send a new version.
Thanks. Viktor
...