linux-kernel - Re: [PATCH 3/5] userns: Don't read extents twice in m

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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 01 Nov 2017 06:08:35 -0500
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     Nikolay Borisov <nborisov@...e.com>
Cc:     Christian Brauner <christian.brauner@...ntu.com>,
        Linux Containers <containers@...ts.linux-foundation.org>,
        tycho@...ho.ws, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/5] userns: Don't read extents twice in m_start

Nikolay Borisov <nborisov@...e.com> writes:

> On  1.11.2017 01:48, Eric W. Biederman wrote:
>> 
>> This is important so reading /proc/<pid>/{uid_map,gid_map,projid_map} while
>> the map is being written does not do strange things.
>> 
>> Signed-off-by: "Eric W. Biederman" <ebiederm@...ssion.com>
>> ---
>>  kernel/user_namespace.c | 6 ++++--
>>  1 file changed, 4 insertions(+), 2 deletions(-)
>> 
>> diff --git a/kernel/user_namespace.c b/kernel/user_namespace.c
>> index 563a2981d7c7..4f7e357ac1e2 100644
>> --- a/kernel/user_namespace.c
>> +++ b/kernel/user_namespace.c
>> @@ -683,11 +683,13 @@ static void *m_start(struct seq_file *seq, loff_t *ppos,
>>  		     struct uid_gid_map *map)
>>  {
>>  	loff_t pos = *ppos;
>> +	unsigned extents = map->nr_extents;
>> +	smp_rmb();
>
> Barriers need to be paired to work correctly as well as have explicit
> comments describing the pairing as per kernel coding style. Checkpatch
> will actually produce warning for that particular memory barrier.

So please look at the code and read the comment.  The fact the barrier
was not in m_start earlier is strictly speaking a bug.

In practice except for a very narrow window when this data is changing
the one time it can, this code does not matter at all.

As for checkpatch I have sympathy for it, checkpatch has a hard job,
but I won't listen to checkpatch when it is wrong.

If you have additional cleanups you would like to make in this area
please send patches.

Eric

>>  
>> -	if (pos >= map->nr_extents)
>> +	if (pos >= extents)
>>  		return NULL;
>>  
>> -	if (map->nr_extents <= UID_GID_MAP_MAX_BASE_EXTENTS)
>> +	if (extents <= UID_GID_MAP_MAX_BASE_EXTENTS)
>>  		return &map->extent[pos];
>>  
>>  	return &map->forward[pos];
>>