[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240625170606.Ed9u123U@linutronix.de>
Date: Tue, 25 Jun 2024 19:06:06 +0200
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: syzbot <syzbot+608a2acde8c5a101d07d@...kaller.appspotmail.com>
Cc: andrii@...nel.org, ast@...nel.org, bpf@...r.kernel.org,
daniel@...earbox.net, davem@...emloft.net, dsahern@...nel.org,
eddyz87@...il.com, edumazet@...gle.com, haoluo@...gle.com,
john.fastabend@...il.com, jolsa@...nel.org, kpsingh@...nel.org,
kuba@...nel.org, linux-kernel@...r.kernel.org, martin.lau@...ux.dev,
netdev@...r.kernel.org, pabeni@...hat.com, sdf@...ichev.me,
sdf@...gle.com, song@...nel.org, syzkaller-bugs@...glegroups.com,
yonghong.song@...ux.dev
Subject: Re: [syzbot] [bpf?] [net?] WARNING in bpf_lwt_seg6_adjust_srh
On 2024-06-25 09:51:25 [-0700], syzbot wrote:
> Hello,
Hi,
…
> commit d1542d4ae4dfdc47c9b3205ebe849ed23af213dd
> Author: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
> Date: Thu Jun 20 13:22:02 2024 +0000
>
> seg6: Use nested-BH locking for seg6_bpf_srh_states.
…
> WARNING: CPU: 0 PID: 5091 at net/core/filter.c:6579 ____bpf_lwt_seg6_adjust_srh net/core/filter.c:6579 [inline]
> WARNING: CPU: 0 PID: 5091 at net/core/filter.c:6579 bpf_lwt_seg6_adjust_srh+0x877/0xb30 net/core/filter.c:6568
…
> Call Trace:
> <TASK>
> bpf_prog_2088341bddeddc1d+0x40/0x42
> bpf_dispatcher_nop_func include/linux/bpf.h:1243 [inline]
> __bpf_prog_run include/linux/filter.h:691 [inline]
> bpf_prog_run include/linux/filter.h:698 [inline]
> bpf_test_run+0x4f0/0xa90 net/bpf/test_run.c:432
> bpf_prog_test_run_skb+0xafa/0x13b0 net/bpf/test_run.c:1081
> bpf_prog_test_run+0x33a/0x3b0 kernel/bpf/syscall.c:4313
> __sys_bpf+0x48d/0x810 kernel/bpf/syscall.c:5728
> __do_sys_bpf kernel/bpf/syscall.c:5817 [inline]
> __se_sys_bpf kernel/bpf/syscall.c:5815 [inline]
> __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5815
> do_syscall_x64 arch/x86/entry/common.c:52 [inline]
> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
I assumed this can only originate from input_action_end_bpf() but
clearly this not a hard requirement based on the report.
So this a valid invocation and it should not have been killer earlier in
the stack?
Sebastian
Powered by blists - more mailing lists