On Tue, Apr 14, 2020 at 12:41 PM Johannes Berg <johannes@xxxxxxxxxxxxxxxx> 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 <pabeni@xxxxxxxxxx> > > 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.
