Re: [PATCH] signal: Don't send signals to tasks that don't exist
From: Andrew Morton
Date: Fri Aug 17 2018 - 15:24:18 EST
On Fri, 17 Aug 2018 13:46:36 -0500 ebiederm@xxxxxxxxxxxx (Eric W. Biederman) wrote:
> Dmitry Vyukov <dvyukov@xxxxxxxxxx> writes:
> > On Wed, Aug 15, 2018 at 9:04 PM, Eric W. Biederman
> > <ebiederm@xxxxxxxxxxxx> wrote:
> >> Recently syzbot reported crashes in send_sigio_to_task and
> >> send_sigurg_to_task in linux-next. Despite finding a reproducer
> >> syzbot apparently did not bisected this or otherwise track down the
> >> offending commit in linux-next.
> >> I happened to see this report and examined the code because I had
> >> recently changed these functions as part of making PIDTYPE_TGID a real
> >> pid type so that fork would does not need to restart when receiving a
> >> signal. By examination I see that I spotted a bug in the code
> >> that could explain the reported crashes.
> >> When I took Oleg's suggestion and optimized send_sigurg and send_sigio
> >> to only send to a single task when type is PIDTYPE_PID or PIDTYPE_TGID
> >> I failed to handle pids that no longer point to tasks. The macro
> >> do_each_pid_task simply iterates for zero iterations. With pid_task
> >> an explicit NULL test is needed.
> >> Update the code to include the missing NULL test.
> >> Fixes: 019191342fec ("signal: Use PIDTYPE_TGID to clearly store where file signals will be sent")
> >> Reported-by: syzkaller-bugs@xxxxxxxxxxxxxxxx
> > Since the commit does not contain the syzbot-provided Reported-by tag,
> > we need to tell syzbot that this is fixed explicitly:
> Nor will my commits ever contain that information. That is information
> only of use to syzbot. That is not information useful to anyone else.
> Further syzbot did not track this down and report this. Syzbot said
> something is fishy here and happened to CC a public mailing list. Only
> by chance did I see the report. There was enough information to start
> an investigation but it certainly was not any kind of useful bug report.
> It is very annoying that despite syzbot claming to have a reproducer
> syzbot completely failed to locate the problem commit or the proper
> people to repor the issue to. I looked at the syzbot website link and
> there was no evidence that syzbot even tried to track down which branch
> in linux-next the commit came from. Much less to identify the commit on
> that branch.
Dude, lighten up.
These reports are useful. Even if they don't have a reproducer, we
have a backtrace and we can go look and we have a good chance of fixing
the bug. And as adding a single-line tag to the commit message helps
the syzbot people keep track of things, why not do it? It's hardly a big
They're doing useful things - please don't get all bent out of shape
because things aren't 100% perfect.
> Very annoyingly syzbot sent out emails and report this before it found a
> reproducer. This is despite several people explicitly asking syzbot
> to not report issuing on linux-next where syzbot does not have a
> reproducer and it can not track down the offending commit.
Dear syzbot, please report linux-next issues when you do not have a
reproducer and/or cannot track down the offending commit.