syzbot has bisected this bug to:
commit 01cacb00b35cb62b139f07d5f84bcf0eeda8eff6
Author: Paolo Abeni <[email protected]>
Date: Fri Mar 27 21:48:51 2020 +0000
mptcp: add netlink-based PM
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=10225bb3e00000
start commit: 4f8a3cc1 Merge tag 'x86-urgent-2020-04-12' of git://git.ke..
git tree: upstream
final crash: https://syzkaller.appspot.com/x/report.txt?x=12225bb3e00000
console output: https://syzkaller.appspot.com/x/log.txt?x=14225bb3e00000
kernel config: https://syzkaller.appspot.com/x/.config?x=3bfbde87e8e65624
dashboard link: https://syzkaller.appspot.com/bug?extid=a4aee3f42d7584d76761
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=100825afe00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=10df613fe00000
Reported-by: [email protected]
Fixes: 01cacb00b35c ("mptcp: add netlink-based PM")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
Hi syzbot keepers,
On Mon, 2020-04-13 at 07:05 -0700, syzbot wrote:
> syzbot has bisected this bug to:
>
> commit 01cacb00b35cb62b139f07d5f84bcf0eeda8eff6
> Author: Paolo Abeni <[email protected]>
> Date: Fri Mar 27 21:48:51 2020 +0000
>
> mptcp: add netlink-based PM
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=10225bb3e00000
This is, fairly obviously, incorrect. Same with the bisection for
6693adf1698864d21734, which is really the same underlying problem as
this one (though at a different code site).
However, it stands out that this was bisected to a commit that adds a
new generic netlink family in both cases.
This makes sense - the reproducer identifies the family by *number*, but
that number isn't stable, generic netlink families should be identified
by *name*.
Perhaps somehow syzbot could be taught that, so that the bisection is
stable across kernels with different generic netlink families
registered?
Alternatively, we _could_ add some kind of stable ID mode, but I'm not
sure we really want to ... since that would mean people start hardcoding
IDs?
johannes
On Tue, Apr 14, 2020 at 12:41 PM Johannes Berg
<[email protected]> wrote:
>
> Hi syzbot keepers,
>
> On Mon, 2020-04-13 at 07:05 -0700, syzbot wrote:
> > syzbot has bisected this bug to:
> >
> > commit 01cacb00b35cb62b139f07d5f84bcf0eeda8eff6
> > Author: Paolo Abeni <[email protected]>
> > Date: Fri Mar 27 21:48:51 2020 +0000
> >
> > mptcp: add netlink-based PM
> >
> > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=10225bb3e00000
>
> This is, fairly obviously, incorrect. Same with the bisection for
> 6693adf1698864d21734, which is really the same underlying problem as
> this one (though at a different code site).
>
> However, it stands out that this was bisected to a commit that adds a
> new generic netlink family in both cases.
>
> This makes sense - the reproducer identifies the family by *number*, but
> that number isn't stable, generic netlink families should be identified
> by *name*.
>
> Perhaps somehow syzbot could be taught that, so that the bisection is
> stable across kernels with different generic netlink families
> registered?
>
> Alternatively, we _could_ add some kind of stable ID mode, but I'm not
> sure we really want to ... since that would mean people start hardcoding
> IDs?
+syzkaller mailing list
Hi Johannes,
syzkaller has a pseudo-syscall to map string genetlink family ID to
int ID. If that syscall would have been used, then I assume it should
have worked. However in this case, it managed to trigger the bug with
a plain opaque blob with no knowledge about the blob contents
whatsoever. I don't see any realistic way to preserve family ID in
this case.