bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* When did CVE-2025-38280 actually become a problem?
@ 2025-08-11  8:50 Rolf Eike Beer
  2025-08-18  8:28 ` Shung-Hsi Yu
  0 siblings, 1 reply; 2+ messages in thread
From: Rolf Eike Beer @ 2025-08-11  8:50 UTC (permalink / raw)
  To: Alexei Starovoitov, Daniel Borkmann, KaFai Wan; +Cc: bpf

[-- Attachment #1: Type: text/plain, Size: 1972 bytes --]

Hi all,

I sent basically the same question to cve@kernel.org but they are out of 
ideas. They assign the affected version numbers based on the "Fixes" 
information initially. But I'm unsure if that one is actually correct here, 
see below.

The fix is this commit:

> commit 86bc9c742426a16b52a10ef61f5b721aecca2344
> Author: KaFai Wan <mannkafai@gmail.com>
> Date:   Mon May 26 21:33:58 2025 +0800
>
>     bpf: Avoid __bpf_prog_ret0_warn when jit fails
> 
[…]
> Fixes: fa9dd599b4da ("bpf: get rid of pure_initcall dependency to enable 
jits")

And my questions were those:

=========
I was staring a while on CVE-2025-38280, especially since the message states:

> When creating bpf program, 'fp->jit_requested' depends on bpf_jit_enable.
> This issue is triggered because of CONFIG_BPF_JIT_ALWAYS_ON is not set …

But the commit that this was attributed to 
(5124abda3060e2eab506fb14a27acadee3c3e396) added the warning to the code, but 
the function is only reachable when CONFIG_BPF_JIT_ALWAYS_ON is set. This was 
the case until 6ebc5030e0c5a698f1dd9a6684cddf6ccaed64a0 moved it out of the 
define. So is this even an issue before 6.15 after all? Since the fix got 
backported I think it's more an issue to where the second commit got 
backported? So in my eyes the 5.10 kernel I'm currently staring at isn't 
affected at all.
==========

Can anyone comment on this? If there is a conclusion I can relay that to the 
CVE folks to update the version ranges afterwards.

Regards,

Eike
-- 
Rolf Eike Beer

emlix GmbH
Headquarters: Berliner Str. 12, 37073 Göttingen, Germany
Phone +49 (0)551 30664-0, e-mail info@emlix.com
District Court of Göttingen, Registry Number HR B 3160
Managing Directors: Heike Jordan, Dr. Uwe Kracke
VAT ID No. DE 205 198 055
Office Berlin: Panoramastr. 1, 10178 Berlin, Germany
Office Bonn: Bachstr. 6, 53115 Bonn, Germany
http://www.emlix.com

emlix - your embedded Linux partner

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 350 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: When did CVE-2025-38280 actually become a problem?
  2025-08-11  8:50 When did CVE-2025-38280 actually become a problem? Rolf Eike Beer
@ 2025-08-18  8:28 ` Shung-Hsi Yu
  0 siblings, 0 replies; 2+ messages in thread
From: Shung-Hsi Yu @ 2025-08-18  8:28 UTC (permalink / raw)
  To: Rolf Eike Beer; +Cc: Alexei Starovoitov, Daniel Borkmann, KaFai Wan, bpf

On Mon, Aug 11, 2025 at 10:50:21AM +0200, Rolf Eike Beer wrote:
> Hi all,
> 
> I sent basically the same question to cve@kernel.org but they are out of 
> ideas. They assign the affected version numbers based on the "Fixes" 
> information initially. But I'm unsure if that one is actually correct here, 
> see below.
> 
> The fix is this commit:
> 
> > commit 86bc9c742426a16b52a10ef61f5b721aecca2344
> > Author: KaFai Wan <mannkafai@gmail.com>
> > Date:   Mon May 26 21:33:58 2025 +0800
> >
> >     bpf: Avoid __bpf_prog_ret0_warn when jit fails
> > 
> […]
> > Fixes: fa9dd599b4da ("bpf: get rid of pure_initcall dependency to enable 
> jits")
> 
> And my questions were those:
> 
> =========
> I was staring a while on CVE-2025-38280, especially since the message states:
> 
> > When creating bpf program, 'fp->jit_requested' depends on bpf_jit_enable.
> > This issue is triggered because of CONFIG_BPF_JIT_ALWAYS_ON is not set …
> 
> But the commit that this was attributed to 
> (5124abda3060e2eab506fb14a27acadee3c3e396) added the warning to the code, but 
> the function is only reachable when CONFIG_BPF_JIT_ALWAYS_ON is set. This was 
> the case until 6ebc5030e0c5a698f1dd9a6684cddf6ccaed64a0 moved it out of the 
> define. So is this even an issue before 6.15 after all? Since the fix got 
> backported I think it's more an issue to where the second commit got 
> backported? So in my eyes the 5.10 kernel I'm currently staring at isn't 
> affected at all.
> ==========
> 
> Can anyone comment on this? If there is a conclusion I can relay that to the 
> CVE folks to update the version ranges afterwards.

Agree with the analysis. As far as the kernel warning is concerned, I
don't think it can happen before commit 6ebc5030e0c5.

Best,
Shung-Hsi

> Regards,
> 
> Eike
> -- 
> Rolf Eike Beer
> 
> emlix GmbH
> Headquarters: Berliner Str. 12, 37073 Göttingen, Germany
> Phone +49 (0)551 30664-0, e-mail info@emlix.com
> District Court of Göttingen, Registry Number HR B 3160
> Managing Directors: Heike Jordan, Dr. Uwe Kracke
> VAT ID No. DE 205 198 055
> Office Berlin: Panoramastr. 1, 10178 Berlin, Germany
> Office Bonn: Bachstr. 6, 53115 Bonn, Germany
> http://www.emlix.com
> 
> emlix - your embedded Linux partner

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2025-08-18  8:28 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-08-11  8:50 When did CVE-2025-38280 actually become a problem? Rolf Eike Beer
2025-08-18  8:28 ` Shung-Hsi Yu

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).