linux-kernel - Re: [syzbot] [mm?] possible deadlock in __mmap_lock_do_trace

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJHvVcjOjOTyrf4K+pTQ30doOx7hqheTExZY6_U+PCcdLigg7g@mail.gmail.com>
Date: Tue, 2 Jul 2024 15:35:14 -0700
From: Axel Rasmussen <axelrasmussen@...gle.com>
To: Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
Cc: syzbot+16b6ab88e66b34d09014@...kaller.appspotmail.com, 
	syzkaller-bugs <syzkaller-bugs@...glegroups.com>, linux-mm <linux-mm@...ck.org>, 
	Andrew Morton <akpm@...ux-foundation.org>, Nicolas Saenz Julienne <nsaenzju@...hat.com>, 
	LKML <linux-kernel@...r.kernel.org>, bpf <bpf@...r.kernel.org>
Subject: Re: [syzbot] [mm?] possible deadlock in __mmap_lock_do_trace_released

On Tue, Jul 2, 2024 at 3:09 PM Tetsuo Handa
<penguin-kernel@...ove.sakura.ne.jp> wrote:
>
> The local lock itself will be removed by
>
> mm: mmap_lock: replace get_memcg_path_buf() with on-stack buffer
>
> but is there possibility that this bpf program forms an infinite
> recursion (kernel stack overflow) bug?

It looks like the answer is "sort of yes", based on this stack from
the syzkaller dashboard:

[...]
[   54.017745][ T4691]  stack_map_get_build_id_offset+0x252/0x360
[   54.023698][ T4691]  __bpf_get_stack+0x1d7/0x240
[   54.028425][ T4691]  ___bpf_prog_run+0x5f6/0x2280
[   54.033415][ T4691]  __bpf_prog_run32+0xbb/0xe0
[   54.038058][ T4691]  ? migrate_disable+0x38/0xb0
[   54.042785][ T4691]  ? trace_call_bpf+0x4b/0x3d0
[   54.047944][ T4691]  trace_call_bpf+0x164/0x3d0
[   54.052580][ T4691]  ? trace_call_bpf+0x4b/0x3d0
[   54.057302][ T4691]  perf_trace_run_bpf_submit+0x3b/0xa0
[   54.062809][ T4691]  perf_trace_mmap_lock_acquire_returned+0x141/0x170
[   54.069877][ T4691]  ? __mmap_lock_do_trace_acquire_returned+0x3e/0x200
[   54.076596][ T4691]  __mmap_lock_do_trace_acquire_returned+0x1e1/0x200
[...]

__mmap_lock_do_trace_acquire_returned is called with mmap_lock held,
which apparently in this setup eventually calls down into
stack_map_get_build_id_offset, which also tries to take mmap_lock.

But, note that stack_map_get_build_id calls mmap_read_trylock, so I
would expect in the recursive case that call will simply fail, and
then stack_map_get_build_id_offset appears to deal gracefully with
that?

I would guess this is not unique to the mmap_lock tracepoints though.
I think the same issue would exist any time a tracepoint is triggered
with mmap_lock held? With ftrace on the right function I would expect
it to be easy to trigger this.

>
> On 2024/07/03 3:54, syzbot wrote:
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit:    a12978712d90 selftests/bpf: Move ARRAY_SIZE to bpf_misc.h
> > git tree:       bpf-next
> > console+strace: https://syzkaller.appspot.com/x/log.txt?x=130457fa980000
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=736daf12bd72e034
> > dashboard link: https://syzkaller.appspot.com/bug?extid=16b6ab88e66b34d09014
> > compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
> > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=125718be980000
> > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14528876980000
>