[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231117094531.GN8262@noisy.programming.kicks-ass.net>
Date: Fri, 17 Nov 2023 10:45:31 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Oleg Nesterov <oleg@...hat.com>
Cc: syzbot <syzbot+cbb25bb9b4d29a773985@...kaller.appspotmail.com>,
boqun.feng@...il.com, brauner@...nel.org,
linux-kernel@...r.kernel.org, longman@...hat.com,
michael.christie@...cle.com, mingo@...hat.com, mst@...hat.com,
syzkaller-bugs@...glegroups.com, tglx@...utronix.de,
wander@...hat.com, will@...nel.org
Subject: Re: [syzbot] [kernel?] inconsistent lock state in ptrace_attach
On Fri, Nov 17, 2023 at 10:38:30AM +0100, Oleg Nesterov wrote:
> On 11/17, Peter Zijlstra wrote:
> >
> > On Fri, Nov 17, 2023 at 12:49:04AM -0800, syzbot wrote:
> > > syzbot has bisected this issue to:
> > >
> > > commit 2d25a889601d2fbc87ec79b30ea315820f874b78
> > > Author: Peter Zijlstra <peterz@...radead.org>
> > > Date: Sun Sep 17 11:24:21 2023 +0000
> > >
> > > ptrace: Convert ptrace_attach() to use lock guards
> > >
> > > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=132b7d84e80000
> > > start commit: f31817cbcf48 Add linux-next specific files for 20231116
> > > git tree: linux-next
> > > final oops: https://syzkaller.appspot.com/x/report.txt?x=10ab7d84e80000
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=172b7d84e80000
> > > kernel config: https://syzkaller.appspot.com/x/.config?x=f59345f1d0a928c
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=cbb25bb9b4d29a773985
> > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1014d797680000
> > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=11b1ec67680000
> > >
> > > Reported-by: syzbot+cbb25bb9b4d29a773985@...kaller.appspotmail.com
> > > Fixes: 2d25a889601d ("ptrace: Convert ptrace_attach() to use lock guards")
> >
> > Hurmph, let me pull that patch from tip and go have a look. Thanks!
>
> I guess
>
> scoped_guard (write_lock, &tasklist_lock)
>
> is not right... this needs write_lock_irq().
>
> I didn't notice this when I reviewed this patch.
Yep, that seems to be the case.
I keep forgetting how to tell the syscall robot to test the below delta,
but I'll push the ammended commit to my staging tree and we'll see what
happens.
---
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -461,7 +461,7 @@ static int ptrace_attach(struct task_str
return retval;
}
- scoped_guard (write_lock, &tasklist_lock) {
+ scoped_guard (write_lock_irq, &tasklist_lock) {
if (unlikely(task->exit_state))
return -EPERM;
if (task->ptrace)
Powered by blists - more mailing lists