linux-kernel - Re: [BUG] staging: android: ashmem: Deadlock during ashmem

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]

Message-ID: <CAJsYZ5mpukCM6TpFb27tJt6G7ZufugEP4kx8wzGxhRwAO46cCw@mail.gmail.com>
Date:	Thu, 25 Apr 2013 19:24:41 +0530
From:	Shankar Brahadeeswaran <shankoo77@...il.com>
To:	Robert Love <rlove@...gle.com>
Cc:	Dan Carpenter <dan.carpenter@...cle.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Bjorn Bringert <bringert@...gle.com>,
	Al Viro <viro@...iv.linux.org.uk>, devel@...verdev.osuosl.org,
	Hugh Dickins <hughd@...gle.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Anjana V Kumar <anjanavk12@...il.com>
Subject: Re: [BUG] staging: android: ashmem: Deadlock during ashmem_shrink

Hi Robert,
Thanks for the feedback.

> This doesn't look insurmountable. It isn't necessary AFAICT to hold
> ashmem_mutex across shmem_file_setup.

I thought it may not be a good idea to do so and hence thought its
difficult to fix.
Dropping the lock in-between mmap may not be any issue if the user land code
follows a given sequence. But assuming that the following sequence of event
happens, it would lead to other races.

Process P1                                          Process P2
--------------                                           --------------
Creates ashmem region                       .....

Shares the fd to P2 via binder             Gets the fd

Does an mmap                                     Does an mmap

Releases the mutex before                  Procees with ashmem_mmap
since mutex is
shmem_file_setup and sleeps             available, checks for a
asma->file, still NUL
within shmem_file_setup                      so this also calls
shmem_file_setup.

The expected behavior is, one of them does the shmem_file_setup, puts
it in asma->file
The other process would just do get_file. With the original code
(without dropping the
mutex in-between) this would have been the behavior.
So IMHO dropping the lock in between could lead to other race conditions.

Also, there are other places in the code where ashmem_mutex is held and memory
allocation functions are called, ex:- range_alloc, calls kmem_cache_zalloc

Since ashmem_shrink holds the ashmem_mutex, any where from ashmem driver
if  a memory allocation function is called with the ashmem_mutex held
&&
if there is a low memory condition that leads to shrinkers being called
we'll hit the deadlock.

I'm trying to see if the ashmem_shrink should really hold the ashmem_mutex,
but looks like its necessary.

Warm Regards,
Shankar

On Tue, Apr 23, 2013 at 10:54 PM, Robert Love <rlove@...gle.com> wrote:
> On Tue, Apr 23, 2013 at 12:20 PM, Shankar Brahadeeswaran
> <shankoo77@...il.com> wrote:
>
>> I'm unable to think of a straight forward way to fix this. If you have
>> any suggestions please provide the same.
>> If we are unable to solve this too with minor mods, as suggested by
>> Dan we have to re-look at the locking in this driver.
>
> This doesn't look insurmountable. It isn't necessary AFAICT to hold
> ashmem_mutex across shmem_file_setup.
>
> Patch attached (untested).
>
>            Robert
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/