[lkml]   [2019]   [Apr]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: general protection fault in fanotify_handle_event
On Thu, Apr 18, 2019 at 8:14 PM syzbot
<> wrote:
> syzbot has bisected this bug to:
> commit 77115225acc67d9ac4b15f04dd138006b9cd1ef2
> Author: Amir Goldstein <>
> Date: Thu Jan 10 17:04:37 2019 +0000
> fanotify: cache fsid in fsnotify_mark_connector
> bisection log:
> start commit: 3f018f4a Add linux-next specific files for 20190418
> git tree: linux-next
> final crash:
> console output:
> kernel config:
> dashboard link:
> syz repro:
> Reported-by:
> Fixes: 77115225acc6 ("fanotify: cache fsid in fsnotify_mark_connector")


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?


 \ /
  Last update: 2019-04-19 21:37    [W:0.075 / U:1.652 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site