Coccinelle Archive on lore.kernel.org
 help / color / mirror / Atom feed
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>

  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