linux-kernel - Re: general protection fault in fanotify_handle

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 19 Apr 2019 12:33:02 +0300
From:   Amir Goldstein <amir73il@...il.com>
To:     Jan Kara <jack@...e.cz>
Cc:     linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        syzkaller-bugs <syzkaller-bugs@...glegroups.com>,
        syzbot <syzbot+15927486a4f1bfcbaf91@...kaller.appspotmail.com>
Subject: Re: general protection fault in fanotify_handle_event

On Thu, Apr 18, 2019 at 8:14 PM syzbot
<syzbot+15927486a4f1bfcbaf91@...kaller.appspotmail.com> wrote:
>
> syzbot has bisected this bug to:
>
> commit 77115225acc67d9ac4b15f04dd138006b9cd1ef2
> Author: Amir Goldstein <amir73il@...il.com>
> 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@...kaller.appspotmail.com
> 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.