I spent some time looking into this: I think there are actually two bugs here. The write-after-free in kernfs_path_from_node_locked has an entirely different call trace (towards the end of this log: https://syzkaller.appspot.com/text?tag=CrashLog&x=16b1e0e9500000) compared to the NULL pointer dereference in neigh_periodic_work crash.
For the neigh_periodic_work crash, I struggle to see how this is related to 0f818c4bc1. It looks like what happens is at some point (I haven't spotted where) we free struct neighbour->lock, and then later when the workqueue calls into us we try to acquire it. I don't see any connection between this code and 0f818c4bc1. The lock in question isn't mmap_lock, but rather a separate lock owned by the struct neighbour. For the kernfs_path_from_node_locked crash, that one *does* look related to 0f818c4bc1. I'll continue debugging and send a patch. On Mon, Nov 30, 2020 at 5:08 AM syzbot <[email protected]> wrote: > > syzbot has bisected this issue to: > > commit 0f818c4bc1f3dc0d6d0ea916e0ab30cf5e75f4c0 > Author: Axel Rasmussen <[email protected]> > Date: Tue Nov 24 05:37:42 2020 +0000 > > mm: mmap_lock: add tracepoints around lock acquisition > > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1626291d500000 > start commit: 6174f052 Add linux-next specific files for 20201127 > git tree: linux-next > final oops: https://syzkaller.appspot.com/x/report.txt?x=1526291d500000 > console output: https://syzkaller.appspot.com/x/log.txt?x=1126291d500000 > kernel config: https://syzkaller.appspot.com/x/.config?x=79c69cf2521bef9c > dashboard link: https://syzkaller.appspot.com/bug?extid=19e6dd9943972fa1c58a > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12c3351d500000 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14c28809500000 > > Reported-by: [email protected] > Fixes: 0f818c4bc1f3 ("mm: mmap_lock: add tracepoints around lock acquisition") > > For information about bisection process see: https://goo.gl/tpsmEJ#bisection
