Attachment 27460 Details for Bug 64652

vendor-sec discussion

smp-fault.txt (text/plain), 70.21 KB, created by Thomas Biege on 2005-01-08 00:00:50 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Thomas Biege

Created: 2005-01-08 00:00:50 UTC

Size: 70.21 KB

patch

obsolete

>From vendor-sec-admin@lst.de  Wed Jan  5 22:13:01 2005
>Return-Path: <vendor-sec-admin@lst.de>
>X-Original-To: thomas@wotan.suse.de
>Received: from hermes.suse.de (hermes.suse.de [149.44.160.1])
>	by wotan.suse.de (Postfix) with ESMTP id 6939813CCB2
>	for <thomas@wotan.suse.de>; Wed,  5 Jan 2005 22:13:01 +0100 (CET)
>Received: by hermes.suse.de (Postfix)
>	id 59D1B13A1E9; Wed,  5 Jan 2005 22:13:01 +0100 (CET)
>Received: from scanhost.suse.de (scanhost.suse.de [149.44.160.36])
>	by hermes.suse.de (Postfix) with ESMTP
>	id 3304A13A1DD; Wed,  5 Jan 2005 22:13:01 +0100 (CET)
>Received: from hermes.suse.de ([149.44.160.1])
> by scanhost.suse.de (scanhost [149.44.160.36]) (amavisd-new, port 10025)
> with ESMTP id 13208-15; Wed,  5 Jan 2005 22:12:53 +0100 (CET)
>Received: from Cantor.suse.de (ns.suse.de [195.135.220.2])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by hermes.suse.de (Postfix) with ESMTP
>	id 7B64F139F80; Wed,  5 Jan 2005 22:12:25 +0100 (CET)
>Received: from mail.lst.de (verein.lst.de [213.95.11.210])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by Cantor.suse.de (Postfix) with ESMTP id A183612E277B;
>	Wed,  5 Jan 2005 21:58:16 +0100 (CET)
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id j05Kw56s007793;
>	Wed, 5 Jan 2005 21:58:05 +0100
>Received: from isec.pl (isec.pl [193.110.121.50])
>	by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id j05Kvx6s007773
>	for <vendor-sec@lst.de>; Wed, 5 Jan 2005 21:57:59 +0100
>Received: by isec.pl (Postfix, from userid 500)
>	id 1A6E64091; Wed,  5 Jan 2005 21:57:59 +0100 (CET)
>Received: from localhost (localhost [127.0.0.1])
>	by isec.pl (Postfix) with ESMTP
>	id 053E318203; Wed,  5 Jan 2005 21:57:59 +0100 (CET)
>From: Paul Starzetz <ihaquer@isec.pl>
>To: vendor-sec <vendor-sec@lst.de>
>Message-ID: <Pine.LNX.4.44.0501052138110.2904-100000@isec.pl>
>MIME-Version: 1.0
>Content-Type: TEXT/PLAIN; charset=US-ASCII
>Subject: [vendor-sec] page fault @ SMP
>Sender: vendor-sec-admin@lst.de
>Errors-To: vendor-sec-admin@lst.de
>X-BeenThere: vendor-sec@lst.de
>X-Mailman-Version: 2.0.11
>Precedence: bulk
>List-Help: <mailto:vendor-sec-request@lst.de?subject=help>
>List-Post: <mailto:vendor-sec@lst.de>
>List-Subscribe: <https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec>,
>	<mailto:vendor-sec-request@lst.de?subject=subscribe>
>List-Id: <vendor-sec.lst.de>
>List-Unsubscribe: <https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec>,
>	<mailto:vendor-sec-request@lst.de?subject=unsubscribe>
>List-Archive: <https://www.lst.de/cgi-bin/mailman/private/vendor-sec/>
>X-Original-Date: Wed, 5 Jan 2005 21:57:58 +0100 (CET)
>Date: Wed, 5 Jan 2005 21:57:58 +0100 (CET)
>X-Virus-Scanned: by amavisd-new at scanhost.suse.de
>X-Spam-Status: No, hits=-4.9 tagged_above=-20.0 required=5.0 tests=BAYES_00
>X-Spam-Level: 
>Status: RO
>Content-Length: 1941
>Lines: 73
>
>Hi,
>
>I have found an exploitable flaw in the page fault handler, however only 
>in the SMP case.
>
>The problem is this:
>
>[A]	down_read(&mm->mmap_sem);
>
>	vma = find_vma(mm, address);
>	if (!vma)
>		goto bad_area;
>	if (vma->vm_start <= address)
>		goto good_area;
>	if (!(vma->vm_flags & VM_GROWSDOWN))
>		goto bad_area;
>	if (error_code & 4) {
>		/*
>		 * accessing the stack below %esp is always a bug.
>		 * The "+ 32" is there due to some instructions (like
>		 * pusha) doing post-decrement on the stack and that
>		 * doesn't show up until later..
>		 */
>		if (address + 32 < regs->esp)
>			goto bad_area;
>	}
>	if (expand_stack(vma, address))
>[B]		goto bad_area;
>
>
>an exploitable race scenario looks as follows:
>
>1) one thread issues down_write on the sem (remap, madvise, ...)
>
>2) two other threads faul below a VM_GROWSDOWN segment (note that they can 
>fault anywhere below vm_start since esp is arbitrary) and sleep in [A]
>
>3) first thread releases the sem and the two others run again, both find 
>the same VMA but:
>
>thread1 ----------F1----------[   VMA   ]
>thread2 ---------------F2-----[   VMA   ]
>
>where F1/2 faul address.
>
>If timed carefully we get:
>
>thread1 expands stack to F1, installs pte1
>thread2 expands stack to F2, installs pte2
>
>resulting in pte1 not covered by the VMA. Techniques like in mremap_pte 
>can be applied to further exploit this condition.
>
>Please do not argue that the race window is small - I have seen even 
>smaller windows opening like a barn :-]
>
>The critical section is only from [A] to [B], we do not care about timings 
>of handle_mm_fault etc, since the VMA is later consulted only for page 
>flags.
>
>Note that this also races with ptrace/proc etc (everything using 
>access_process_vm/get_user_pages).
>
>-- 
>Paul Starzetz
>iSEC Security Research
>http://isec.pl/
>
>
>_______________________________________________
>Vendor Security mailing list
>Vendor Security@lst.de
>https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec
>
>From vendor-sec-admin@lst.de  Thu Jan  6 20:16:05 2005
>Return-Path: <vendor-sec-admin@lst.de>
>X-Original-To: thomas@wotan.suse.de
>Received: from hermes.suse.de (hermes.suse.de [149.44.160.1])
>	by wotan.suse.de (Postfix) with ESMTP id D0F1A140E45
>	for <thomas@wotan.suse.de>; Thu,  6 Jan 2005 20:16:05 +0100 (CET)
>Received: by hermes.suse.de (Postfix)
>	id BA01413A849; Thu,  6 Jan 2005 20:16:05 +0100 (CET)
>Received: from scanhost.suse.de (scanhost.suse.de [149.44.160.36])
>	by hermes.suse.de (Postfix) with ESMTP
>	id 9C3E313A536; Thu,  6 Jan 2005 20:16:05 +0100 (CET)
>Received: from hermes.suse.de ([149.44.160.1])
> by scanhost.suse.de (scanhost [149.44.160.36]) (amavisd-new, port 10025)
> with ESMTP id 12003-08; Thu,  6 Jan 2005 20:15:47 +0100 (CET)
>Received: from Cantor.suse.de (mail.suse.de [195.135.220.2])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by hermes.suse.de (Postfix) with ESMTP
>	id 808CD13A8B9; Thu,  6 Jan 2005 19:59:31 +0100 (CET)
>Received: from mail.lst.de (verein.lst.de [213.95.11.210])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by Cantor.suse.de (Postfix) with ESMTP id C9BF312EBEC9;
>	Thu,  6 Jan 2005 19:59:30 +0100 (CET)
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id j06IxB6s026843;
>	Thu, 6 Jan 2005 19:59:11 +0100
>Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252])
>	by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id j06IwW6t026811
>	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
>	for <vendor-sec@lst.de>; Thu, 6 Jan 2005 19:58:33 +0100
>Received: from [127.0.0.1] (helo=logos.cnet)
>	by www.linux.org.uk with esmtp (Exim 4.33)
>	id 1Cmcq4-0008Jn-QV; Thu, 06 Jan 2005 18:58:29 +0000
>Received: by logos.cnet (Postfix, from userid 500)
>	id DDBBD122EEF; Thu,  6 Jan 2005 14:17:57 -0200 (BRST)
>From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
>To: Paul Starzetz <ihaquer@isec.pl>
>Cc: vendor-sec <vendor-sec@lst.de>, Andrew Morton <akpm@osdl.org>,
>	mingo@elte.hu, Hugh Dickins <hugh@veritas.com>
>Subject: Re: [vendor-sec] page fault @ SMP
>Message-ID: <20050106161757.GA23289@logos.cnet>
>References: <Pine.LNX.4.44.0501052138110.2904-100000@isec.pl>
>Mime-Version: 1.0
>Content-Type: text/plain; charset=us-ascii
>Content-Disposition: inline
>In-Reply-To: <Pine.LNX.4.44.0501052138110.2904-100000@isec.pl>
>User-Agent: Mutt/1.5.5.1i
>Sender: vendor-sec-admin@lst.de
>Errors-To: vendor-sec-admin@lst.de
>X-BeenThere: vendor-sec@lst.de
>X-Mailman-Version: 2.0.11
>Precedence: bulk
>List-Help: <mailto:vendor-sec-request@lst.de?subject=help>
>List-Post: <mailto:vendor-sec@lst.de>
>List-Subscribe: <https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec>,
>	<mailto:vendor-sec-request@lst.de?subject=subscribe>
>List-Id: <vendor-sec.lst.de>
>List-Unsubscribe: <https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec>,
>	<mailto:vendor-sec-request@lst.de?subject=unsubscribe>
>List-Archive: <https://www.lst.de/cgi-bin/mailman/private/vendor-sec/>
>X-Original-Date: Thu, 6 Jan 2005 14:17:57 -0200
>Date: Thu, 6 Jan 2005 14:17:57 -0200
>X-Virus-Scanned: by amavisd-new at scanhost.suse.de
>X-Spam-Status: No, hits=-5.9 tagged_above=-20.0 required=5.0 tests=BAYES_00,
> MY_LINUX
>X-Spam-Level: 
>Status: RO
>Content-Length: 4936
>Lines: 160
>
>
>Hi, 
>
>Amazing how many exploitable races have you found, thanks!
>
>On Wed, Jan 05, 2005 at 09:57:58PM +0100, Paul Starzetz wrote:
>> Hi,
>> 
>> I have found an exploitable flaw in the page fault handler, however only 
>> in the SMP case.
>> 
>> The problem is this:
>> 
>> [A]	down_read(&mm->mmap_sem);
>> 
>> 	vma = find_vma(mm, address);
>> 	if (!vma)
>> 		goto bad_area;
>> 	if (vma->vm_start <= address)
>> 		goto good_area;
>> 	if (!(vma->vm_flags & VM_GROWSDOWN))
>> 		goto bad_area;
>> 	if (error_code & 4) {
>> 		/*
>> 		 * accessing the stack below %esp is always a bug.
>> 		 * The "+ 32" is there due to some instructions (like
>> 		 * pusha) doing post-decrement on the stack and that
>> 		 * doesn't show up until later..
>> 		 */
>> 		if (address + 32 < regs->esp)
>> 			goto bad_area;
>> 	}
>> 	if (expand_stack(vma, address))
>> [B]		goto bad_area;
>> 
>> 
>> an exploitable race scenario looks as follows:
>> 
>> 1) one thread issues down_write on the sem (remap, madvise, ...)
>> 
>> 2) two other threads faul below a VM_GROWSDOWN segment (note that they can 
>> fault anywhere below vm_start since esp is arbitrary) and sleep in [A]
>> 
>> 3) first thread releases the sem and the two others run again, both find 
>> the same VMA but:
>> 
>> thread1 ----------F1----------[   VMA   ]
>> thread2 ---------------F2-----[   VMA   ]
>> 
>> where F1/2 faul address.
>> 
>> If timed carefully we get:
>> 
>> thread1 expands stack to F1, installs pte1
>> thread2 expands stack to F2, installs pte2
>> 
>> resulting in pte1 not covered by the VMA. Techniques like in mremap_pte 
>> can be applied to further exploit this condition.
>
>What techniques are these ? Can you give me a brief explanation?
>URL?
>
>The race looks valid to me.
>
>> Please do not argue that the race window is small - I have seen even 
>> smaller windows opening like a barn :-]
>
>Yes, there is a window - the race also triggers incorrect accounting in expand_stack() 
>AFAICS.
>
>> The critical section is only from [A] to [B], we do not care about timings 
>> of handle_mm_fault etc, since the VMA is later consulted only for page 
>> flags.
>> 
>> Note that this also races with ptrace/proc etc (everything using 
>> access_process_vm/get_user_pages).
>
>We lock the page_table_lock inside expand_stack(), which can be used
>to guarantee exclusivity. In v2.6 the anon_vma lock is used.
>
>The following untested patches ensure no thread will leave a stale pte "uncovered".
>
>I dont see any problem with access_process_vm->get_user_pages() either with 
>this in place.
>
>Please review. 
>
>Paul, do you have an exploit ready?
>
>The comment on top of expand_stack is bogus on v2.4 also.
>
>So this is the v2.4.28 version (someone needs to check the correctness of the GROWSDOWN
>case please - Willy?):
>
>
>--- linux-2.4.28.orig/include/linux/mm.h	2005-01-06 13:31:40.730506624 -0200
>+++ linux-2.4.28/include/linux/mm.h	2005-01-06 15:53:51.383650224 -0200
>@@ -647,12 +647,22 @@
> 	unsigned long grow;
> 
> 	/*
>-	 * vma->vm_start/vm_end cannot change under us because the caller is required
>-	 * to hold the mmap_sem in write mode. We need to get the spinlock only
>-	 * before relocating the vma range ourself.
>+	 * vma->vm_start/vm_end cannot change under us because the caller
>+	 * is required to hold the mmap_sem in read mode.  We need the
>+	 * page_table_lock lock to serialize against concurrent expand_stacks.
> 	 */
> 	address &= PAGE_MASK;
>  	spin_lock(&vma->vm_mm->page_table_lock);
>+
>+	/* already expanded while we were spinning? */
>+	if ((vma->vm_flags & VM_GROWSDOWN) && vma->vm_start <= address) {
>+		spin_unlock(vma->vm_mm->page_table_lock);
>+		return 0;
>+	} else if ((vma->vm_flags & VM_GROWSUP) && vma->vm_start >= address) {
>+		spin_unlock(vma->vm_mm->page_table_lock);
>+		return 0;
>+	}
>+
> 	grow = (vma->vm_start - address) >> PAGE_SHIFT;
> 	if (vma->vm_end - address > current->rlim[RLIMIT_STACK].rlim_cur ||
> 	    ((vma->vm_mm->total_vm + grow) << PAGE_SHIFT) > current->rlim[RLIMIT_AS].rlim_cur) {
>
>And the v2.6 version (someone needs to check the correctness of the GROSDOWN case please):
>
>
>--- linux-2.6.10-mm1.orig/mm/mmap.c	2005-01-05 15:58:26.000000000 -0200
>+++ linux-2.6.10-mm1/mm/mmap.c	2005-01-06 15:42:19.371852008 -0200
>@@ -1373,6 +1373,13 @@
> 	 */
> 	address += 4 + PAGE_SIZE - 1;
> 	address &= PAGE_MASK;
>+
>+	/* already expanded while waiting for anon_vma lock? */
>+	if (vma->vm_start >= address) {
>+		anon_vma_unlock(vma);
>+		return 0;
>+	}
>+
> 	grow = (address - vma->vm_end) >> PAGE_SHIFT;
> 
> 	/* Overcommit.. */
>@@ -1432,6 +1439,12 @@
> 		return -ENOMEM;
> 	anon_vma_lock(vma);
> 
>+	/* already expanded while waiting for anon_vma lock? */
>+	if (vma->vm_start <= address) {
>+		anon_vma_unlock(vma);
>+		return 0;
>+	}
>+
> 	/*
> 	 * vma->vm_start/vm_end cannot change under us because the caller
> 	 * is required to hold the mmap_sem in read mode.  We need the
>_______________________________________________
>Vendor Security mailing list
>Vendor Security@lst.de
>https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec
>
>From vendor-sec-admin@lst.de  Thu Jan  6 20:32:08 2005
>Return-Path: <vendor-sec-admin@lst.de>
>X-Original-To: thomas@wotan.suse.de
>Received: from hermes.suse.de (hermes.suse.de [149.44.160.1])
>	by wotan.suse.de (Postfix) with ESMTP id 0405F140E45
>	for <thomas@wotan.suse.de>; Thu,  6 Jan 2005 20:32:08 +0100 (CET)
>Received: by hermes.suse.de (Postfix)
>	id D750613A6B7; Thu,  6 Jan 2005 20:32:07 +0100 (CET)
>Received: from scanhost.suse.de (scanhost.suse.de [149.44.160.36])
>	by hermes.suse.de (Postfix) with ESMTP
>	id C228D13A583; Thu,  6 Jan 2005 20:32:07 +0100 (CET)
>Received: from hermes.suse.de ([149.44.160.1])
> by scanhost.suse.de (scanhost [149.44.160.36]) (amavisd-new, port 10025)
> with ESMTP id 16532-20; Thu,  6 Jan 2005 20:31:48 +0100 (CET)
>Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by hermes.suse.de (Postfix) with ESMTP
>	id 1F01813A75A; Thu,  6 Jan 2005 20:17:17 +0100 (CET)
>Received: from mail.lst.de (verein.lst.de [213.95.11.210])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by Cantor.suse.de (Postfix) with ESMTP id DE95A12EF04B;
>	Thu,  6 Jan 2005 20:17:16 +0100 (CET)
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id j06JH56s027158;
>	Thu, 6 Jan 2005 20:17:05 +0100
>Received: from isec.pl (isec.pl [193.110.121.50])
>	by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id j06JGU6s027138
>	for <vendor-sec@lst.de>; Thu, 6 Jan 2005 20:16:30 +0100
>Received: by isec.pl (Postfix, from userid 500)
>	id 0C3974090; Thu,  6 Jan 2005 20:16:29 +0100 (CET)
>Received: from localhost (localhost [127.0.0.1])
>	by isec.pl (Postfix) with ESMTP
>	id F133A18207; Thu,  6 Jan 2005 20:16:29 +0100 (CET)
>From: Paul Starzetz <ihaquer@isec.pl>
>To: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
>Cc: vendor-sec <vendor-sec@lst.de>, Andrew Morton <akpm@osdl.org>,
>	<mingo@elte.hu>, Hugh Dickins <hugh@veritas.com>
>Subject: Re: [vendor-sec] page fault @ SMP
>In-Reply-To: <20050106161757.GA23289@logos.cnet>
>Message-ID: <Pine.LNX.4.44.0501062008470.2904-100000@isec.pl>
>MIME-Version: 1.0
>Content-Type: TEXT/PLAIN; charset=US-ASCII
>Sender: vendor-sec-admin@lst.de
>Errors-To: vendor-sec-admin@lst.de
>X-BeenThere: vendor-sec@lst.de
>X-Mailman-Version: 2.0.11
>Precedence: bulk
>List-Help: <mailto:vendor-sec-request@lst.de?subject=help>
>List-Post: <mailto:vendor-sec@lst.de>
>List-Subscribe: <https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec>,
>	<mailto:vendor-sec-request@lst.de?subject=subscribe>
>List-Id: <vendor-sec.lst.de>
>List-Unsubscribe: <https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec>,
>	<mailto:vendor-sec-request@lst.de?subject=unsubscribe>
>List-Archive: <https://www.lst.de/cgi-bin/mailman/private/vendor-sec/>
>X-Original-Date: Thu, 6 Jan 2005 20:16:29 +0100 (CET)
>Date: Thu, 6 Jan 2005 20:16:29 +0100 (CET)
>X-Virus-Scanned: by amavisd-new at scanhost.suse.de
>X-Spam-Status: No, hits=-4.9 tagged_above=-20.0 required=5.0 tests=BAYES_00
>X-Spam-Level: 
>Status: RO
>Content-Length: 1328
>Lines: 53
>
>On Thu, 6 Jan 2005, Marcelo Tosatti wrote:
>
>> 
>> Hi, 
>> 
>> Amazing how many exploitable races have you found, thanks!
>
>I wish they were less :-]
>
>> What techniques are these ? Can you give me a brief explanation?
>> URL?
>
>mremap_pte used the pte cache to inject those PTEs into the dynamic linker 
>in a setuid binary :-/
>
>http://www.isec.pl/vulnerabilities/isec-0014-mremap-unmap.txt
>
>> We lock the page_table_lock inside expand_stack(), which can be used
>> to guarantee exclusivity. In v2.6 the anon_vma lock is used.
>
>the race is due to concurrent expand_stack() AFTER testing the necessity 
>WITHOUT an only-one-thread lock.
>
>> 
>> The following untested patches ensure no thread will leave a stale pte "uncovered".
>> 
>> I dont see any problem with access_process_vm->get_user_pages() either with 
>> this in place.
>
>there is a problem! A race skeleton looks like this:
>
>vma = find_vma()
>
>if( vma_needs_expand(vma) )
>{
>	expand_stack()
>}
>
>> Paul, do you have an exploit ready?
>
>I have done some simple code however I'm not able to hit the race 
>(some SMP machine...). Or I have a bug in the code :-] (or I'm wrong)
>
>-- 
>Paul Starzetz
>iSEC Security Research
>http://isec.pl/
>
>
>_______________________________________________
>Vendor Security mailing list
>Vendor Security@lst.de
>https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec
>
>From vendor-sec-admin@lst.de  Thu Jan  6 21:16:38 2005
>Return-Path: <vendor-sec-admin@lst.de>
>X-Original-To: thomas@wotan.suse.de
>Received: from hermes.suse.de (hermes.suse.de [149.44.160.1])
>	by wotan.suse.de (Postfix) with ESMTP id 9D9341401B2
>	for <thomas@wotan.suse.de>; Thu,  6 Jan 2005 21:16:38 +0100 (CET)
>Received: by hermes.suse.de (Postfix)
>	id 935F113A659; Thu,  6 Jan 2005 21:16:38 +0100 (CET)
>Received: from scanhost.suse.de (scanhost.suse.de [149.44.160.36])
>	by hermes.suse.de (Postfix) with ESMTP
>	id 817A913A637; Thu,  6 Jan 2005 21:16:38 +0100 (CET)
>Received: from hermes.suse.de ([149.44.160.1])
> by scanhost.suse.de (scanhost [149.44.160.36]) (amavisd-new, port 10025)
> with ESMTP id 00953-19; Thu,  6 Jan 2005 21:16:19 +0100 (CET)
>Received: from Cantor.suse.de (mail-ex.suse.de [195.135.220.2])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by hermes.suse.de (Postfix) with ESMTP
>	id 0336F13A6F9; Thu,  6 Jan 2005 21:03:40 +0100 (CET)
>Received: from mail.lst.de (verein.lst.de [213.95.11.210])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by Cantor.suse.de (Postfix) with ESMTP id E18B112EB097;
>	Thu,  6 Jan 2005 21:03:33 +0100 (CET)
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id j06K3K6s027805;
>	Thu, 6 Jan 2005 21:03:20 +0100
>Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252])
>	by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id j06K2h6t027760
>	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
>	for <vendor-sec@lst.de>; Thu, 6 Jan 2005 21:02:43 +0100
>Received: from [127.0.0.1] (helo=logos.cnet)
>	by www.linux.org.uk with esmtp (Exim 4.33)
>	id 1CmdqD-0001Oz-FC; Thu, 06 Jan 2005 20:02:41 +0000
>Received: by logos.cnet (Postfix, from userid 500)
>	id 4D140122EEF; Thu,  6 Jan 2005 15:22:00 -0200 (BRST)
>From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
>To: Paul Starzetz <ihaquer@isec.pl>
>Cc: vendor-sec <vendor-sec@lst.de>, Andrew Morton <akpm@osdl.org>,
>	mingo@elte.hu, Hugh Dickins <hugh@veritas.com>
>Subject: Re: [vendor-sec] page fault @ SMP
>Message-ID: <20050106172200.GD23289@logos.cnet>
>References: <20050106161757.GA23289@logos.cnet> <Pine.LNX.4.44.0501062008470.2904-100000@isec.pl>
>Mime-Version: 1.0
>Content-Type: text/plain; charset=us-ascii
>Content-Disposition: inline
>In-Reply-To: <Pine.LNX.4.44.0501062008470.2904-100000@isec.pl>
>User-Agent: Mutt/1.5.5.1i
>Sender: vendor-sec-admin@lst.de
>Errors-To: vendor-sec-admin@lst.de
>X-BeenThere: vendor-sec@lst.de
>X-Mailman-Version: 2.0.11
>Precedence: bulk
>List-Help: <mailto:vendor-sec-request@lst.de?subject=help>
>List-Post: <mailto:vendor-sec@lst.de>
>List-Subscribe: <https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec>,
>	<mailto:vendor-sec-request@lst.de?subject=subscribe>
>List-Id: <vendor-sec.lst.de>
>List-Unsubscribe: <https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec>,
>	<mailto:vendor-sec-request@lst.de?subject=unsubscribe>
>List-Archive: <https://www.lst.de/cgi-bin/mailman/private/vendor-sec/>
>X-Original-Date: Thu, 6 Jan 2005 15:22:00 -0200
>Date: Thu, 6 Jan 2005 15:22:00 -0200
>X-Virus-Scanned: by amavisd-new at scanhost.suse.de
>X-Spam-Status: No, hits=-4.9 tagged_above=-20.0 required=5.0 tests=BAYES_00
>X-Spam-Level: 
>Status: RO
>Content-Length: 1754
>Lines: 59
>
>On Thu, Jan 06, 2005 at 08:16:29PM +0100, Paul Starzetz wrote:
>> On Thu, 6 Jan 2005, Marcelo Tosatti wrote:
>> 
>> > 
>> > Hi, 
>> > 
>> > Amazing how many exploitable races have you found, thanks!
>> 
>> I wish they were less :-]
>> 
>> > What techniques are these ? Can you give me a brief explanation?
>> > URL?
>> 
>> mremap_pte used the pte cache to inject those PTEs into the dynamic linker 
>> in a setuid binary :-/
>> 
>> http://www.isec.pl/vulnerabilities/isec-0014-mremap-unmap.txt
>> 
>> > We lock the page_table_lock inside expand_stack(), which can be used
>> > to guarantee exclusivity. In v2.6 the anon_vma lock is used.
>> 
>> the race is due to concurrent expand_stack() AFTER testing the necessity 
>> WITHOUT an only-one-thread lock.
>
>The two threads are sharing the vma, and these locks (page_table_lock and anon vma) 
>are per-vma which guarantees exclusivity. 
>
>The additional checks the patch adds guarantees no "expand on already expanded area" 
>will happen.
>
>What have I misundertood?
>
>> > 
>> > The following untested patches ensure no thread will leave a stale pte "uncovered".
>> > 
>> > I dont see any problem with access_process_vm->get_user_pages() either with 
>> > this in place.
>> 
>> there is a problem! A race skeleton looks like this:
>> 
>> vma = find_vma()
>> 
>> if( vma_needs_expand(vma) )
>> {
>> 	expand_stack()
>> }
>
>??? 
>
>> > Paul, do you have an exploit ready?
>> 
>> I have done some simple code however I'm not able to hit the race 
>> (some SMP machine...). Or I have a bug in the code :-] (or I'm wrong)
>
>The race you describe looks real to me - I dont see anything which prevents it.
>_______________________________________________
>Vendor Security mailing list
>Vendor Security@lst.de
>https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec
>
>From vendor-sec-admin@lst.de  Thu Jan  6 21:22:59 2005
>Return-Path: <vendor-sec-admin@lst.de>
>X-Original-To: thomas@wotan.suse.de
>Received: from hermes.suse.de (hermes.suse.de [149.44.160.1])
>	by wotan.suse.de (Postfix) with ESMTP id ED7BA140E45
>	for <thomas@wotan.suse.de>; Thu,  6 Jan 2005 21:22:58 +0100 (CET)
>Received: by hermes.suse.de (Postfix)
>	id D6FA213A354; Thu,  6 Jan 2005 21:22:58 +0100 (CET)
>Received: from scanhost.suse.de (scanhost.suse.de [149.44.160.36])
>	by hermes.suse.de (Postfix) with ESMTP
>	id 9F1B913A345; Thu,  6 Jan 2005 21:22:58 +0100 (CET)
>Received: from hermes.suse.de ([149.44.160.1])
> by scanhost.suse.de (scanhost [149.44.160.36]) (amavisd-new, port 10025)
> with ESMTP id 04267-13; Thu,  6 Jan 2005 21:22:40 +0100 (CET)
>Received: from Cantor.suse.de (mail-ex.suse.de [195.135.220.2])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by hermes.suse.de (Postfix) with ESMTP
>	id D278D13A3B7; Thu,  6 Jan 2005 21:10:14 +0100 (CET)
>Received: from mail.lst.de (verein.lst.de [213.95.11.210])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by Cantor.suse.de (Postfix) with ESMTP id A89AD12EF7BE;
>	Thu,  6 Jan 2005 21:10:14 +0100 (CET)
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id j06KA56s027992;
>	Thu, 6 Jan 2005 21:10:05 +0100
>Received: from isec.pl (isec.pl [193.110.121.50])
>	by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id j06K976s027954
>	for <vendor-sec@lst.de>; Thu, 6 Jan 2005 21:09:07 +0100
>Received: by isec.pl (Postfix, from userid 500)
>	id 8626B4091; Thu,  6 Jan 2005 21:09:07 +0100 (CET)
>Received: from localhost (localhost [127.0.0.1])
>	by isec.pl (Postfix) with ESMTP
>	id 7511D18207; Thu,  6 Jan 2005 21:09:07 +0100 (CET)
>From: Paul Starzetz <ihaquer@isec.pl>
>To: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
>Cc: vendor-sec <vendor-sec@lst.de>, Andrew Morton <akpm@osdl.org>,
>	<mingo@elte.hu>, Hugh Dickins <hugh@veritas.com>
>Subject: Re: [vendor-sec] page fault @ SMP
>In-Reply-To: <20050106172200.GD23289@logos.cnet>
>Message-ID: <Pine.LNX.4.44.0501062107180.2904-100000@isec.pl>
>MIME-Version: 1.0
>Content-Type: TEXT/PLAIN; charset=US-ASCII
>Sender: vendor-sec-admin@lst.de
>Errors-To: vendor-sec-admin@lst.de
>X-BeenThere: vendor-sec@lst.de
>X-Mailman-Version: 2.0.11
>Precedence: bulk
>List-Help: <mailto:vendor-sec-request@lst.de?subject=help>
>List-Post: <mailto:vendor-sec@lst.de>
>List-Subscribe: <https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec>,
>	<mailto:vendor-sec-request@lst.de?subject=subscribe>
>List-Id: <vendor-sec.lst.de>
>List-Unsubscribe: <https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec>,
>	<mailto:vendor-sec-request@lst.de?subject=unsubscribe>
>List-Archive: <https://www.lst.de/cgi-bin/mailman/private/vendor-sec/>
>X-Original-Date: Thu, 6 Jan 2005 21:09:07 +0100 (CET)
>Date: Thu, 6 Jan 2005 21:09:07 +0100 (CET)
>X-Virus-Scanned: by amavisd-new at scanhost.suse.de
>X-Spam-Status: No, hits=-4.9 tagged_above=-20.0 required=5.0 tests=BAYES_00
>X-Spam-Level: 
>Status: RO
>Content-Length: 702
>Lines: 29
>
>On Thu, 6 Jan 2005, Marcelo Tosatti wrote:
>
>> The two threads are sharing the vma, and these locks (page_table_lock and anon vma) 
>> are per-vma which guarantees exclusivity. 
>
>I was talking about 2.4.
>
>> 
>> The additional checks the patch adds guarantees no "expand on already expanded area" 
>> will happen.
>> 
>> What have I misundertood?
>
>nothing ;-)
>
>> The race you describe looks real to me - I dont see anything which prevents it.
>
>yeah, to me too, but I just cannot trigger it :-]
>
>-- 
>Paul Starzetz
>iSEC Security Research
>http://isec.pl/
>
>
>_______________________________________________
>Vendor Security mailing list
>Vendor Security@lst.de
>https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec
>
>From vendor-sec-admin@lst.de  Thu Jan  6 22:30:45 2005
>Return-Path: <vendor-sec-admin@lst.de>
>X-Original-To: thomas@wotan.suse.de
>Received: from hermes.suse.de (hermes.suse.de [149.44.160.1])
>	by wotan.suse.de (Postfix) with ESMTP id 9042E1401B2
>	for <thomas@wotan.suse.de>; Thu,  6 Jan 2005 22:30:45 +0100 (CET)
>Received: by hermes.suse.de (Postfix)
>	id 83B79135236; Thu,  6 Jan 2005 22:30:45 +0100 (CET)
>Received: from scanhost.suse.de (scanhost.suse.de [149.44.160.36])
>	by hermes.suse.de (Postfix) with ESMTP
>	id 750BD12CE97; Thu,  6 Jan 2005 22:30:45 +0100 (CET)
>Received: from hermes.suse.de ([149.44.160.1])
> by scanhost.suse.de (scanhost [149.44.160.36]) (amavisd-new, port 10025)
> with ESMTP id 32599-05; Thu,  6 Jan 2005 22:30:31 +0100 (CET)
>Received: from Cantor.suse.de (ns.suse.de [195.135.220.2])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by hermes.suse.de (Postfix) with ESMTP
>	id 363A812A39C; Thu,  6 Jan 2005 22:30:31 +0100 (CET)
>Received: from mail.lst.de (verein.lst.de [213.95.11.210])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by Cantor.suse.de (Postfix) with ESMTP id 0946412EE9E1;
>	Thu,  6 Jan 2005 22:30:31 +0100 (CET)
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id j06LUC6s029222;
>	Thu, 6 Jan 2005 22:30:12 +0100
>Received: from MTVMIME01.enterprise.veritas.com (bay-bridge.veritas.com [143.127.3.10])
>	by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id j06LTA6s029195
>	for <vendor-sec@lst.de>; Thu, 6 Jan 2005 22:29:10 +0100
>Received: from megami.veritas.com (unverified) by 
>    MTVMIME01.enterprise.veritas.com (Content Technologies SMTPRS 4.3.12) 
>    with SMTP id <T6e549f87420a8911516d8@MTVMIME01.enterprise.veritas.com>; 
>    Thu, 6 Jan 2005 13:29:03 -0800
>Received: from goblin.wat.veritas.com ([10.10.97.50]) (3556 bytes) by 
>    megami.veritas.com via sendmail with P:esmtp/R:smart_host/T:smtp 
>    (sender: <hugh@veritas.com>) id <m1CmfBm-00018rC@megami.veritas.com> for 
>    <akpm@osdl.org>; Thu, 6 Jan 2005 13:29:02 -0800 (PST) 
>    (Smail-3.2.0.101 1997-Dec-17 #15 built 2001-Aug-30)
>From: Hugh Dickins <hugh@veritas.com>
>X-X-Sender: hugh@localhost.localdomain
>To: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
>Cc: Paul Starzetz <ihaquer@isec.pl>, vendor-sec <vendor-sec@lst.de>,
>	Andrew Morton <akpm@osdl.org>, <mingo@elte.hu>
>Subject: Re: [vendor-sec] page fault @ SMP
>In-Reply-To: <20050106161757.GA23289@logos.cnet>
>Message-ID: <Pine.LNX.4.44.0501062107220.3143-100000@localhost.localdomain>
>MIME-Version: 1.0
>Content-Type: text/plain; charset="us-ascii"
>Sender: vendor-sec-admin@lst.de
>Errors-To: vendor-sec-admin@lst.de
>X-BeenThere: vendor-sec@lst.de
>X-Mailman-Version: 2.0.11
>Precedence: bulk
>List-Help: <mailto:vendor-sec-request@lst.de?subject=help>
>List-Post: <mailto:vendor-sec@lst.de>
>List-Subscribe: <https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec>,
>	<mailto:vendor-sec-request@lst.de?subject=subscribe>
>List-Id: <vendor-sec.lst.de>
>List-Unsubscribe: <https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec>,
>	<mailto:vendor-sec-request@lst.de?subject=unsubscribe>
>List-Archive: <https://www.lst.de/cgi-bin/mailman/private/vendor-sec/>
>X-Original-Date: Thu, 6 Jan 2005 21:28:43 +0000 (GMT)
>Date: Thu, 6 Jan 2005 21:28:43 +0000 (GMT)
>X-Virus-Scanned: by amavisd-new at scanhost.suse.de
>X-Spam-Status: No, hits=-5.9 tagged_above=-20.0 required=5.0 tests=BAYES_00,
> MY_LINUX
>X-Spam-Level: 
>Status: RO
>Content-Length: 2952
>Lines: 92
>
>On Thu, 6 Jan 2005, Marcelo Tosatti wrote:
>> 
>> The race looks valid to me.
>
>Me too.
>
>> So this is the v2.4.28 version (someone needs to check the correctness
>> of the GROWSDOWN case please - Willy?):
>
>I think it's the GROWSUP case we need help with.
>
>> --- linux-2.4.28.orig/include/linux/mm.h	2005-01-06 13:31:40.730506624 -0200
>> +++ linux-2.4.28/include/linux/mm.h	2005-01-06 15:53:51.383650224 -0200
>> @@ -647,12 +647,22 @@
>>  	unsigned long grow;
>>  
>>  	/*
>> -	 * vma->vm_start/vm_end cannot change under us because the caller is required
>> -	 * to hold the mmap_sem in write mode. We need to get the spinlock only
>> -	 * before relocating the vma range ourself.
>> +	 * vma->vm_start/vm_end cannot change under us because the caller
>> +	 * is required to hold the mmap_sem in read mode.  We need the
>> +	 * page_table_lock lock to serialize against concurrent expand_stacks.
>>  	 */
>>  	address &= PAGE_MASK;
>>   	spin_lock(&vma->vm_mm->page_table_lock);
>> +
>> +	/* already expanded while we were spinning? */
>> +	if ((vma->vm_flags & VM_GROWSDOWN) && vma->vm_start <= address) {
>> +		spin_unlock(vma->vm_mm->page_table_lock);
>
>Needs to be "spin_unlock(&vma->...", but otherwise looks okay.
>
>> +		return 0;
>> +	} else if ((vma->vm_flags & VM_GROWSUP) && vma->vm_start >= address) {
>> +		spin_unlock(vma->vm_mm->page_table_lock);
>
>Similarly needs to be "spin_unlock(&vma->".  But I do not understand
>how the 2.4 expand_stack works with VM_GROWSUP at all.  Help!
>
>> +		return 0;
>> +	}
>> +
>>  	grow = (vma->vm_start - address) >> PAGE_SHIFT;
>>  	if (vma->vm_end - address > current->rlim[RLIMIT_STACK].rlim_cur ||
>>  	    ((vma->vm_mm->total_vm + grow) << PAGE_SHIFT) > current->rlim[RLIMIT_AS].rlim_cur) {
>> 
>> And the v2.6 version (someone needs to check the correctness of the GROSDOWN case please):
>> 
>> --- linux-2.6.10-mm1.orig/mm/mmap.c	2005-01-05 15:58:26.000000000 -0200
>> +++ linux-2.6.10-mm1/mm/mmap.c	2005-01-06 15:42:19.371852008 -0200
>> @@ -1373,6 +1373,13 @@
>>  	 */
>>  	address += 4 + PAGE_SIZE - 1;
>>  	address &= PAGE_MASK;
>> +
>> +	/* already expanded while waiting for anon_vma lock? */
>> +	if (vma->vm_start >= address) {
>
>No, this GROWSUP case needs to say "if (vma->vm_end >= address) {"
>doesn't it?  See grow below, and it's vm_end which gets adjusted.
>
>> +		anon_vma_unlock(vma);
>> +		return 0;
>> +	}
>> +
>>  	grow = (address - vma->vm_end) >> PAGE_SHIFT;
>>  
>>  	/* Overcommit.. */
>> @@ -1432,6 +1439,12 @@
>>  		return -ENOMEM;
>>  	anon_vma_lock(vma);
>>  
>> +	/* already expanded while waiting for anon_vma lock? */
>> +	if (vma->vm_start <= address) {
>> +		anon_vma_unlock(vma);
>> +		return 0;
>> +	}
>> +
>
>Looks good.
>
>>  	/*
>>  	 * vma->vm_start/vm_end cannot change under us because the caller
>>  	 * is required to hold the mmap_sem in read mode.  We need the
>
>Hugh
>
>_______________________________________________
>Vendor Security mailing list
>Vendor Security@lst.de
>https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec
>
>From vendor-sec-admin@lst.de  Fri Jan  7 00:48:45 2005
>Return-Path: <vendor-sec-admin@lst.de>
>X-Original-To: thomas@wotan.suse.de
>Received: from hermes.suse.de (hermes.suse.de [149.44.160.1])
>	by wotan.suse.de (Postfix) with ESMTP id CB0C2140E45
>	for <thomas@wotan.suse.de>; Fri,  7 Jan 2005 00:48:45 +0100 (CET)
>Received: by hermes.suse.de (Postfix)
>	id AEC22139D77; Fri,  7 Jan 2005 00:48:45 +0100 (CET)
>Received: from scanhost.suse.de (scanhost.suse.de [149.44.160.36])
>	by hermes.suse.de (Postfix) with ESMTP
>	id A2E5F125959; Fri,  7 Jan 2005 00:48:45 +0100 (CET)
>Received: from hermes.suse.de ([149.44.160.1])
> by scanhost.suse.de (scanhost [149.44.160.36]) (amavisd-new, port 10025)
> with ESMTP id 07291-07; Fri,  7 Jan 2005 00:48:34 +0100 (CET)
>Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by hermes.suse.de (Postfix) with ESMTP
>	id DF1D8E6103; Fri,  7 Jan 2005 00:48:34 +0100 (CET)
>Received: from mail.lst.de (verein.lst.de [213.95.11.210])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by Cantor.suse.de (Postfix) with ESMTP id BCBD912F1413;
>	Fri,  7 Jan 2005 00:48:34 +0100 (CET)
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id j06NmL6s031424;
>	Fri, 7 Jan 2005 00:48:21 +0100
>Received: from localhost.localdomain (clock-tower.bc.nu [81.2.110.250] (may be forged))
>	by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id j06NlI6t031400
>	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
>	for <vendor-sec@lst.de>; Fri, 7 Jan 2005 00:47:18 +0100
>Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
>	by localhost.localdomain (8.12.11/8.12.11) with ESMTP id j06MgLFG002059;
>	Thu, 6 Jan 2005 22:42:21 GMT
>Received: (from alan@localhost)
>	by localhost.localdomain (8.12.11/8.12.11/Submit) id j06MgJwn002058;
>	Thu, 6 Jan 2005 22:42:19 GMT
>X-Authentication-Warning: localhost.localdomain: alan set sender to alan@lxorguk.ukuu.org.uk using -f
>Subject: Re: [vendor-sec] page fault @ SMP
>From: Alan Cox <alan@lxorguk.ukuu.org.uk>
>To: Hugh Dickins <hugh@veritas.com>
>Cc: Marcelo Tosatti <marcelo.tosatti@cyclades.com>,
>	Paul Starzetz <ihaquer@isec.pl>, vendor-sec <vendor-sec@lst.de>,
>	Andrew Morton <akpm@osdl.org>, mingo@elte.hu
>In-Reply-To: <Pine.LNX.4.44.0501062107220.3143-100000@localhost.localdomain>
>References: <Pine.LNX.4.44.0501062107220.3143-100000@localhost.localdomain>
>Content-Type: text/plain
>Content-Transfer-Encoding: 7bit
>Message-Id: <1105050093.24896.277.camel@localhost.localdomain>
>Mime-Version: 1.0
>X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) 
>Sender: vendor-sec-admin@lst.de
>Errors-To: vendor-sec-admin@lst.de
>X-BeenThere: vendor-sec@lst.de
>X-Mailman-Version: 2.0.11
>Precedence: bulk
>List-Help: <mailto:vendor-sec-request@lst.de?subject=help>
>List-Post: <mailto:vendor-sec@lst.de>
>List-Subscribe: <https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec>,
>	<mailto:vendor-sec-request@lst.de?subject=subscribe>
>List-Id: <vendor-sec.lst.de>
>List-Unsubscribe: <https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec>,
>	<mailto:vendor-sec-request@lst.de?subject=unsubscribe>
>List-Archive: <https://www.lst.de/cgi-bin/mailman/private/vendor-sec/>
>X-Original-Date: Thu, 06 Jan 2005 22:42:18 +0000
>Date: Thu, 06 Jan 2005 22:42:18 +0000
>X-Virus-Scanned: by amavisd-new at scanhost.suse.de
>X-Spam-Status: No, hits=-4.9 tagged_above=-20.0 required=5.0 tests=BAYES_00
>X-Spam-Level: 
>Status: RO
>Content-Length: 466
>Lines: 16
>
>On Iau, 2005-01-06 at 21:28, Hugh Dickins wrote:
>> On Thu, 6 Jan 2005, Marcelo Tosatti wrote:
>> > 
>> > The race looks valid to me.
>> 
>> Me too.
>> 
>> > So this is the v2.4.28 version (someone needs to check the correctness
>> > of the GROWSDOWN case please - Willy?):
>
>Parisc 2.4 was never afaik merged in full.
>
>_______________________________________________
>Vendor Security mailing list
>Vendor Security@lst.de
>https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec
>
>From vendor-sec-admin@lst.de  Fri Jan  7 13:19:27 2005
>Return-Path: <vendor-sec-admin@lst.de>
>X-Original-To: thomas@wotan.suse.de
>Received: from hermes.suse.de (hermes.suse.de [149.44.160.1])
>	by wotan.suse.de (Postfix) with ESMTP id 3506D143819
>	for <thomas@wotan.suse.de>; Fri,  7 Jan 2005 13:19:27 +0100 (CET)
>Received: by hermes.suse.de (Postfix)
>	id 1944313A5E3; Fri,  7 Jan 2005 13:19:27 +0100 (CET)
>Received: from scanhost.suse.de (scanhost.suse.de [149.44.160.36])
>	by hermes.suse.de (Postfix) with ESMTP
>	id E7CD913A450; Fri,  7 Jan 2005 13:19:26 +0100 (CET)
>Received: from hermes.suse.de ([149.44.160.1])
> by scanhost.suse.de (scanhost [149.44.160.36]) (amavisd-new, port 10025)
> with ESMTP id 18555-01; Fri,  7 Jan 2005 13:19:23 +0100 (CET)
>Received: from Cantor.suse.de (news.suse.de [195.135.220.2])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by hermes.suse.de (Postfix) with ESMTP
>	id 5855A13A567; Fri,  7 Jan 2005 13:19:23 +0100 (CET)
>Received: from mail.lst.de (verein.lst.de [213.95.11.210])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by Cantor.suse.de (Postfix) with ESMTP id 5D11E12F42EA;
>	Fri,  7 Jan 2005 13:19:17 +0100 (CET)
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id j07CJ76s011489;
>	Fri, 7 Jan 2005 13:19:07 +0100
>Received: from MTVMIME03.enterprise.veritas.com (bay-bridge.veritas.com [143.127.3.10])
>	by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id j07CIJ6s011395
>	for <vendor-sec@lst.de>; Fri, 7 Jan 2005 13:18:19 +0100
>Received: from megami.veritas.com (unverified) by 
>    MTVMIME03.enterprise.veritas.com (Content Technologies SMTPRS 4.3.12) 
>    with SMTP id <T6e57cd93b10a891155630@MTVMIME03.enterprise.veritas.com>; 
>    Fri, 7 Jan 2005 04:18:13 -0800
>Received: from goblin.wat.veritas.com ([10.10.97.50]) (1821 bytes) by 
>    megami.veritas.com via sendmail with P:esmtp/R:smart_host/T:smtp 
>    (sender: <hugh@veritas.com>) id <m1Cmt4G-0000daC@megami.veritas.com> for 
>    <akpm@osdl.org>; Fri, 7 Jan 2005 04:18:12 -0800 (PST) 
>    (Smail-3.2.0.101 1997-Dec-17 #15 built 2001-Aug-30)
>From: Hugh Dickins <hugh@veritas.com>
>X-X-Sender: hugh@localhost.localdomain
>To: Alan Cox <alan@lxorguk.ukuu.org.uk>
>Cc: Marcelo Tosatti <marcelo.tosatti@cyclades.com>,
>	Paul Starzetz <ihaquer@isec.pl>, vendor-sec <vendor-sec@lst.de>,
>	Andrew Morton <akpm@osdl.org>, <mingo@elte.hu>
>Subject: Re: [vendor-sec] page fault @ SMP
>In-Reply-To: <1105050093.24896.277.camel@localhost.localdomain>
>Message-ID: <Pine.LNX.4.44.0501071205550.2742-100000@localhost.localdomain>
>MIME-Version: 1.0
>Content-Type: text/plain; charset="us-ascii"
>Sender: vendor-sec-admin@lst.de
>Errors-To: vendor-sec-admin@lst.de
>X-BeenThere: vendor-sec@lst.de
>X-Mailman-Version: 2.0.11
>Precedence: bulk
>List-Help: <mailto:vendor-sec-request@lst.de?subject=help>
>List-Post: <mailto:vendor-sec@lst.de>
>List-Subscribe: <https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec>,
>	<mailto:vendor-sec-request@lst.de?subject=subscribe>
>List-Id: <vendor-sec.lst.de>
>List-Unsubscribe: <https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec>,
>	<mailto:vendor-sec-request@lst.de?subject=unsubscribe>
>List-Archive: <https://www.lst.de/cgi-bin/mailman/private/vendor-sec/>
>X-Original-Date: Fri, 7 Jan 2005 12:17:52 +0000 (GMT)
>Date: Fri, 7 Jan 2005 12:17:52 +0000 (GMT)
>X-Virus-Scanned: by amavisd-new at scanhost.suse.de
>X-Spam-Status: No, hits=-4.9 tagged_above=-20.0 required=5.0 tests=BAYES_00
>X-Spam-Level: 
>Status: RO
>Content-Length: 1132
>Lines: 27
>
>On Thu, 6 Jan 2005, Alan Cox wrote:
>> On Iau, 2005-01-06 at 21:28, Hugh Dickins wrote:
>> > On Thu, 6 Jan 2005, Marcelo Tosatti wrote:
>> > 
>> > > So this is the v2.4.28 version (someone needs to check the correctness
>> > > of the GROWSDOWN case please - Willy?):
>> 
>> Parisc 2.4 was never afaik merged in full.
>
>Ah, that would explain why expand_stack seems incapable of handling
>VM_GROWSUP then, thanks.  (Though I'm then puzzled as to how any parisc
>source got into the 2.4 tree, if it can't even grow the user stack -
>perhaps they preassign a large stack area?)
>
>If that's the case, Marcelo, I think it would be a lot less confusing
>if you drop the VM_GROWSUP case (and the VM_GROWSDOWN test) from your
>2.4 racefix, and add a comment that this version of expand_stack does
>not support VM_GROWSUP.  To provide a VM_GROWSUP case for the racefix
>would mislead people into thinking that the function as a whole
>supports VM_GROWSUP, which it does not, so far as I can see.
>
>Hugh
>
>_______________________________________________
>Vendor Security mailing list
>Vendor Security@lst.de
>https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec
>
>From vendor-sec-admin@lst.de  Fri Jan  7 14:11:50 2005
>Return-Path: <vendor-sec-admin@lst.de>
>X-Original-To: thomas@wotan.suse.de
>Received: from hermes.suse.de (hermes.suse.de [149.44.160.1])
>	by wotan.suse.de (Postfix) with ESMTP id AB3181450FF
>	for <thomas@wotan.suse.de>; Fri,  7 Jan 2005 14:11:50 +0100 (CET)
>Received: by hermes.suse.de (Postfix)
>	id 946A113A7AB; Fri,  7 Jan 2005 14:11:50 +0100 (CET)
>Received: from scanhost.suse.de (scanhost.suse.de [149.44.160.36])
>	by hermes.suse.de (Postfix) with ESMTP
>	id 865EA13A6EA; Fri,  7 Jan 2005 14:11:50 +0100 (CET)
>Received: from hermes.suse.de ([149.44.160.1])
> by scanhost.suse.de (scanhost [149.44.160.36]) (amavisd-new, port 10025)
> with ESMTP id 14033-07; Fri,  7 Jan 2005 14:11:46 +0100 (CET)
>Received: from Cantor.suse.de (news.suse.de [195.135.220.2])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by hermes.suse.de (Postfix) with ESMTP
>	id A052C13A7C0; Fri,  7 Jan 2005 14:11:43 +0100 (CET)
>Received: from mail.lst.de (verein.lst.de [213.95.11.210])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by Cantor.suse.de (Postfix) with ESMTP id 67AD812F0946;
>	Fri,  7 Jan 2005 14:11:17 +0100 (CET)
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id j07DB66s012731;
>	Fri, 7 Jan 2005 14:11:06 +0100
>Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252])
>	by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id j07DAN6t012708
>	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
>	for <vendor-sec@lst.de>; Fri, 7 Jan 2005 14:10:24 +0100
>Received: from [127.0.0.1] (helo=logos.cnet)
>	by www.linux.org.uk with esmtp (Exim 4.33)
>	id 1Cmtsl-0000q9-Dh; Fri, 07 Jan 2005 13:10:23 +0000
>Received: by logos.cnet (Postfix, from userid 500)
>	id 5D973123A55; Fri,  7 Jan 2005 08:22:22 -0200 (BRST)
>From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
>To: Hugh Dickins <hugh@veritas.com>
>Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
>	Paul Starzetz <ihaquer@isec.pl>, vendor-sec <vendor-sec@lst.de>,
>	Andrew Morton <akpm@osdl.org>, mingo@elte.hu
>Subject: Re: [vendor-sec] page fault @ SMP
>Message-ID: <20050107102222.GB29176@logos.cnet>
>References: <1105050093.24896.277.camel@localhost.localdomain> <Pine.LNX.4.44.0501071205550.2742-100000@localhost.localdomain>
>Mime-Version: 1.0
>Content-Type: text/plain; charset=us-ascii
>Content-Disposition: inline
>In-Reply-To: <Pine.LNX.4.44.0501071205550.2742-100000@localhost.localdomain>
>User-Agent: Mutt/1.5.5.1i
>Sender: vendor-sec-admin@lst.de
>Errors-To: vendor-sec-admin@lst.de
>X-BeenThere: vendor-sec@lst.de
>X-Mailman-Version: 2.0.11
>Precedence: bulk
>List-Help: <mailto:vendor-sec-request@lst.de?subject=help>
>List-Post: <mailto:vendor-sec@lst.de>
>List-Subscribe: <https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec>,
>	<mailto:vendor-sec-request@lst.de?subject=subscribe>
>List-Id: <vendor-sec.lst.de>
>List-Unsubscribe: <https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec>,
>	<mailto:vendor-sec-request@lst.de?subject=unsubscribe>
>List-Archive: <https://www.lst.de/cgi-bin/mailman/private/vendor-sec/>
>X-Original-Date: Fri, 7 Jan 2005 08:22:22 -0200
>Date: Fri, 7 Jan 2005 08:22:22 -0200
>X-Virus-Scanned: by amavisd-new at scanhost.suse.de
>X-Spam-Status: No, hits=-4.9 tagged_above=-20.0 required=5.0 tests=BAYES_00
>X-Spam-Level: 
>Content-Length: 1338
>Lines: 31
>
>On Fri, Jan 07, 2005 at 12:17:52PM +0000, Hugh Dickins wrote:
>> On Thu, 6 Jan 2005, Alan Cox wrote:
>> > On Iau, 2005-01-06 at 21:28, Hugh Dickins wrote:
>> > > On Thu, 6 Jan 2005, Marcelo Tosatti wrote:
>> > > 
>> > > > So this is the v2.4.28 version (someone needs to check the correctness
>> > > > of the GROWSDOWN case please - Willy?):
>> > 
>> > Parisc 2.4 was never afaik merged in full.
>> 
>> Ah, that would explain why expand_stack seems incapable of handling
>> VM_GROWSUP then, thanks.  (Though I'm then puzzled as to how any parisc
>> source got into the 2.4 tree, if it can't even grow the user stack -
>> perhaps they preassign a large stack area?)
>
>Quoting willy:
>
><willy> ok, so we have our own expand_stack under an ifdef ARCH_STACK_GROWSUP
>
>> If that's the case, Marcelo, I think it would be a lot less confusing
>> if you drop the VM_GROWSUP case (and the VM_GROWSDOWN test) from your
>> 2.4 racefix, and add a comment that this version of expand_stack does
>> not support VM_GROWSUP.  To provide a VM_GROWSUP case for the racefix
>> would mislead people into thinking that the function as a whole
>> supports VM_GROWSUP, which it does not, so far as I can see.
>
>Agreed, will do.
>_______________________________________________
>Vendor Security mailing list
>Vendor Security@lst.de
>https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec
>
>From vendor-sec-admin@lst.de  Fri Jan  7 14:46:25 2005
>Return-Path: <vendor-sec-admin@lst.de>
>X-Original-To: thomas@wotan.suse.de
>Received: from hermes.suse.de (hermes.suse.de [149.44.160.1])
>	by wotan.suse.de (Postfix) with ESMTP id 6B200144907
>	for <thomas@wotan.suse.de>; Fri,  7 Jan 2005 14:46:25 +0100 (CET)
>Received: by hermes.suse.de (Postfix)
>	id 5C0AF13A7E2; Fri,  7 Jan 2005 14:46:25 +0100 (CET)
>Received: from scanhost.suse.de (scanhost.suse.de [149.44.160.36])
>	by hermes.suse.de (Postfix) with ESMTP
>	id 476AB13A7CA; Fri,  7 Jan 2005 14:46:25 +0100 (CET)
>Received: from hermes.suse.de ([149.44.160.1])
> by scanhost.suse.de (scanhost [149.44.160.36]) (amavisd-new, port 10025)
> with ESMTP id 26161-05; Fri,  7 Jan 2005 14:46:18 +0100 (CET)
>Received: from Cantor.suse.de (news.suse.de [195.135.220.2])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by hermes.suse.de (Postfix) with ESMTP
>	id C07C913A7C3; Fri,  7 Jan 2005 14:46:18 +0100 (CET)
>Received: from mail.lst.de (verein.lst.de [213.95.11.210])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by Cantor.suse.de (Postfix) with ESMTP id 93EF312F57D0;
>	Fri,  7 Jan 2005 14:46:18 +0100 (CET)
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id j07Dk56s013634;
>	Fri, 7 Jan 2005 14:46:05 +0100
>Received: from MTVMIME01.enterprise.veritas.com (bay-bridge.veritas.com [143.127.3.10])
>	by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id j07DjN6s013605
>	for <vendor-sec@lst.de>; Fri, 7 Jan 2005 14:45:24 +0100
>Received: from megami.veritas.com (unverified) by 
>    MTVMIME01.enterprise.veritas.com (Content Technologies SMTPRS 4.3.12) 
>    with SMTP id <T6e581d4c6c0a8911516d8@MTVMIME01.enterprise.veritas.com>; 
>    Fri, 7 Jan 2005 05:45:17 -0800
>Received: from goblin.wat.veritas.com ([10.10.97.50]) (1442 bytes) by 
>    megami.veritas.com via sendmail with P:esmtp/R:smart_host/T:smtp 
>    (sender: <hugh@veritas.com>) id <m1CmuQW-00019EC@megami.veritas.com> for 
>    <akpm@osdl.org>; Fri, 7 Jan 2005 05:45:16 -0800 (PST) 
>    (Smail-3.2.0.101 1997-Dec-17 #15 built 2001-Aug-30)
>From: Hugh Dickins <hugh@veritas.com>
>X-X-Sender: hugh@localhost.localdomain
>To: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
>Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
>	Paul Starzetz <ihaquer@isec.pl>, vendor-sec <vendor-sec@lst.de>,
>	Andrew Morton <akpm@osdl.org>, Matthew Wilcox <willy@debian.org>,
>	<mingo@elte.hu>
>Subject: Re: [vendor-sec] page fault @ SMP
>In-Reply-To: <20050107102222.GB29176@logos.cnet>
>Message-ID: <Pine.LNX.4.44.0501071340300.2788-100000@localhost.localdomain>
>MIME-Version: 1.0
>Content-Type: text/plain; charset="us-ascii"
>Sender: vendor-sec-admin@lst.de
>Errors-To: vendor-sec-admin@lst.de
>X-BeenThere: vendor-sec@lst.de
>X-Mailman-Version: 2.0.11
>Precedence: bulk
>List-Help: <mailto:vendor-sec-request@lst.de?subject=help>
>List-Post: <mailto:vendor-sec@lst.de>
>List-Subscribe: <https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec>,
>	<mailto:vendor-sec-request@lst.de?subject=subscribe>
>List-Id: <vendor-sec.lst.de>
>List-Unsubscribe: <https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec>,
>	<mailto:vendor-sec-request@lst.de?subject=unsubscribe>
>List-Archive: <https://www.lst.de/cgi-bin/mailman/private/vendor-sec/>
>X-Original-Date: Fri, 7 Jan 2005 13:44:56 +0000 (GMT)
>Date: Fri, 7 Jan 2005 13:44:56 +0000 (GMT)
>X-Virus-Scanned: by amavisd-new at scanhost.suse.de
>X-Spam-Status: No, hits=-4.9 tagged_above=-20.0 required=5.0 tests=BAYES_00
>X-Spam-Level: 
>Content-Length: 713
>Lines: 20
>
>On Fri, 7 Jan 2005, Marcelo Tosatti wrote:
>> On Fri, Jan 07, 2005 at 12:17:52PM +0000, Hugh Dickins wrote:
>> > 
>> > Ah, that would explain why expand_stack seems incapable of handling
>> > VM_GROWSUP then, thanks.  (Though I'm then puzzled as to how any parisc
>> > source got into the 2.4 tree, if it can't even grow the user stack -
>> > perhaps they preassign a large stack area?)
>> 
>> Quoting willy:
>> 
>> <willy> ok, so we have our own expand_stack under an ifdef ARCH_STACK_GROWSUP
>
>Yet they've _never_ submitted that code to your 2.4 tree?  Odd...
>
>Hugh
>
>_______________________________________________
>Vendor Security mailing list
>Vendor Security@lst.de
>https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec
>
>From vendor-sec-admin@lst.de  Fri Jan  7 16:19:27 2005
>Return-Path: <vendor-sec-admin@lst.de>
>X-Original-To: thomas@wotan.suse.de
>Received: from hermes.suse.de (hermes.suse.de [149.44.160.1])
>	by wotan.suse.de (Postfix) with ESMTP id CCCEF147639
>	for <thomas@wotan.suse.de>; Fri,  7 Jan 2005 16:19:21 +0100 (CET)
>Received: by hermes.suse.de (Postfix)
>	id E795E13AD74; Fri,  7 Jan 2005 16:14:27 +0100 (CET)
>Received: from scanhost.suse.de (scanhost.suse.de [149.44.160.36])
>	by hermes.suse.de (Postfix) with ESMTP
>	id DA9D913AD6C; Fri,  7 Jan 2005 16:14:27 +0100 (CET)
>Received: from hermes.suse.de ([149.44.160.1])
> by scanhost.suse.de (scanhost [149.44.160.36]) (amavisd-new, port 10025)
> with ESMTP id 09005-04; Fri,  7 Jan 2005 16:14:23 +0100 (CET)
>Received: from Cantor.suse.de (mail.suse.de [195.135.220.2])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by hermes.suse.de (Postfix) with ESMTP
>	id 246DD13AD68; Fri,  7 Jan 2005 16:14:23 +0100 (CET)
>Received: from mail.lst.de (verein.lst.de [213.95.11.210])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by Cantor.suse.de (Postfix) with ESMTP id ECB0612F61B5;
>	Fri,  7 Jan 2005 16:14:22 +0100 (CET)
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id j07FEB6s015154;
>	Fri, 7 Jan 2005 16:14:11 +0100
>Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252])
>	by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id j07FDL6t015134
>	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
>	for <vendor-sec@lst.de>; Fri, 7 Jan 2005 16:13:22 +0100
>Received: from willy by www.linux.org.uk with local (Exim 4.33)
>	id 1Cmvnl-0006Mu-35; Fri, 07 Jan 2005 15:13:21 +0000
>From: Matthew Wilcox <matthew@wil.cx>
>To: Hugh Dickins <hugh@veritas.com>
>Cc: Marcelo Tosatti <marcelo.tosatti@cyclades.com>,
>	Alan Cox <alan@lxorguk.ukuu.org.uk>, Paul Starzetz <ihaquer@isec.pl>,
>	vendor-sec <vendor-sec@lst.de>, Andrew Morton <akpm@osdl.org>,
>	Matthew Wilcox <willy@debian.org>, mingo@elte.hu
>Subject: Re: [vendor-sec] page fault @ SMP
>Message-ID: <20050107151321.GU27371@parcelfarce.linux.theplanet.co.uk>
>References: <20050107102222.GB29176@logos.cnet> <Pine.LNX.4.44.0501071340300.2788-100000@localhost.localdomain>
>Mime-Version: 1.0
>Content-Type: text/plain; charset=us-ascii
>Content-Disposition: inline
>In-Reply-To: <Pine.LNX.4.44.0501071340300.2788-100000@localhost.localdomain>
>User-Agent: Mutt/1.4.1i
>Sender: vendor-sec-admin@lst.de
>Errors-To: vendor-sec-admin@lst.de
>X-BeenThere: vendor-sec@lst.de
>X-Mailman-Version: 2.0.11
>Precedence: bulk
>List-Help: <mailto:vendor-sec-request@lst.de?subject=help>
>List-Post: <mailto:vendor-sec@lst.de>
>List-Subscribe: <https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec>,
>	<mailto:vendor-sec-request@lst.de?subject=subscribe>
>List-Id: <vendor-sec.lst.de>
>List-Unsubscribe: <https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec>,
>	<mailto:vendor-sec-request@lst.de?subject=unsubscribe>
>List-Archive: <https://www.lst.de/cgi-bin/mailman/private/vendor-sec/>
>X-Original-Date: Fri, 7 Jan 2005 15:13:21 +0000
>Date: Fri, 7 Jan 2005 15:13:21 +0000
>X-Virus-Scanned: by amavisd-new at scanhost.suse.de
>X-Spam-Status: No, hits=-4.9 tagged_above=-20.0 required=5.0 tests=BAYES_00
>X-Spam-Level: 
>Content-Length: 1405
>Lines: 30
>
>On Fri, Jan 07, 2005 at 01:44:56PM +0000, Hugh Dickins wrote:
>> On Fri, 7 Jan 2005, Marcelo Tosatti wrote:
>> > On Fri, Jan 07, 2005 at 12:17:52PM +0000, Hugh Dickins wrote:
>> > > 
>> > > Ah, that would explain why expand_stack seems incapable of handling
>> > > VM_GROWSUP then, thanks.  (Though I'm then puzzled as to how any parisc
>> > > source got into the 2.4 tree, if it can't even grow the user stack -
>> > > perhaps they preassign a large stack area?)
>> > 
>> > Quoting willy:
>> > 
>> > <willy> ok, so we have our own expand_stack under an ifdef ARCH_STACK_GROWSUP
>> 
>> Yet they've _never_ submitted that code to your 2.4 tree?  Odd...
>
>I think it was probably submitted once and dropped.  Merging parisc into
>the 2.4 tree has never been a high priority.  Our expand_stack is in 2.6
>which is all we really care about.
>
>-- 
>"Next the statesmen will invent cheap lies, putting the blame upon 
>the nation that is attacked, and every man will be glad of those
>conscience-soothing falsities, and will diligently study them, and refuse
>to examine any refutations of them; and thus he will by and by convince 
>himself that the war is just, and will thank God for the better sleep 
>he enjoys after this process of grotesque self-deception." -- Mark Twain
>_______________________________________________
>Vendor Security mailing list
>Vendor Security@lst.de
>https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec
>
>From vendor-sec-admin@lst.de  Fri Jan  7 14:11:45 2005
>Return-Path: <vendor-sec-admin@lst.de>
>X-Original-To: thomas@wotan.suse.de
>Received: from hermes.suse.de (hermes.suse.de [149.44.160.1])
>	by wotan.suse.de (Postfix) with ESMTP id 7B0641450FE
>	for <thomas@wotan.suse.de>; Fri,  7 Jan 2005 14:11:45 +0100 (CET)
>Received: by hermes.suse.de (Postfix)
>	id 5F1D613A7CB; Fri,  7 Jan 2005 14:11:45 +0100 (CET)
>Received: from scanhost.suse.de (scanhost.suse.de [149.44.160.36])
>	by hermes.suse.de (Postfix) with ESMTP
>	id 4ED0913A797; Fri,  7 Jan 2005 14:11:45 +0100 (CET)
>Received: from hermes.suse.de ([149.44.160.1])
> by scanhost.suse.de (scanhost [149.44.160.36]) (amavisd-new, port 10025)
> with ESMTP id 10182-17; Fri,  7 Jan 2005 14:11:41 +0100 (CET)
>Received: from Cantor.suse.de (mail.suse.de [195.135.220.2])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by hermes.suse.de (Postfix) with ESMTP
>	id 2449D13A76B; Fri,  7 Jan 2005 14:11:41 +0100 (CET)
>Received: from mail.lst.de (verein.lst.de [213.95.11.210])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by Cantor.suse.de (Postfix) with ESMTP id 953EE12EFE1C;
>	Fri,  7 Jan 2005 14:11:12 +0100 (CET)
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id j07DAG6s012639;
>	Fri, 7 Jan 2005 14:10:16 +0100
>Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252])
>	by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id j07D9J6t012614
>	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
>	for <vendor-sec@lst.de>; Fri, 7 Jan 2005 14:09:19 +0100
>Received: from [127.0.0.1] (helo=logos.cnet)
>	by www.linux.org.uk with esmtp (Exim 4.33)
>	id 1Cmtrh-0000mD-8g; Fri, 07 Jan 2005 13:09:17 +0000
>Received: by logos.cnet (Postfix, from userid 500)
>	id BF3F7123A55; Fri,  7 Jan 2005 08:21:16 -0200 (BRST)
>From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
>To: Hugh Dickins <hugh@veritas.com>
>Cc: Paul Starzetz <ihaquer@isec.pl>, vendor-sec <vendor-sec@lst.de>,
>	Andrew Morton <akpm@osdl.org>, mingo@elte.hu
>Subject: Re: [vendor-sec] page fault @ SMP
>Message-ID: <20050107102116.GA29176@logos.cnet>
>References: <20050106161757.GA23289@logos.cnet> <Pine.LNX.4.44.0501062107220.3143-100000@localhost.localdomain>
>Mime-Version: 1.0
>Content-Type: text/plain; charset=us-ascii
>Content-Disposition: inline
>In-Reply-To: <Pine.LNX.4.44.0501062107220.3143-100000@localhost.localdomain>
>User-Agent: Mutt/1.5.5.1i
>Sender: vendor-sec-admin@lst.de
>Errors-To: vendor-sec-admin@lst.de
>X-BeenThere: vendor-sec@lst.de
>X-Mailman-Version: 2.0.11
>Precedence: bulk
>List-Help: <mailto:vendor-sec-request@lst.de?subject=help>
>List-Post: <mailto:vendor-sec@lst.de>
>List-Subscribe: <https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec>,
>	<mailto:vendor-sec-request@lst.de?subject=subscribe>
>List-Id: <vendor-sec.lst.de>
>List-Unsubscribe: <https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec>,
>	<mailto:vendor-sec-request@lst.de?subject=unsubscribe>
>List-Archive: <https://www.lst.de/cgi-bin/mailman/private/vendor-sec/>
>X-Original-Date: Fri, 7 Jan 2005 08:21:16 -0200
>Date: Fri, 7 Jan 2005 08:21:16 -0200
>X-Virus-Scanned: by amavisd-new at scanhost.suse.de
>X-Spam-Status: No, hits=-5.9 tagged_above=-20.0 required=5.0 tests=BAYES_00,
> MY_LINUX
>X-Spam-Level: 
>Content-Length: 3296
>Lines: 102
>
>On Thu, Jan 06, 2005 at 09:28:43PM +0000, Hugh Dickins wrote:
>> On Thu, 6 Jan 2005, Marcelo Tosatti wrote:
>> > 
>> > The race looks valid to me.
>> 
>> Me too.
>> 
>> > So this is the v2.4.28 version (someone needs to check the correctness
>> > of the GROWSDOWN case please - Willy?):
>> 
>> I think it's the GROWSUP case we need help with.
>
>Yep
>
>> > --- linux-2.4.28.orig/include/linux/mm.h	2005-01-06 13:31:40.730506624 -0200
>> > +++ linux-2.4.28/include/linux/mm.h	2005-01-06 15:53:51.383650224 -0200
>> > @@ -647,12 +647,22 @@
>> >  	unsigned long grow;
>> >  
>> >  	/*
>> > -	 * vma->vm_start/vm_end cannot change under us because the caller is required
>> > -	 * to hold the mmap_sem in write mode. We need to get the spinlock only
>> > -	 * before relocating the vma range ourself.
>> > +	 * vma->vm_start/vm_end cannot change under us because the caller
>> > +	 * is required to hold the mmap_sem in read mode.  We need the
>> > +	 * page_table_lock lock to serialize against concurrent expand_stacks.
>> >  	 */
>> >  	address &= PAGE_MASK;
>> >   	spin_lock(&vma->vm_mm->page_table_lock);
>> > +
>> > +	/* already expanded while we were spinning? */
>> > +	if ((vma->vm_flags & VM_GROWSDOWN) && vma->vm_start <= address) {
>> > +		spin_unlock(vma->vm_mm->page_table_lock);
>> 
>> Needs to be "spin_unlock(&vma->...", but otherwise looks okay.
>> 
>> > +		return 0;
>> > +	} else if ((vma->vm_flags & VM_GROWSUP) && vma->vm_start >= address) {
>> > +		spin_unlock(vma->vm_mm->page_table_lock);
>> 
>> Similarly needs to be "spin_unlock(&vma->".
>
>Yep, OK.
>
>> But I do not understand
>> how the 2.4 expand_stack works with VM_GROWSUP at all.  Help!
>
>It does not support VM_GROWSUP at all. My mistake.
>
>> > +		return 0;
>> > +	}
>> > +
>> >  	grow = (vma->vm_start - address) >> PAGE_SHIFT;
>> >  	if (vma->vm_end - address > current->rlim[RLIMIT_STACK].rlim_cur ||
>> >  	    ((vma->vm_mm->total_vm + grow) << PAGE_SHIFT) > current->rlim[RLIMIT_AS].rlim_cur) {
>> > 
>> > And the v2.6 version (someone needs to check the correctness of the GROSDOWN case please):
>> > 
>> > --- linux-2.6.10-mm1.orig/mm/mmap.c	2005-01-05 15:58:26.000000000 -0200
>> > +++ linux-2.6.10-mm1/mm/mmap.c	2005-01-06 15:42:19.371852008 -0200
>> > @@ -1373,6 +1373,13 @@
>> >  	 */
>> >  	address += 4 + PAGE_SIZE - 1;
>> >  	address &= PAGE_MASK;
>> > +
>> > +	/* already expanded while waiting for anon_vma lock? */
>> > +	if (vma->vm_start >= address) {
>> 
>> No, this GROWSUP case needs to say "if (vma->vm_end >= address) {"
>> doesn't it?  See grow below, and it's vm_end which gets adjusted.
>
>I'll update the patch, thanks.
>
>> > +		anon_vma_unlock(vma);
>> > +		return 0;
>> > +	}
>> > +
>> >  	grow = (address - vma->vm_end) >> PAGE_SHIFT;
>> >  
>> >  	/* Overcommit.. */
>> > @@ -1432,6 +1439,12 @@
>> >  		return -ENOMEM;
>> >  	anon_vma_lock(vma);
>> >  
>> > +	/* already expanded while waiting for anon_vma lock? */
>> > +	if (vma->vm_start <= address) {
>> > +		anon_vma_unlock(vma);
>> > +		return 0;
>> > +	}
>> > +
>> 
>> Looks good.
>> 
>> >  	/*
>> >  	 * vma->vm_start/vm_end cannot change under us because the caller
>> >  	 * is required to hold the mmap_sem in read mode.  We need the
>
>Thanks for the review!
>_______________________________________________
>Vendor Security mailing list
>Vendor Security@lst.de
>https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec
>
>From vendor-sec-admin@lst.de  Fri Jan  7 12:02:40 2005
>Return-Path: <vendor-sec-admin@lst.de>
>X-Original-To: thomas@wotan.suse.de
>Received: from hermes.suse.de (hermes.suse.de [149.44.160.1])
>	by wotan.suse.de (Postfix) with ESMTP id 8709E1447C7
>	for <thomas@wotan.suse.de>; Fri,  7 Jan 2005 12:02:40 +0100 (CET)
>Received: by hermes.suse.de (Postfix)
>	id 6F99213A55C; Fri,  7 Jan 2005 12:02:40 +0100 (CET)
>Received: from scanhost.suse.de (scanhost.suse.de [149.44.160.36])
>	by hermes.suse.de (Postfix) with ESMTP
>	id 5B2BE13A3DE; Fri,  7 Jan 2005 12:02:40 +0100 (CET)
>Received: from hermes.suse.de ([149.44.160.1])
> by scanhost.suse.de (scanhost [149.44.160.36]) (amavisd-new, port 10025)
> with ESMTP id 03271-05; Fri,  7 Jan 2005 12:02:37 +0100 (CET)
>Received: from Cantor.suse.de (cantor.suse.de [195.135.220.2])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by hermes.suse.de (Postfix) with ESMTP
>	id A45C813AAE4; Fri,  7 Jan 2005 12:00:14 +0100 (CET)
>Received: from mail.lst.de (verein.lst.de [213.95.11.210])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by Cantor.suse.de (Postfix) with ESMTP id 7C4EB12F453C;
>	Fri,  7 Jan 2005 12:00:14 +0100 (CET)
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id j07B056s009271;
>	Fri, 7 Jan 2005 12:00:05 +0100
>Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31])
>	by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id j07Ax36t009247
>	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
>	for <vendor-sec@lst.de>; Fri, 7 Jan 2005 11:59:04 +0100
>Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
>	by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j07Awuwg010500;
>	Fri, 7 Jan 2005 05:59:01 -0500
>Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156])
>	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j07Awtr25892;
>	Fri, 7 Jan 2005 05:58:55 -0500
>Received: from dell1.moose.awe.com (IDENT:U2FsdGVkX1/J6CQNQV3Xh4z61p7m8ZX7DMaf6a8g53M@vpn50-39.rdu.redhat.com [172.16.50.39])
>	by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id j07AwtlL018282;
>	Fri, 7 Jan 2005 05:58:55 -0500
>Received: from dell1.moose.awe.com
>	([127.0.0.1] helo=localhost ident=[U2FsdGVkX1/7BybpXEdl4I4lb2jY0dUp8Ur8EyUFIAw=])
>	by dell1.moose.awe.com with esmtp (Exim 4.05)
>	id 1CmrpU-0000BA-00; Fri, 07 Jan 2005 10:58:52 +0000
>From: Mark J Cox <mjc@redhat.com>
>To: Paul Starzetz <ihaquer@isec.pl>
>Cc: vendor-sec <vendor-sec@lst.de>
>Subject: Re: [vendor-sec] page fault @ SMP
>In-Reply-To: <Pine.LNX.4.44.0501052138110.2904-100000@isec.pl>
>Message-ID: <0501071049031.32723@dell1.moose.awe.com>
>References: <Pine.LNX.4.44.0501052138110.2904-100000@isec.pl>
>X-PGP-Public-Key: http://www.awe.com/mark/pgpkey.asc
>X-PGP-Fingerprint: 7B79 19FA 716B 8725 0E77 21E5 52D9 83BF
>MIME-Version: 1.0
>Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>Sender: vendor-sec-admin@lst.de
>Errors-To: vendor-sec-admin@lst.de
>X-BeenThere: vendor-sec@lst.de
>X-Mailman-Version: 2.0.11
>Precedence: bulk
>List-Help: <mailto:vendor-sec-request@lst.de?subject=help>
>List-Post: <mailto:vendor-sec@lst.de>
>List-Subscribe: <https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec>,
>	<mailto:vendor-sec-request@lst.de?subject=subscribe>
>List-Id: <vendor-sec.lst.de>
>List-Unsubscribe: <https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec>,
>	<mailto:vendor-sec-request@lst.de?subject=unsubscribe>
>List-Archive: <https://www.lst.de/cgi-bin/mailman/private/vendor-sec/>
>X-Original-Date: Fri, 7 Jan 2005 10:58:52 +0000 (GMT)
>Date: Fri, 7 Jan 2005 10:58:52 +0000 (GMT)
>X-Virus-Scanned: by amavisd-new at scanhost.suse.de
>X-Spam-Status: No, hits=-4.9 tagged_above=-20.0 required=5.0 tests=BAYES_00
>X-Spam-Level: 
>Status: RO
>Content-Length: 1089
>Lines: 32
>
>On Wed, 5 Jan 2005, Paul Starzetz wrote:
>> I have found an exploitable flaw in the page fault handler, however only
>> in the SMP case.
>
>We noticed yesterday that our kernel folks had previously already fixed 
>this in a December 20th update to our kernels - it was in response to a 
>bug logged by one of our customers and didn't get escalated to the 
>security team as it wasn't seen to have a security consequence at the 
>time:
>
>http://rhn.redhat.com/errata/RHBA-2004-550.html contains
>kernel-2.4.21-27.EL.src.rpm which has the following patch inside:
>
>+
>+       /* check if another thread has already expanded the stack */
>+       if (address >= vma->vm_start) {
>+               spin_unlock(&vma->vm_mm->page_table_lock);
>+               vm_validate_enough("exiting expand_stack - NOTHING TO 
>DO");
>+               return 0;
>+       }
>+
>
>This fix was also scheduled for a RHEL2.1 kernel update, but that isn't 
>out yet.
>
>Cheers,
>Mark
>_______________________________________________
>Vendor Security mailing list
>Vendor Security@lst.de
>https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec
>
>From vendor-sec-admin@lst.de  Fri Jan  7 12:21:02 2005
>Return-Path: <vendor-sec-admin@lst.de>
>X-Original-To: thomas@wotan.suse.de
>Received: from hermes.suse.de (hermes.suse.de [149.44.160.1])
>	by wotan.suse.de (Postfix) with ESMTP id 69E0B1447D2
>	for <thomas@wotan.suse.de>; Fri,  7 Jan 2005 12:21:02 +0100 (CET)
>Received: by hermes.suse.de (Postfix)
>	id 5BB8B13A51D; Fri,  7 Jan 2005 12:21:02 +0100 (CET)
>Received: from scanhost.suse.de (scanhost.suse.de [149.44.160.36])
>	by hermes.suse.de (Postfix) with ESMTP
>	id 408F013A363; Fri,  7 Jan 2005 12:21:02 +0100 (CET)
>Received: from hermes.suse.de ([149.44.160.1])
> by scanhost.suse.de (scanhost [149.44.160.36]) (amavisd-new, port 10025)
> with ESMTP id 02109-06; Fri,  7 Jan 2005 12:20:50 +0100 (CET)
>Received: from Cantor.suse.de (mail.suse.de [195.135.220.2])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by hermes.suse.de (Postfix) with ESMTP
>	id 9727B13A7FC; Fri,  7 Jan 2005 12:18:23 +0100 (CET)
>Received: from mail.lst.de (verein.lst.de [213.95.11.210])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by Cantor.suse.de (Postfix) with ESMTP id 6E7BE12F46A3;
>	Fri,  7 Jan 2005 12:18:23 +0100 (CET)
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id j07BI86s009590;
>	Fri, 7 Jan 2005 12:18:08 +0100
>Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31])
>	by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id j07BH76t009551
>	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
>	for <vendor-sec@lst.de>; Fri, 7 Jan 2005 12:17:08 +0100
>Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
>	by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j07BH0hE015216;
>	Fri, 7 Jan 2005 06:17:05 -0500
>Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156])
>	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j07BH0r30179;
>	Fri, 7 Jan 2005 06:17:00 -0500
>Received: from dell1.moose.awe.com (IDENT:U2FsdGVkX1+6WxZ1uNb7YQQyFzCsUN5MG5c0DOclnwo@vpn50-39.rdu.redhat.com [172.16.50.39])
>	by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id j07BGxlL021083;
>	Fri, 7 Jan 2005 06:17:00 -0500
>Received: from dell1.moose.awe.com
>	([127.0.0.1] helo=localhost ident=[U2FsdGVkX18t17mmSHgJMnjTolvyfQfK1ArIPFjpSBE=])
>	by dell1.moose.awe.com with esmtp (Exim 4.05)
>	id 1Cms6z-0000Ez-00; Fri, 07 Jan 2005 11:16:57 +0000
>From: Mark J Cox <mjc@redhat.com>
>To: Paul Starzetz <ihaquer@isec.pl>
>Cc: vendor-sec <vendor-sec@lst.de>
>Subject: Re: [vendor-sec] page fault @ SMP
>In-Reply-To: <Pine.LNX.4.44.0501052138110.2904-100000@isec.pl>
>Message-ID: <0501071115260.32723@dell1.moose.awe.com>
>References: <Pine.LNX.4.44.0501052138110.2904-100000@isec.pl>
>X-PGP-Public-Key: http://www.awe.com/mark/pgpkey.asc
>X-PGP-Fingerprint: 7B79 19FA 716B 8725 0E77 21E5 52D9 83BF
>MIME-Version: 1.0
>Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>Sender: vendor-sec-admin@lst.de
>Errors-To: vendor-sec-admin@lst.de
>X-BeenThere: vendor-sec@lst.de
>X-Mailman-Version: 2.0.11
>Precedence: bulk
>List-Help: <mailto:vendor-sec-request@lst.de?subject=help>
>List-Post: <mailto:vendor-sec@lst.de>
>List-Subscribe: <https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec>,
>	<mailto:vendor-sec-request@lst.de?subject=subscribe>
>List-Id: <vendor-sec.lst.de>
>List-Unsubscribe: <https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec>,
>	<mailto:vendor-sec-request@lst.de?subject=unsubscribe>
>List-Archive: <https://www.lst.de/cgi-bin/mailman/private/vendor-sec/>
>X-Original-Date: Fri, 7 Jan 2005 11:16:57 +0000 (GMT)
>Date: Fri, 7 Jan 2005 11:16:57 +0000 (GMT)
>X-Virus-Scanned: by amavisd-new at scanhost.suse.de
>X-Spam-Status: No, hits=-4.9 tagged_above=-20.0 required=5.0 tests=BAYES_00
>X-Spam-Level: 
>Status: RO
>Content-Length: 324
>Lines: 11
>
>> I have found an exploitable flaw in the page fault handler, however only
>> in the SMP case.
>
>Nearly forgot.... please use CAN-2005-0001 for this issue.
>
>Cheers, Mark
>
>_______________________________________________
>Vendor Security mailing list
>Vendor Security@lst.de
>https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec
>

Actions: View

Attachments on bug 64652: 27460 | 27461 | 27462 | 27606 | 27626 | 27628 | 27647