linux-kernel - Re: [-mm][PATCH 1/2] mm owner fix race between swap and exit

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]

Date:	Tue, 12 Aug 2008 09:36:36 +0530
From:	Balbir Singh <balbir@...ux.vnet.ibm.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	linux-mm@...ck.org, skumar@...ux.vnet.ibm.com,
	yamamoto@...inux.co.jp, menage@...gle.com, lizf@...fujitsu.com,
	linux-kernel@...r.kernel.org, nishimura@....nes.nec.co.jp,
	xemul@...nvz.org, hugh@...itas.com, kamezawa.hiroyu@...fujitsu.com
Subject: Re: [-mm][PATCH 1/2] mm owner fix race between swap and exit

Andrew Morton wrote:
> On Mon, 11 Aug 2008 15:37:33 +0530
> Balbir Singh <balbir@...ux.vnet.ibm.com> wrote:
> 
>> There's a race between mm->owner assignment and try_to_unuse(). The condition
>> occurs when try_to_unuse() runs in parallel with an exiting task.
>>
>> The race can be visualized below. To quote Hugh
>> "I don't think your careful alternation of CPU0/1 events at the end matters:
>> the swapoff CPU simply dereferences mm->owner after that task has gone"
>>
>> But the alteration does help understand the race better (at-least for me :))
>>
>> CPU0					CPU1
>> 					try_to_unuse
>> task 1 stars exiting			look at mm = task1->mm
>> ..					increment mm_users
>> task 1 exits
>> mm->owner needs to be updated, but
>> no new owner is found
>> (mm_users > 1, but no other task
>> has task->mm = task1->mm)
>> mm_update_next_owner() leaves
>>
>> grace period
>> 					user count drops, call mmput(mm)
>> task 1 freed
>> 					dereferencing mm->owner fails
>>
>> The fix is to notify the subsystem (via mm_owner_changed callback), if
>> no new owner is found by specifying the new task as NULL.
> 
> This patch applies to mainline, 2.6.27-rc2 and even 2.6.26.
> 
> Against which kernel/patch is it actually applicable?
> 
> (If the answer was "all of the above" then please don't go embedding
> mainline bugfixes in the middle of a -mm-only patch series!)

Andrew,

The answer is all, but the bug is not exposed *outside* of the memrlimit
controller, thus the push into -mm. I can redo and rework the patches for
mainline if required and pull it out of -mm.

-- 
	Warm Regards,
	Balbir Singh
	Linux Technology Center
	IBM, ISTL
--
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/