linux-kernel - Re: [syzbot] [bpf?] [net?] WARNING in bpf_lwt_seg6_adjust

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

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