From: nicstange@gmail.com (Nicolai Stange)
To: cocci@systeme.lip6.fr
Subject: [Cocci] [PATCH v6 2/8] debugfs: prevent access to removed files' private data
Date: Sun, 22 May 2016 15:28:12 +0200 [thread overview]
Message-ID: <878tz22peb.fsf@gmail.com> (raw)
In-Reply-To: <874m9rcmzx.fsf@gmail.com> (Nicolai Stange's message of "Sat, 21 May 2016 19:57:38 +0200")
Nicolai Stange <nicstange@gmail.com> writes:
> Sasha Levin <sasha.levin@oracle.com> writes:
>
>> On 05/18/2016 12:05 PM, Greg Kroah-Hartman wrote:
>>> On Wed, May 18, 2016 at 11:18:16AM -0400, Sasha Levin wrote:
>>>> On 05/18/2016 11:01 AM, Nicolai Stange wrote:
>>>>> Thanks a million for reporting!
>>>>>
>>>>> 1.) Do you have lockdep enabled?
>>>>
>>>> Yup, nothing there.
>>>>
>>>>> 2.) Does this happen before or after userspace init has been spawned,
>>>>> i.e. does the lockup happen at debugfs file creation time or
>>>>> possibly at usage time?
>>>>
>>>> So I looked closer, and it seems to happen after starting syzkaller, which
>>>> as far as I know tries to open many different debugfs files.
>>>>
>>>> Is there debug code I can add it that'll help us figure out what's up?
>>>
>>> Trying to figure out _which_ debugfs file is causing this would be
>>> great, if at all possible. strace?
>>
>> What seems to be failing is syzkaller's attempt to mmap the coverage
>> debugfs file. So this isn't actually a kernel deadlock but syzkaller
>> misbehaves when that scenario happens.
>>
>> Either way, it only fails to mmap with that commit that I've pointed
>> out.
>
> That info is really helpful here: the proxy file_operations introduced by
> this commit doesn't have a ->mmap() defined, i.e. it is NULL from the
> VFS layer's point of view.
>
> The simple reason is that at the time I submitted this series, my
> Coccinelle script didn't find any debugfs user with a ->mmap()
> defined. Thus either that script was broken or things have changed in
> the meanwhile.
Thankfully, it's the latter :)
See the attached cocci script I used back then.
It now reports:
./drivers/staging/android/sync_debug.c:330:1-20: unsupported file_operations given to debugfs
./kernel/kcov.c:267:6-25: unsupported file_operations given to debugfs
The kcov's ->mmap() has been introduced by
5c9a8750a640 ("kernel: add kcov code coverage")
dated from March this year.
Since that kcov debugfs file is never removed, it needs no protecting
proxy and thus, a replacement of debugfs_create_file() by
debugfs_create_file_unsafe() will do the trick here.
I'll send patches addressing the above two issues.
>>
>> th->cover_fd = open("/sys/kernel/debug/kcov", O_RDWR);
>> if (th->cover_fd == -1)
>> fail("open of /sys/kernel/debug/kcov failed");
>> if (ioctl(th->cover_fd, KCOV_INIT_TRACE, kCoverSize))
>> fail("cover enable write failed");
>> th->cover_data = (uintptr_t*)mmap(NULL, kCoverSize * sizeof(th->cover_data[0]), PROT_READ | PROT_WRITE, MAP_SHARED, th->cover_fd, 0);
>> if ((void*)th->cover_data == MAP_FAILED)
>> fail("cover mmap failed");
>>
>> And it's the mmap() that fails with -ENODEV.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: debugfs_unsupp_fops.cocci
URL: <https://systeme.lip6.fr/pipermail/cocci/attachments/20160522/23b3ce79/attachment.ksh>
next prev parent reply other threads:[~2016-05-22 13:28 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-22 13:11 [Cocci] [PATCH v6 0/8] fix debugfs file removal races Nicolai Stange
2016-03-22 13:11 ` [Cocci] [PATCH v6 1/8] debugfs: prevent access to possibly dead file_operations at file open Nicolai Stange
2016-03-22 13:11 ` [Cocci] [PATCH v6 2/8] debugfs: prevent access to removed files' private data Nicolai Stange
[not found] ` <573C80C8.6090307@oracle.com>
2016-05-18 15:01 ` Nicolai Stange
[not found] ` <573C87B8.902@oracle.com>
2016-05-18 16:32 ` Nicolai Stange
[not found] ` <20160518160520.GA5407@kroah.com>
[not found] ` <573F4200.3080208@oracle.com>
2016-05-21 17:57 ` Nicolai Stange
2016-05-22 13:28 ` Nicolai Stange [this message]
2016-03-22 13:11 ` [Cocci] [PATCH v6 3/8] debugfs: add support for self-protecting attribute file fops Nicolai Stange
2016-03-22 13:11 ` [Cocci] [PATCH v6 4/8] debugfs, coccinelle: check for obsolete DEFINE_SIMPLE_ATTRIBUTE() usage Nicolai Stange
2016-03-22 13:18 ` Julia Lawall
2016-03-22 13:11 ` [Cocci] [PATCH v6 5/8] debugfs: unproxify integer attribute files Nicolai Stange
2016-03-22 13:11 ` [Cocci] [PATCH v6 6/8] debugfs: unproxify files created through debugfs_create_bool() Nicolai Stange
2016-03-22 13:11 ` [Cocci] [PATCH v6 7/8] debugfs: unproxify files created through debugfs_create_blob() Nicolai Stange
2016-03-22 13:11 ` [Cocci] [PATCH v6 8/8] debugfs: unproxify files created through debugfs_create_u32_array() Nicolai Stange
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878tz22peb.fsf@gmail.com \
--to=nicstange@gmail.com \
--cc=cocci@systeme.lip6.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox