linux-kernel - Re: [PATCH] SMACK: Add missing rcu_read_lock/unlock for process capability walk.

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: <4DAF6FA5.7080801@schaufler-ca.com>
Date:	Wed, 20 Apr 2011 16:43:33 -0700
From:	Casey Schaufler <casey@...aufler-ca.com>
To:	Andi Kleen <ak@...ux.intel.com>
CC:	Andi Kleen <andi@...stfloor.org>, jmorris@...ei.org,
	linux-security-module@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Casey Schaufler <casey@...aufler-ca.com>
Subject: Re: [PATCH] SMACK: Add missing rcu_read_lock/unlock for process capability
 walk.

On 4/20/2011 4:18 PM, Andi Kleen wrote:
> On Wed, Apr 20, 2011 at 03:51:41PM -0700, Casey Schaufler wrote:
>> On 4/20/2011 3:00 PM, Andi Kleen wrote:
>>> From: Andi Kleen <ak@...ux.intel.com>
>>>
>>> smk_access_entry does a RCU list walk for a list shared with other
>>> threads. It relies on the caller doing rcu_read_lock().
>>> One caller forgot to do to this, which could lead to races
>>> on preemptible kernels.
>>>
>>> Move the rcu_read_lock() into smk_access_entry instead.
>> Nacked-by: Casey Schaufler <casey@...aufler-ca.com>
>>
>> The lock was moved out of smk_access_entry in support of the
>> processing done in the smack_mmap_file() hook. Where do you see
>> a potential race, and which caller "forgot" to do the lock?
> There are two callers and only one takes it.

There are two callers in smack_access.c.
There are four more in smack_lsm.c

> The one that doesn't take it is smk_curacc.

The call in smk_curacc() is using the task local list, not the system list.

> I checked the callers of that and there is no rcu_read_lock() in those
>
> As far as I understand the cred which holds this list is shared
> between threads and other threads can modify it. Which means 
> it needs RCU read lock protection.

The global list, yes. The task specific list, no. Modifying the local
list is like any other modification of the cred structure and requires
the cred be copied.

Moving the lock into smk_access_entry() would introduce a potential
deadlock in smack_mmap_file. There is a bit of convolution in the
mmap hook that requires looking at the list in a way that does not
allow the locking to be embedded where it used to be.

> -Andi
> --
> 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/
>
>

--
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/