[PATCH bpf-next 1/1] bpf: fix WARNING in __bpf_prog_ret0_warn when jit failed

[PATCH bpf-next 1/1] bpf: fix WARNING in __bpf_prog_ret0_warn when jit failed

[KaFai Wan]

syzkaller reported an issue:

WARNING: CPU: 3 PID: 217 at kernel/bpf/core.c:2357 __bpf_prog_ret0_warn+0xa/0x20 kernel/bpf/core.c:2357
Modules linked in:
CPU: 3 UID: 0 PID: 217 Comm: kworker/u32:6 Not tainted 6.15.0-rc4-syzkaller-00040-g8bac8898fe39 #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
Workqueue: ipv6_addrconf addrconf_dad_work
RIP: 0010:__bpf_prog_ret0_warn+0xa/0x20 kernel/bpf/core.c:2357
RSP: 0018:ffffc900031f6c18 EFLAGS: 00010293
RAX: 0000000000000000 RBX: ffffc9000006e000 RCX: 1ffff9200000dc06
RDX: ffff8880234ba440 RSI: ffffffff81ca6979 RDI: ffff888031e93040
RBP: ffffc900031f6cb8 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff88802b61e010
R13: ffff888031e93040 R14: 00000000000000a0 R15: ffff88802c3d4800
FS:  0000000000000000(0000) GS:ffff8880d6ce2000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000055557b6d2ca8 CR3: 000000002473e000 CR4: 0000000000352ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 <TASK>
 bpf_dispatcher_nop_func include/linux/bpf.h:1316 [inline]
 __bpf_prog_run include/linux/filter.h:718 [inline]
 bpf_prog_run include/linux/filter.h:725 [inline]
 cls_bpf_classify+0x74a/0x1110 net/sched/cls_bpf.c:105
 ...

When creating bpf program, 'fp->jit_requested' depends on bpf_jit_enable.
Currently the value of bpf_jit_enable is available from 0 to 2, 0 means use
interpreter and not jit, 1 and 2 means need to jit. When
CONFIG_BPF_JIT_ALWAYS_ON is enabled, bpf_jit_enable is permanently set
to 1, when it's not set or disabled, we can set bpf_jit_enable via proc.

This issue is triggered because of CONFIG_BPF_JIT_ALWAYS_ON is not set
and bpf_jit_enable is set to 1, causing the arch to attempt JIT the prog,
but jit failed due to FAULT_INJECTION. As a result, incorrectly
treats the program as valid, when the program runs it calls
`__bpf_prog_ret0_warn` and triggers the WARN_ON_ONCE(1).

Reported-by: syzbot+0903f6d7f285e41cdf10@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/bpf/6816e34e.a70a0220.254cdc.002c.GAE@google.com
Fixes: fa9dd599b4da ("bpf: get rid of pure_initcall dependency to enable jits")
Signed-off-by: KaFai Wan <mannkafai@gmail.com>
---
 kernel/bpf/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index a3e571688421..c20babbf998f 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -2474,7 +2474,7 @@ struct bpf_prog *bpf_prog_select_runtime(struct bpf_prog *fp, int *err)
 	/* In case of BPF to BPF calls, verifier did all the prep
 	 * work with regards to JITing, etc.
 	 */
-	bool jit_needed = false;
+	bool jit_needed = fp->jit_requested;
 
 	if (fp->bpf_func)
 		goto finalize;
-- 
2.43.0

Re: [PATCH bpf-next 1/1] bpf: fix WARNING in __bpf_prog_ret0_warn when jit failed

[patchwork-bot+netdevbpf]

Hello:

This patch was applied to bpf/bpf-next.git (master)
by Alexei Starovoitov <ast@kernel.org>:

On Mon, 26 May 2025 21:33:58 +0800 you wrote:
> syzkaller reported an issue:
> 
> WARNING: CPU: 3 PID: 217 at kernel/bpf/core.c:2357 __bpf_prog_ret0_warn+0xa/0x20 kernel/bpf/core.c:2357
> Modules linked in:
> CPU: 3 UID: 0 PID: 217 Comm: kworker/u32:6 Not tainted 6.15.0-rc4-syzkaller-00040-g8bac8898fe39 #0 PREEMPT(full)
> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
> Workqueue: ipv6_addrconf addrconf_dad_work
> RIP: 0010:__bpf_prog_ret0_warn+0xa/0x20 kernel/bpf/core.c:2357
> RSP: 0018:ffffc900031f6c18 EFLAGS: 00010293
> RAX: 0000000000000000 RBX: ffffc9000006e000 RCX: 1ffff9200000dc06
> RDX: ffff8880234ba440 RSI: ffffffff81ca6979 RDI: ffff888031e93040
> RBP: ffffc900031f6cb8 R08: 0000000000000001 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000000 R12: ffff88802b61e010
> R13: ffff888031e93040 R14: 00000000000000a0 R15: ffff88802c3d4800
> FS:  0000000000000000(0000) GS:ffff8880d6ce2000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 000055557b6d2ca8 CR3: 000000002473e000 CR4: 0000000000352ef0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
>  <TASK>
>  bpf_dispatcher_nop_func include/linux/bpf.h:1316 [inline]
>  __bpf_prog_run include/linux/filter.h:718 [inline]
>  bpf_prog_run include/linux/filter.h:725 [inline]
>  cls_bpf_classify+0x74a/0x1110 net/sched/cls_bpf.c:105
>  ...
> 
> [...]

Here is the summary with links:
  - [bpf-next,1/1] bpf: fix WARNING in __bpf_prog_ret0_warn when jit failed
    https://git.kernel.org/bpf/bpf-next/c/86bc9c742426

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

Re: [PATCH bpf-next 1/1] bpf: fix WARNING in __bpf_prog_ret0_warn when jit failed

[Felix Fietkau]

Hi,

On 26.05.25 15:33, KaFai Wan wrote:
> syzkaller reported an issue:
> 
> WARNING: CPU: 3 PID: 217 at kernel/bpf/core.c:2357 __bpf_prog_ret0_warn+0xa/0x20 kernel/bpf/core.c:2357
> Modules linked in:
> CPU: 3 UID: 0 PID: 217 Comm: kworker/u32:6 Not tainted 6.15.0-rc4-syzkaller-00040-g8bac8898fe39 #0 PREEMPT(full)
> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
> Workqueue: ipv6_addrconf addrconf_dad_work
> RIP: 0010:__bpf_prog_ret0_warn+0xa/0x20 kernel/bpf/core.c:2357
> RSP: 0018:ffffc900031f6c18 EFLAGS: 00010293
> RAX: 0000000000000000 RBX: ffffc9000006e000 RCX: 1ffff9200000dc06
> RDX: ffff8880234ba440 RSI: ffffffff81ca6979 RDI: ffff888031e93040
> RBP: ffffc900031f6cb8 R08: 0000000000000001 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000000 R12: ffff88802b61e010
> R13: ffff888031e93040 R14: 00000000000000a0 R15: ffff88802c3d4800
> FS:  0000000000000000(0000) GS:ffff8880d6ce2000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 000055557b6d2ca8 CR3: 000000002473e000 CR4: 0000000000352ef0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
>   <TASK>
>   bpf_dispatcher_nop_func include/linux/bpf.h:1316 [inline]
>   __bpf_prog_run include/linux/filter.h:718 [inline]
>   bpf_prog_run include/linux/filter.h:725 [inline]
>   cls_bpf_classify+0x74a/0x1110 net/sched/cls_bpf.c:105
>   ...
> 
> When creating bpf program, 'fp->jit_requested' depends on bpf_jit_enable.
> Currently the value of bpf_jit_enable is available from 0 to 2, 0 means use
> interpreter and not jit, 1 and 2 means need to jit. When
> CONFIG_BPF_JIT_ALWAYS_ON is enabled, bpf_jit_enable is permanently set
> to 1, when it's not set or disabled, we can set bpf_jit_enable via proc.
> 
> This issue is triggered because of CONFIG_BPF_JIT_ALWAYS_ON is not set
> and bpf_jit_enable is set to 1, causing the arch to attempt JIT the prog,
> but jit failed due to FAULT_INJECTION. As a result, incorrectly
> treats the program as valid, when the program runs it calls
> `__bpf_prog_ret0_warn` and triggers the WARN_ON_ONCE(1).
> 
> Reported-by: syzbot+0903f6d7f285e41cdf10@syzkaller.appspotmail.com
> Closes: https://lore.kernel.org/bpf/6816e34e.a70a0220.254cdc.002c.GAE@google.com
> Fixes: fa9dd599b4da ("bpf: get rid of pure_initcall dependency to enable jits")
> Signed-off-by: KaFai Wan <mannkafai@gmail.com>

I think this patch may have caused a regression in configurations with 
CONFIG_BPF_JIT_DEFAULT_ON=y when programs can't be JITed. Attaching the 
program fails with error -ENOTSUPP.

Please see https://github.com/openwrt/openwrt/issues/19405 for more 
information.

- Felix

Re: [PATCH bpf-next 1/1] bpf: fix WARNING in __bpf_prog_ret0_warn when jit failed

[Yonghong Song]

On 7/22/25 6:28 AM, Felix Fietkau wrote:
> Hi,
>
> On 26.05.25 15:33, KaFai Wan wrote:
>> syzkaller reported an issue:
>>
>> WARNING: CPU: 3 PID: 217 at kernel/bpf/core.c:2357 
>> __bpf_prog_ret0_warn+0xa/0x20 kernel/bpf/core.c:2357
>> Modules linked in:
>> CPU: 3 UID: 0 PID: 217 Comm: kworker/u32:6 Not tainted 
>> 6.15.0-rc4-syzkaller-00040-g8bac8898fe39 #0 PREEMPT(full)
>> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 
>> 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
>> Workqueue: ipv6_addrconf addrconf_dad_work
>> RIP: 0010:__bpf_prog_ret0_warn+0xa/0x20 kernel/bpf/core.c:2357
>> RSP: 0018:ffffc900031f6c18 EFLAGS: 00010293
>> RAX: 0000000000000000 RBX: ffffc9000006e000 RCX: 1ffff9200000dc06
>> RDX: ffff8880234ba440 RSI: ffffffff81ca6979 RDI: ffff888031e93040
>> RBP: ffffc900031f6cb8 R08: 0000000000000001 R09: 0000000000000000
>> R10: 0000000000000000 R11: 0000000000000000 R12: ffff88802b61e010
>> R13: ffff888031e93040 R14: 00000000000000a0 R15: ffff88802c3d4800
>> FS:  0000000000000000(0000) GS:ffff8880d6ce2000(0000) 
>> knlGS:0000000000000000
>> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> CR2: 000055557b6d2ca8 CR3: 000000002473e000 CR4: 0000000000352ef0
>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
>> Call Trace:
>>   <TASK>
>>   bpf_dispatcher_nop_func include/linux/bpf.h:1316 [inline]
>>   __bpf_prog_run include/linux/filter.h:718 [inline]
>>   bpf_prog_run include/linux/filter.h:725 [inline]
>>   cls_bpf_classify+0x74a/0x1110 net/sched/cls_bpf.c:105
>>   ...
>>
>> When creating bpf program, 'fp->jit_requested' depends on 
>> bpf_jit_enable.
>> Currently the value of bpf_jit_enable is available from 0 to 2, 0 
>> means use
>> interpreter and not jit, 1 and 2 means need to jit. When
>> CONFIG_BPF_JIT_ALWAYS_ON is enabled, bpf_jit_enable is permanently set
>> to 1, when it's not set or disabled, we can set bpf_jit_enable via proc.
>>
>> This issue is triggered because of CONFIG_BPF_JIT_ALWAYS_ON is not set
>> and bpf_jit_enable is set to 1, causing the arch to attempt JIT the 
>> prog,
>> but jit failed due to FAULT_INJECTION. As a result, incorrectly
>> treats the program as valid, when the program runs it calls
>> `__bpf_prog_ret0_warn` and triggers the WARN_ON_ONCE(1).
>>
>> Reported-by: syzbot+0903f6d7f285e41cdf10@syzkaller.appspotmail.com
>> Closes: 
>> https://lore.kernel.org/bpf/6816e34e.a70a0220.254cdc.002c.GAE@google.com
>> Fixes: fa9dd599b4da ("bpf: get rid of pure_initcall dependency to 
>> enable jits")
>> Signed-off-by: KaFai Wan <mannkafai@gmail.com>
>
> I think this patch may have caused a regression in configurations with 
> CONFIG_BPF_JIT_DEFAULT_ON=y when programs can't be JITed. Attaching 
> the program fails with error -ENOTSUPP.

Could you explain why there is an issue here?
CONFIG_BPF_JIT_DEFAULT_ON=y but prog cannot be jit'ed. So the end result is to return -ENOTSUPP.
It looks okay to me since the jit is required but jit failed, the only choice for the kernel
is to return an error.

>
> Please see https://github.com/openwrt/openwrt/issues/19405 for more 
> information.
>
> - Felix

Re: [PATCH bpf-next 1/1] bpf: fix WARNING in __bpf_prog_ret0_warn when jit failed

[Yonghong Song]

On 7/25/25 10:30 AM, Yonghong Song wrote:
>
> On 7/22/25 6:28 AM, Felix Fietkau wrote:
>> Hi,
>>
>> On 26.05.25 15:33, KaFai Wan wrote:
>>> syzkaller reported an issue:
>>>
>>> WARNING: CPU: 3 PID: 217 at kernel/bpf/core.c:2357 
>>> __bpf_prog_ret0_warn+0xa/0x20 kernel/bpf/core.c:2357
>>> Modules linked in:
>>> CPU: 3 UID: 0 PID: 217 Comm: kworker/u32:6 Not tainted 
>>> 6.15.0-rc4-syzkaller-00040-g8bac8898fe39 #0 PREEMPT(full)
>>> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 
>>> 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
>>> Workqueue: ipv6_addrconf addrconf_dad_work
>>> RIP: 0010:__bpf_prog_ret0_warn+0xa/0x20 kernel/bpf/core.c:2357
>>> RSP: 0018:ffffc900031f6c18 EFLAGS: 00010293
>>> RAX: 0000000000000000 RBX: ffffc9000006e000 RCX: 1ffff9200000dc06
>>> RDX: ffff8880234ba440 RSI: ffffffff81ca6979 RDI: ffff888031e93040
>>> RBP: ffffc900031f6cb8 R08: 0000000000000001 R09: 0000000000000000
>>> R10: 0000000000000000 R11: 0000000000000000 R12: ffff88802b61e010
>>> R13: ffff888031e93040 R14: 00000000000000a0 R15: ffff88802c3d4800
>>> FS:  0000000000000000(0000) GS:ffff8880d6ce2000(0000) 
>>> knlGS:0000000000000000
>>> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>> CR2: 000055557b6d2ca8 CR3: 000000002473e000 CR4: 0000000000352ef0
>>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>>> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
>>> Call Trace:
>>>   <TASK>
>>>   bpf_dispatcher_nop_func include/linux/bpf.h:1316 [inline]
>>>   __bpf_prog_run include/linux/filter.h:718 [inline]
>>>   bpf_prog_run include/linux/filter.h:725 [inline]
>>>   cls_bpf_classify+0x74a/0x1110 net/sched/cls_bpf.c:105
>>>   ...
>>>
>>> When creating bpf program, 'fp->jit_requested' depends on 
>>> bpf_jit_enable.
>>> Currently the value of bpf_jit_enable is available from 0 to 2, 0 
>>> means use
>>> interpreter and not jit, 1 and 2 means need to jit. When
>>> CONFIG_BPF_JIT_ALWAYS_ON is enabled, bpf_jit_enable is permanently set
>>> to 1, when it's not set or disabled, we can set bpf_jit_enable via 
>>> proc.
>>>
>>> This issue is triggered because of CONFIG_BPF_JIT_ALWAYS_ON is not set
>>> and bpf_jit_enable is set to 1, causing the arch to attempt JIT the 
>>> prog,
>>> but jit failed due to FAULT_INJECTION. As a result, incorrectly
>>> treats the program as valid, when the program runs it calls
>>> `__bpf_prog_ret0_warn` and triggers the WARN_ON_ONCE(1).
>>>
>>> Reported-by: syzbot+0903f6d7f285e41cdf10@syzkaller.appspotmail.com
>>> Closes: 
>>> https://lore.kernel.org/bpf/6816e34e.a70a0220.254cdc.002c.GAE@google.com 
>>>
>>> Fixes: fa9dd599b4da ("bpf: get rid of pure_initcall dependency to 
>>> enable jits")
>>> Signed-off-by: KaFai Wan <mannkafai@gmail.com>
>>
>> I think this patch may have caused a regression in configurations 
>> with CONFIG_BPF_JIT_DEFAULT_ON=y when programs can't be JITed. 
>> Attaching the program fails with error -ENOTSUPP.
>
> Could you explain why there is an issue here?
> CONFIG_BPF_JIT_DEFAULT_ON=y but prog cannot be jit'ed. So the end 
> result is to return -ENOTSUPP.
> It looks okay to me since the jit is required but jit failed, the only 
> choice for the kernel
> is to return an error.

BTW, you mentioned programs cannot be jited. Could you explain why programs cannot be jitted?
It would be strange that a program cannot be jitted but can be interpreted.

>
>>
>> Please see https://github.com/openwrt/openwrt/issues/19405 for more 
>> information.
>>
>> - Felix
>
>