On Thu, Apr 18, 2019 at 8:14 PM syzbot <syzbot+15927486a4f1bfcbaf91@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > > syzbot has bisected this bug to: > > commit 77115225acc67d9ac4b15f04dd138006b9cd1ef2 > Author: Amir Goldstein <amir73il@xxxxxxxxx> > Date: Thu Jan 10 17:04:37 2019 +0000 > > fanotify: cache fsid in fsnotify_mark_connector > > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1627632d200000 > start commit: 3f018f4a Add linux-next specific files for 20190418 > git tree: linux-next > final crash: https://syzkaller.appspot.com/x/report.txt?x=1527632d200000 > console output: https://syzkaller.appspot.com/x/log.txt?x=1127632d200000 > kernel config: https://syzkaller.appspot.com/x/.config?x=faa7bdc352fc157e > dashboard link: https://syzkaller.appspot.com/bug?extid=15927486a4f1bfcbaf91 > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=155543d3200000 > > Reported-by: syzbot+15927486a4f1bfcbaf91@xxxxxxxxxxxxxxxxxxxxxxxxx > Fixes: 77115225acc6 ("fanotify: cache fsid in fsnotify_mark_connector") > Jan, It looks like lockless access to mark->connector is not safe as there is nothing preventing a reader from seeing a mark on object list without seeing the mark->connector assignment. It made me wonder if (!mark->connector) check in fsnotify_put_mark() is safe. I couldn't find any call site where that would be a problem, but perhaps we should be more careful? Anyway, it seems that fsnotify_put_mark() uses the non NULL mark->connector as the indication that mark is on object list, so just assigning mark->connector before adding to object list won't do. Since a reference of mark is our guaranty that mark->connector is not going away, I guess we could do opportunistic test for non NULL mark->connector from lockless path, if that fails, we check again with mark->lock held and if that fails something went wrong. Another option is to teach fsnotify_first_mark() and fsnotify_next_mark() to skip over marks with NULL mark->connector. What do you think? Did I over complicate this? Thanks, Amir.
