Attachment 15808 Details for Bug 49117

full mremap thread from vendor-sec (so far)

mremap.thread (text/plain), 155.42 KB, created by Olaf Kirch on 2004-01-30 00:33:25 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Olaf Kirch

Created: 2004-01-30 00:33:25 UTC

Size: 155.42 KB

patch

obsolete

>From vendor-sec-admin@lst.de  Fri Jan 23 13:41:13 2004
>Return-Path: <vendor-sec-admin@lst.de>
>Received: from Hermes.suse.de (Hermes.suse.de [10.0.0.1])
>	by wotan.suse.de (Postfix) with ESMTP id 26DB31071A
>	for <okir@wotan.suse.de>; Fri, 23 Jan 2004 13:41:13 +0100 (CET)
>Received: by Hermes.suse.de (Postfix)
>	id 216788042; Fri, 23 Jan 2004 13:41:13 +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 1BEB23657
>	for <okir@suse.de>; Fri, 23 Jan 2004 13:41:13 +0100 (CET)
>Received: from mail.lst.de (verein.lst.de [212.34.189.10])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by Cantor.suse.de (Postfix) with ESMTP id EAE048D867
>	for <okir@suse.de>; Fri, 23 Jan 2004 13:41:12 +0100 (CET)
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NCfCe6025375
>	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
>	for <okir@suse.de>; Fri, 23 Jan 2004 13:41:12 +0100
>Received: (from cyrus@localhost)
>	by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i0NCfC8x025373
>	for okir@suse.de; Fri, 23 Jan 2004 13:41:12 +0100
>Received: from mail.lst.de ([unix socket])
>	by mail.lst.de (Cyrus v2.1.15-IPv6-Debian-2.1.15-0woody.1.0) with LMTP; Fri, 23 Jan 2004 13:41:12 +0100
>X-Sieve: CMU Sieve 2.2
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NCfBe5025369;
>	Fri, 23 Jan 2004 13:41:11 +0100
>Received: from isec.pl (isec.pl [193.110.121.50])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NCehe5025350
>	for <vendor-sec@lst.de>; Fri, 23 Jan 2004 13:40:43 +0100
>Received: by isec.pl (Postfix, from userid 500)
>	id B82D03F22; Fri, 23 Jan 2004 13:40:25 +0100 (CET)
>Received: from localhost (localhost [127.0.0.1])
>	by isec.pl (Postfix) with ESMTP
>	id A681A17695; Fri, 23 Jan 2004 13:40:25 +0100 (CET)
>From: Paul Starzetz <ihaquer@isec.pl>
>Reply-To: security@isec.pl
>To: vendor-sec <vendor-sec@lst.de>
>Message-ID: <Pine.LNX.4.44.0401231327070.21007-100000@isec.pl>
>MIME-Version: 1.0
>Content-Type: TEXT/PLAIN; charset=US-ASCII
>X-Spam-Score: -4.901 () BAYES_00
>X-Scanned-By: MIMEDefang 2.39
>Subject: [vendor-sec] Another serious mremap() vulnerability
>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/>
>Date: Fri, 23 Jan 2004 13:40:20 +0100 (CET)
>X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on 
>	wotan.suse.de
>X-Spam-Level: 
>X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
>	version=2.61
>Status: RO
>Content-Length: 6419
>Lines: 173
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Synopsis:  Linux kernel do_mremap VMA limit local privilege escalation
>           vulnerability
>Product:   Linux kernel
>Version:   2.4 up to 2.4.24 and 2.6.0
>Vendor:    http://www.kernel.org/
>URL:       not assigned
>CVE:       not assigned
>Author:    Paul Starzetz <ihaquer@isec.pl>, Wojciech Purczynski
>           <cliph@isec.pl>
>Date:      January 23, 2004
>
>
>Issue:
>======
>
>A critical security vulnerability has been found in the Linux kernel 
>memory management code inside the mremap(2) system call due to missing 
>function return value check. This bug is completely unrelated to the 
>mremap bug disclosed on 5.1.2004 except concerning the same internal 
>kernel function code.
>
>
>Details:
>========
>
>The Linux kernel manages a list of user addressable valid memory 
>locations on a per process basis. Every process owns a single linked 
>list of so called virtual memory area descriptors (called from now on 
>just VMAs). Every VMA describes the start of a valid memory region, its 
>length and moreover various memory flags like page protection. 
>
>Every VMA in the list corresponds to a part of the process's page table. 
>The page table contains descriptors (in short page table entries PTEs) 
>of physical memory pages seen by the process. The VMA descriptor can be 
>thus understood as a high level description of a particual region of the 
>process's page table storing PTE properties like page R/W flag and so 
>on.
>
>The mremap() system call provides resizing (shrinking or growing) as 
>well as moving of existing virtual memory areas or any of its parts 
>across process's addressable space.
>
>Moving a part of the virtual memory from inside a VMA area to a new 
>location requires creation of a new VMA descriptor as well as copying 
>the underlying page table entries described by the VMA from the old to 
>the new location in the process's page table.
>
>To accomplish this task the do_mremap code calls the do_munmap() 
>internal kernel function to remove any potentially existing old memory 
>mapping in the new location. Unfortunately the code doesn't test the 
>return value of the do_munmap() function which may fail if the maximum 
>number of available VMA descriptors has been exceeded. This happens if 
>the new VMA location goes into the middle of an existing memory mapping 
>and the process's limit on the number of VMAs has been reached (which is 
>currently 65535).
>
>This can be illustrated with the following ASCII-art picture where the 
>corresponding page table entries (PTEs) have been marked with X/Y:
>
>Before mremap():
>
>(YYYYYYYYYYYYYYYYYYYYYYYY)     (XXXXXXXXXXXXX)
>[----------VMA1----------]     [-----VMA2----]
>      [REMAPPED-VMA] <---------------|
>
>
>After mremap() without VMA limit:
>
>(YYYY)(XXXXXXXXXXXX)(YYYY)
>[VMA3][REMAPPED-VMA][VMA4]
>
>
>After mremap() but VMA limit:
>
>(YYYYYXXXXXXXXXXXXYYYYY)
>[---------VMA1---------]
>     [REMAPPED-VMA]
>
>
>After the maximum number of VMAs in the process's VMA list has been 
>reached do_munmap() will refuse to create the necessary VMA hole because 
>it would split the original VMA in two disjoint VMA areas exceeding the 
>VMA descriptor limit.
>
>Due to the missing return value check after trying to unmap the middle 
>of the VMA1 (this is the first invocation of do_munmap inside do_mremap) 
>the corresponding page table entries from VMA2 are still inserted into 
>the page table location described by VMA1 thus being subject to VMA1 
>page protection flags. It must be also mentioned that the original PTEs 
>in the VMA1 are lost thus leaving the corresponding page frames locked 
>in memory.
>
>The kernel also tries to insert the overlapping VMA area into the VMA 
>descriptor list but this fails due to further checks in the low level 
>VMA manipulation code. The low level VMA list check in the 2.4 and 2.6 
>kernel versions just call BUG() therefore terminating the malicious 
>process.
>
>We were able to create a proof-of-concept exploit code moving page table 
>entries from one VMA to another one with different PTE protection flags. 
>The moved page table entries could be then manipulated for example to 
>gain write access to normaly read-only pages mapping disk files like 
>/etc/passwd and so on.
>
>There are also two other unchecked calls to do_munmap() and we believe 
>that the second occurence of unchecked do_munmap is very easily 
>exploitable. The second occurence takes place if the VMA to be remapped 
>is beeing truncated in place. However do_munmap can also fail on an 
>execptional low memory condition while trying to preallocate a VMA 
>descriptor.
>
>
>Impact:
>=======
>
>Since no special privileges are required to use the mremap(2) system 
>call any process may use its unexpected behavior to disrupt the kernel 
>memory management subsystem.
>
>Proper exploitation of this vulnerability may lead to local privilege 
>escalation giving an attacker full super-user privileges but may also 
>include execution of arbitrary code with kernel level access. The 
>vulnerability leads also to a denial-of-service attack on the available 
>system memory.
>
>Tested and known to be vulnerable kernel versions are all <= 2.4.24 and 
>2.6.0. All users are encouraged to patch all vulnerable systems as soon 
>as appropriate vendor patches are released.
>
>
>Credits:
>========
>
>Paul Starzetz <ihaquer@isec.pl> has identified the vulnerability and 
>performed further research. COPYING, DISTRIBUTION, AND MODIFICATION OF 
>INFORMATION PRESENTED HERE IS ALLOWED ONLY WITH EXPRESS PERMISSION OF 
>ONE OF THE AUTHORS.
>
>
>Disclaimer:
>===========
>
>This document and all the information it contains are provided "as is", 
>for educational purposes only, without warranty of any kind, whether 
>express or implied.
>
>The authors reserve the right not to be responsible for the topicality, 
>correctness, completeness or quality of the information  provided in 
>this document. Liability claims regarding damage caused by the use of 
>any information provided, including any kind of information which is 
>incomplete or incorrect, will therefore be rejected.
>
>- -- 
>Paul Starzetz
>iSEC Security Research
>http://isec.pl/
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.0.7 (GNU/Linux)
>
>iD8DBQFAERY5C+8U3Z5wpu4RAnmvAJ93n73Fi8BBpYZgvTUF21DVMonjKQCg1MBY
>HyvaD+vttT7Y3bLX2r/JKnQ=
>=mO5q
>-----END PGP SIGNATURE-----
>
>
>_______________________________________________
>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 23 13:54:09 2004
>Return-Path: <vendor-sec-admin@lst.de>
>Received: from Hermes.suse.de (Hermes.suse.de [10.0.0.1])
>	by wotan.suse.de (Postfix) with ESMTP id 088AE1071A
>	for <okir@wotan.suse.de>; Fri, 23 Jan 2004 13:54:09 +0100 (CET)
>Received: by Hermes.suse.de (Postfix)
>	id 00F6B8042; Fri, 23 Jan 2004 13:54:09 +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 F07723657
>	for <okir@suse.de>; Fri, 23 Jan 2004 13:54:08 +0100 (CET)
>Received: from mail.lst.de (verein.lst.de [212.34.189.10])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by Cantor.suse.de (Postfix) with ESMTP id C56E86FB5C
>	for <okir@suse.de>; Fri, 23 Jan 2004 13:54:08 +0100 (CET)
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NCs8e6025755
>	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
>	for <okir@suse.de>; Fri, 23 Jan 2004 13:54:08 +0100
>Received: (from cyrus@localhost)
>	by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i0NCs8gl025753
>	for okir@suse.de; Fri, 23 Jan 2004 13:54:08 +0100
>Received: from mail.lst.de ([unix socket])
>	by mail.lst.de (Cyrus v2.1.15-IPv6-Debian-2.1.15-0woody.1.0) with LMTP; Fri, 23 Jan 2004 13:54:08 +0100
>X-Sieve: CMU Sieve 2.2
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NCs7e5025750;
>	Fri, 23 Jan 2004 13:54:07 +0100
>Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NCrPe5025728
>	for <vendor-sec@lst.de>; Fri, 23 Jan 2004 13:53:26 +0100
>Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
>	by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id i0NCrJl18817;
>	Fri, 23 Jan 2004 07:53:19 -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 i0NCrJa25860;
>	Fri, 23 Jan 2004 07:53:19 -0500
>Received: from dell1.moose.awe.com (mjc-cipe.stuttgart.redhat.com [172.16.3.26])
>	by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id i0NCrIJG002015;
>	Fri, 23 Jan 2004 07:53:18 -0500
>Received: from dell1.moose.awe.com ([127.0.0.1] helo=localhost)
>	by dell1.moose.awe.com with esmtp (Exim 4.05)
>	id 1Ak0oL-0007dl-00; Fri, 23 Jan 2004 12:53:21 +0000
>From: Mark J Cox <mjc@redhat.com>
>X-X-Sender: mark@dell1.moose.awe.com
>To: security@isec.pl
>Cc: vendor-sec <vendor-sec@lst.de>
>Subject: Re: [vendor-sec] Another serious mremap() vulnerability
>In-Reply-To: <Pine.LNX.4.44.0401231327070.21007-100000@isec.pl>
>Message-ID: <Pine.LNX.4.58.0401231252240.28871@dell1.moose.awe.com>
>References: <Pine.LNX.4.44.0401231327070.21007-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
>X-Spam-Score: -4.901 () BAYES_00
>X-Scanned-By: MIMEDefang 2.39
>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/>
>Date: Fri, 23 Jan 2004 12:53:21 +0000 (GMT)
>X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on 
>	wotan.suse.de
>X-Spam-Level: 
>X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
>	version=2.61
>Status: RO
>Content-Length: 520
>Lines: 20
>
>> Synopsis:  Linux kernel do_mremap VMA limit local privilege escalation
>>            vulnerability
>> Product:   Linux kernel
>> Version:   2.4 up to 2.4.24 and 2.6.0
>> Vendor:    http://www.kernel.org/
>> URL:       not assigned
>> CVE:       not assigned
>
>Use CAN-2003-0077
>
>> Date:      January 23, 2004
>
>When do you plan on disclosing this issue?
> 
>Regards, 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 23 13:59:06 2004
>Return-Path: <vendor-sec-admin@lst.de>
>Received: from Hermes.suse.de (Hermes.suse.de [10.0.0.1])
>	by wotan.suse.de (Postfix) with ESMTP id 7B8EFE1EB
>	for <okir@wotan.suse.de>; Fri, 23 Jan 2004 13:59:06 +0100 (CET)
>Received: by Hermes.suse.de (Postfix)
>	id 73F948042; Fri, 23 Jan 2004 13:59:06 +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 6E54B3657
>	for <okir@suse.de>; Fri, 23 Jan 2004 13:59:06 +0100 (CET)
>Received: from mail.lst.de (verein.lst.de [212.34.189.10])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by Cantor.suse.de (Postfix) with ESMTP id 4F42E8DA65
>	for <okir@suse.de>; Fri, 23 Jan 2004 13:59:06 +0100 (CET)
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NCx5e6025954
>	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
>	for <okir@suse.de>; Fri, 23 Jan 2004 13:59:05 +0100
>Received: (from cyrus@localhost)
>	by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i0NCx543025952
>	for okir@suse.de; Fri, 23 Jan 2004 13:59:05 +0100
>Received: from mail.lst.de ([unix socket])
>	by mail.lst.de (Cyrus v2.1.15-IPv6-Debian-2.1.15-0woody.1.0) with LMTP; Fri, 23 Jan 2004 13:59:05 +0100
>X-Sieve: CMU Sieve 2.2
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NCx5e5025948;
>	Fri, 23 Jan 2004 13:59:05 +0100
>Received: from isec.pl (isec.pl [193.110.121.50])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NCwce5025924
>	for <vendor-sec@lst.de>; Fri, 23 Jan 2004 13:58:38 +0100
>Received: by isec.pl (Postfix, from userid 500)
>	id A599D3F22; Fri, 23 Jan 2004 13:58:38 +0100 (CET)
>Received: from localhost (localhost [127.0.0.1])
>	by isec.pl (Postfix) with ESMTP
>	id 93F6517695; Fri, 23 Jan 2004 13:58:38 +0100 (CET)
>From: Paul Starzetz <ihaquer@isec.pl>
>To: Mark J Cox <mjc@redhat.com>
>Cc: vendor-sec <vendor-sec@lst.de>
>Subject: Re: [vendor-sec] Another serious mremap() vulnerability
>In-Reply-To: <Pine.LNX.4.58.0401231252240.28871@dell1.moose.awe.com>
>Message-ID: <Pine.LNX.4.44.0401231357100.21955-100000@isec.pl>
>MIME-Version: 1.0
>Content-Type: TEXT/PLAIN; charset=US-ASCII
>X-Spam-Score: -4.901 () BAYES_00
>X-Scanned-By: MIMEDefang 2.39
>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/>
>Date: Fri, 23 Jan 2004 13:58:38 +0100 (CET)
>X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on 
>	wotan.suse.de
>X-Spam-Level: 
>X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
>	version=2.61
>Status: RO
>Content-Length: 473
>Lines: 20
>
>On Fri, 23 Jan 2004, Mark J Cox wrote:
>
>> When do you plan on disclosing this issue?
>
>We would like to set the deadline to 09.02.2004 if this is ok for you.
>
>Anyway my impression is that the mremap() code should be rewritten in a 
>clean way from scratch...
>
>
>-- 
>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  Fri Jan 23 20:27:27 2004
>Return-Path: <vendor-sec-admin@lst.de>
>Received: from Hermes.suse.de (Hermes.suse.de [10.0.0.1])
>	by wotan.suse.de (Postfix) with ESMTP id 1B84375FB
>	for <okir@wotan.suse.de>; Fri, 23 Jan 2004 20:27:27 +0100 (CET)
>Received: by Hermes.suse.de (Postfix)
>	id 0CCE03657; Fri, 23 Jan 2004 20:27:27 +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 D28C111E11
>	for <okir@suse.de>; Fri, 23 Jan 2004 20:27:26 +0100 (CET)
>Received: from mail.lst.de (verein.lst.de [212.34.189.10])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by Cantor.suse.de (Postfix) with ESMTP id 64D2F90D1F
>	for <okir@suse.de>; Fri, 23 Jan 2004 20:27:15 +0100 (CET)
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NJREe6001437
>	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
>	for <okir@suse.de>; Fri, 23 Jan 2004 20:27:14 +0100
>Received: (from cyrus@localhost)
>	by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i0NJREhq001435
>	for okir@suse.de; Fri, 23 Jan 2004 20:27:14 +0100
>Received: from mail.lst.de ([unix socket])
>	by mail.lst.de (Cyrus v2.1.15-IPv6-Debian-2.1.15-0woody.1.0) with LMTP; Fri, 23 Jan 2004 20:27:14 +0100
>X-Sieve: CMU Sieve 2.2
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NJRBe5001427;
>	Fri, 23 Jan 2004 20:27:11 +0100
>Received: from luonnotar.infodrom.org (luonnotar.infodrom.org [195.124.48.78])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NJQ8e5001375
>	for <vendor-sec@lst.de>; Fri, 23 Jan 2004 20:26:08 +0100
>Received: by luonnotar.infodrom.org (Postfix, from userid 10)
>	id AC634366B6E; Fri, 23 Jan 2004 20:25:56 +0100 (CET)
>Received: at Infodrom Oldenburg (/\##/\ Smail-3.2.0.102 1998-Aug-2 #2)
>	from infodrom.org by finlandia.Infodrom.North.DE
>	via smail from stdin
>	id <m1Ak6qu-000pFGC@finlandia.Infodrom.North.DE>
>	for ihaquer@isec.pl; Fri, 23 Jan 2004 20:20:24 +0100 (CET) 
>From: Martin Schulze <joey@infodrom.org>
>To: Paul Starzetz <ihaquer@isec.pl>
>Cc: vendor-sec <vendor-sec@lst.de>
>Message-ID: <20040123192023.GN10663@finlandia.infodrom.north.de>
>References: <Pine.LNX.4.58.0401231252240.28871@dell1.moose.awe.com> <Pine.LNX.4.44.0401231357100.21955-100000@isec.pl>
>Mime-Version: 1.0
>Content-Type: text/plain; charset=iso-8859-1
>Content-Disposition: inline
>In-Reply-To: <Pine.LNX.4.44.0401231357100.21955-100000@isec.pl>
>User-Agent: Mutt/1.5.4i
>X-Spam-Score: -4.901 () BAYES_00
>X-Scanned-By: MIMEDefang 2.39
>Subject: [vendor-sec] Re: Another serious mremap() vulnerability
>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/>
>Date: Fri, 23 Jan 2004 20:20:24 +0100
>X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on 
>	wotan.suse.de
>X-Spam-Level: 
>X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
>	version=2.61
>Status: RO
>Content-Length: 619
>Lines: 22
>
>Paul Starzetz wrote:
>> On Fri, 23 Jan 2004, Mark J Cox wrote:
>> 
>> > When do you plan on disclosing this issue?
>> 
>> We would like to set the deadline to 09.02.2004 if this is ok for you.
>
>Hmm, I'd rather opt for one week later Feb 16th.
>Debian still has some architectures and kernels with unfixed mremap#1,
>kernel problems take a long way to migrate into all our kernels,
>alas.
>
>Regards,
>
>	Joey
>
>-- 
>Unix is user friendly ...  It's just picky about its friends.
>_______________________________________________
>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 23 14:17:07 2004
>Return-Path: <vendor-sec-admin@lst.de>
>Received: from Hermes.suse.de (Hermes.suse.de [10.0.0.1])
>	by wotan.suse.de (Postfix) with ESMTP id 905551071A
>	for <okir@wotan.suse.de>; Fri, 23 Jan 2004 14:17:07 +0100 (CET)
>Received: by Hermes.suse.de (Postfix)
>	id 891FC11E27; Fri, 23 Jan 2004 14:17:07 +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 8420CC6F3
>	for <okir@suse.de>; Fri, 23 Jan 2004 14:17:07 +0100 (CET)
>Received: from mail.lst.de (verein.lst.de [212.34.189.10])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by Cantor.suse.de (Postfix) with ESMTP id 63A378D4E4
>	for <okir@suse.de>; Fri, 23 Jan 2004 14:17:07 +0100 (CET)
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NDH6e6026756
>	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
>	for <okir@suse.de>; Fri, 23 Jan 2004 14:17:06 +0100
>Received: (from cyrus@localhost)
>	by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i0NDH6SR026754
>	for okir@suse.de; Fri, 23 Jan 2004 14:17:06 +0100
>Received: from mail.lst.de ([unix socket])
>	by mail.lst.de (Cyrus v2.1.15-IPv6-Debian-2.1.15-0woody.1.0) with LMTP; Fri, 23 Jan 2004 14:17:05 +0100
>X-Sieve: CMU Sieve 2.2
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NDH5e5026751;
>	Fri, 23 Jan 2004 14:17:05 +0100
>Received: from perninha.conectiva.com.br (perninha.conectiva.com.br [200.140.247.100])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NDGhe5026732
>	for <vendor-sec@lst.de>; Fri, 23 Jan 2004 14:16:44 +0100
>Received: from pandora.distro.conectiva (pandora.distro.conectiva [10.0.17.30])
>	by perninha.conectiva.com.br (Postfix) with ESMTP
>	id D181647331; Fri, 23 Jan 2004 11:16:35 -0200 (BRST)
>Received: by pandora.distro.conectiva (Postfix, from userid 500)
>	id C7FCFB4305; Fri, 23 Jan 2004 11:16:35 -0200 (BRST)
>From: Andreas <andreas@conectiva.com.br>
>To: Mark J Cox <mjc@redhat.com>
>Cc: security@isec.pl, vendor-sec <vendor-sec@lst.de>
>Subject: Re: [vendor-sec] Another serious mremap() vulnerability
>Message-ID: <20040123131635.GB9414@conectiva.com.br>
>References: <Pine.LNX.4.44.0401231327070.21007-100000@isec.pl> <Pine.LNX.4.58.0401231252240.28871@dell1.moose.awe.com>
>Mime-Version: 1.0
>Content-Type: text/plain; charset=us-ascii
>Content-Disposition: inline
>In-Reply-To: <Pine.LNX.4.58.0401231252240.28871@dell1.moose.awe.com>
>User-Agent: Mutt/1.5.5.1i
>X-Spam-Score: -4.901 () BAYES_00
>X-Scanned-By: MIMEDefang 2.39
>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/>
>Date: Fri, 23 Jan 2004 11:16:35 -0200
>X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on 
>	wotan.suse.de
>X-Spam-Level: 
>X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
>	version=2.61
>Status: RO
>Content-Length: 514
>Lines: 17
>
>On Fri, Jan 23, 2004 at 12:53:21PM +0000, Mark J Cox wrote:
>> > Synopsis:  Linux kernel do_mremap VMA limit local privilege escalation
>> >            vulnerability
>> > Product:   Linux kernel
>> > Version:   2.4 up to 2.4.24 and 2.6.0
>> > Vendor:    http://www.kernel.org/
>> > URL:       not assigned
>> > CVE:       not assigned
>> 
>> Use CAN-2003-0077
>
>2003?
>
>_______________________________________________
>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 23 15:35:15 2004
>Return-Path: <vendor-sec-admin@lst.de>
>Received: from Hermes.suse.de (Hermes.suse.de [10.0.0.1])
>	by wotan.suse.de (Postfix) with ESMTP id 94B15AE2C
>	for <okir@wotan.suse.de>; Fri, 23 Jan 2004 15:35:15 +0100 (CET)
>Received: by Hermes.suse.de (Postfix)
>	id 912518042; Fri, 23 Jan 2004 15:35:15 +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 81342907
>	for <okir@suse.de>; Fri, 23 Jan 2004 15:35:15 +0100 (CET)
>Received: from mail.lst.de (verein.lst.de [212.34.189.10])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by Cantor.suse.de (Postfix) with ESMTP id 57E848BBE2
>	for <okir@suse.de>; Fri, 23 Jan 2004 15:35:15 +0100 (CET)
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NEZEe6027986
>	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
>	for <okir@suse.de>; Fri, 23 Jan 2004 15:35:14 +0100
>Received: (from cyrus@localhost)
>	by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i0NEZElL027984
>	for okir@suse.de; Fri, 23 Jan 2004 15:35:14 +0100
>Received: from mail.lst.de ([unix socket])
>	by mail.lst.de (Cyrus v2.1.15-IPv6-Debian-2.1.15-0woody.1.0) with LMTP; Fri, 23 Jan 2004 15:35:14 +0100
>X-Sieve: CMU Sieve 2.2
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NEZDe5027981;
>	Fri, 23 Jan 2004 15:35:13 +0100
>Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NEXYe5027942
>	for <vendor-sec@lst.de>; Fri, 23 Jan 2004 15:33:34 +0100
>Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
>	by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id i0NEXKl16909;
>	Fri, 23 Jan 2004 09:33:20 -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 i0NEXKa23898;
>	Fri, 23 Jan 2004 09:33:20 -0500
>Received: from dell1.moose.awe.com (mjc-cipe.stuttgart.redhat.com [172.16.3.26])
>	by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id i0NEXJJG014223;
>	Fri, 23 Jan 2004 09:33:20 -0500
>Received: from dell1.moose.awe.com ([127.0.0.1] helo=localhost)
>	by dell1.moose.awe.com with esmtp (Exim 4.05)
>	id 1Ak2N8-0007ng-00; Fri, 23 Jan 2004 14:33:22 +0000
>From: Mark J Cox <mjc@redhat.com>
>X-X-Sender: mark@dell1.moose.awe.com
>To: Andreas <andreas@conectiva.com.br>
>Cc: security@isec.pl, vendor-sec <vendor-sec@lst.de>
>Subject: Re: [vendor-sec] Another serious mremap() vulnerability
>In-Reply-To: <20040123131635.GB9414@conectiva.com.br>
>Message-ID: <Pine.LNX.4.58.0401231433030.29980@dell1.moose.awe.com>
>References: <Pine.LNX.4.44.0401231327070.21007-100000@isec.pl>
> <Pine.LNX.4.58.0401231252240.28871@dell1.moose.awe.com>
> <20040123131635.GB9414@conectiva.com.br>
>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
>X-Spam-Score: -4.901 () BAYES_00
>X-Scanned-By: MIMEDefang 2.39
>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/>
>Date: Fri, 23 Jan 2004 14:33:22 +0000 (GMT)
>X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on 
>	wotan.suse.de
>X-Spam-Level: 
>X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
>	version=2.61
>Status: RO
>Content-Length: 727
>Lines: 28
>
>Doh. I always get it wrong when I don't cut and paste.  Well caught ;)
>CAN-2004-0077
>
>Thanks, Mark
>-- 
>Mark J Cox / Red Hat Security Response Team
>
>
>
>On Fri, 23 Jan 2004, Andreas wrote:
>
>> On Fri, Jan 23, 2004 at 12:53:21PM +0000, Mark J Cox wrote:
>> > > Synopsis:  Linux kernel do_mremap VMA limit local privilege escalation
>> > >            vulnerability
>> > > Product:   Linux kernel
>> > > Version:   2.4 up to 2.4.24 and 2.6.0
>> > > Vendor:    http://www.kernel.org/
>> > > URL:       not assigned
>> > > CVE:       not assigned
>> > 
>> > Use CAN-2003-0077
>> 
>> 2003?
>> 
>_______________________________________________
>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 23 15:46:07 2004
>Return-Path: <vendor-sec-admin@lst.de>
>Received: from Hermes.suse.de (Hermes.suse.de [10.0.0.1])
>	by wotan.suse.de (Postfix) with ESMTP id F13831071A
>	for <okir@wotan.suse.de>; Fri, 23 Jan 2004 15:46:06 +0100 (CET)
>Received: by Hermes.suse.de (Postfix)
>	id EFEB88042; Fri, 23 Jan 2004 15:46:06 +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 E8C15C6F3
>	for <okir@suse.de>; Fri, 23 Jan 2004 15:46:06 +0100 (CET)
>Received: from mail.lst.de (verein.lst.de [212.34.189.10])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by Cantor.suse.de (Postfix) with ESMTP id B34A28C45B
>	for <okir@suse.de>; Fri, 23 Jan 2004 15:46:06 +0100 (CET)
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NEk6e6028375
>	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
>	for <okir@suse.de>; Fri, 23 Jan 2004 15:46:06 +0100
>Received: (from cyrus@localhost)
>	by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i0NEk6SR028373
>	for okir@suse.de; Fri, 23 Jan 2004 15:46:06 +0100
>Received: from mail.lst.de ([unix socket])
>	by mail.lst.de (Cyrus v2.1.15-IPv6-Debian-2.1.15-0woody.1.0) with LMTP; Fri, 23 Jan 2004 15:46:06 +0100
>X-Sieve: CMU Sieve 2.2
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NEk5e5028369;
>	Fri, 23 Jan 2004 15:46:05 +0100
>Received: from mitzu.mi.org (mitzu.mi.org [198.22.64.42])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NEjLe5028319
>	for <vendor-sec@lst.de>; Fri, 23 Jan 2004 15:45:21 +0100
>Received: from dojo.mi.org (mojo.mi.org [198.22.64.44])
>	by mitzu.mi.org (Postfix) with ESMTP id 011134089
>	for <vendor-sec@lst.de>; Fri, 23 Jan 2004 09:45:04 -0500 (EST)
>Received: by dojo.mi.org
>	id 5DF97648A9C; Fri, 23 Jan 2004 09:37:55 -0500 (EST)
>Subject: Re: [vendor-sec] Another serious mremap() vulnerability
>To: vendor-sec@lst.de (vendor-sec List)
>From: "Mike O'Connor" <mjo@dojo.mi.org>
>Reply-To: "Mike O'Connor" <mjo@dojo.mi.org>
>Message-Id: <040123093755.mjo@dojo.mi.org>
>X-Organization: :noitazinagrO-X
>X-Spam-Score: -4.901 () BAYES_00
>X-Scanned-By: MIMEDefang 2.39
>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/>
>Date: Fri, 23 Jan 2004 09:37:55 -0500 (EST)
>X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on 
>	wotan.suse.de
>X-Spam-Level: 
>X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
>	version=2.61
>Status: RO
>Content-Length: 1179
>Lines: 37
>
>:On Fri, 23 Jan 2004, Mark J Cox wrote:
>:
>:> When do you plan on disclosing this issue?
>:
>:We would like to set the deadline to 09.02.2004 if this is ok for you.
>
>For the U.S. centric sorts, I'm fairly sure this turns out to be
>February 9th rather than September 2nd.  However, if a complete
>rewrite of mremap() is indeed in order, I doubt that it could be
>done and well-tested in 2 weeks, and the September timeframe is 
>probably closer to reality...
>
>:Anyway my impression is that the mremap() code should be rewritten in a 
>:clean way from scratch...
>:
>:
>:-- 
>: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
>:
>
>
>-- 
> Mail: mjo@dojo.mi.org  WWW: http://dojo.mi.org/~mjo/  Phone: +1 248 427 4481
> =--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--=
>"I need a vacation."                                          -The Terminator
>_______________________________________________
>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 23 16:30:07 2004
>Return-Path: <vendor-sec-admin@lst.de>
>Received: from Hermes.suse.de (Hermes.suse.de [10.0.0.1])
>	by wotan.suse.de (Postfix) with ESMTP id D263F1072A
>	for <okir@wotan.suse.de>; Fri, 23 Jan 2004 16:30:07 +0100 (CET)
>Received: by Hermes.suse.de (Postfix)
>	id CABFC60D4; Fri, 23 Jan 2004 16:30:07 +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 BF6E3907
>	for <okir@suse.de>; Fri, 23 Jan 2004 16:30:07 +0100 (CET)
>Received: from mail.lst.de (verein.lst.de [212.34.189.10])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by Cantor.suse.de (Postfix) with ESMTP id 961B58EE0F
>	for <okir@suse.de>; Fri, 23 Jan 2004 16:30:07 +0100 (CET)
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NFU6e6029356
>	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
>	for <okir@suse.de>; Fri, 23 Jan 2004 16:30:06 +0100
>Received: (from cyrus@localhost)
>	by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i0NFU6dW029354
>	for okir@suse.de; Fri, 23 Jan 2004 16:30:06 +0100
>Received: from mail.lst.de ([unix socket])
>	by mail.lst.de (Cyrus v2.1.15-IPv6-Debian-2.1.15-0woody.1.0) with LMTP; Fri, 23 Jan 2004 16:30:06 +0100
>X-Sieve: CMU Sieve 2.2
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NFU5e5029350;
>	Fri, 23 Jan 2004 16:30:05 +0100
>Received: from president.dataforce.net (president.dataforce.net [195.42.160.21])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with SMTP id i0NFTce5029317
>	for <vendor-sec@lst.de>; Fri, 23 Jan 2004 16:29:38 +0100
>Received: (qmail 26129 invoked from network); 23 Jan 2004 15:29:37 -0000
>Received: from localhost (HELO openwall.com) (127.0.0.1)
>  by localhost with SMTP; 23 Jan 2004 15:29:37 -0000
>Received: by openwall.com (Postfix, from userid 503)
>	id 948722A0EB; Fri, 23 Jan 2004 18:19:47 +0300 (MSK)
>From: Solar Designer <solar@openwall.com>
>To: security@isec.pl
>Cc: vendor-sec <vendor-sec@lst.de>
>Subject: Re: [vendor-sec] Another serious mremap() vulnerability
>Message-ID: <20040123151947.GA28650@openwall.com>
>References: <Pine.LNX.4.44.0401231327070.21007-100000@isec.pl>
>Mime-Version: 1.0
>Content-Type: text/plain; charset=us-ascii
>Content-Disposition: inline
>In-Reply-To: <Pine.LNX.4.44.0401231327070.21007-100000@isec.pl>
>User-Agent: Mutt/1.4.1i
>X-Spam-Score: -4.901 () BAYES_00
>X-Scanned-By: MIMEDefang 2.39
>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/>
>Date: Fri, 23 Jan 2004 18:19:47 +0300
>X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on 
>	wotan.suse.de
>X-Spam-Level: 
>X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
>	version=2.61
>Status: RO
>Content-Length: 542
>Lines: 19
>
>Paul,
>
>On Fri, Jan 23, 2004 at 01:40:20PM +0100, Paul Starzetz wrote:
>[...]
>> Due to the missing return value check after trying to unmap the middle 
>> of the VMA1 (this is the first invocation of do_munmap inside do_mremap) 
>
>Have you checked 2.4.23-ow2 / 2.4.24-ow1?  I think I had that fixed.
>
>Do you have an exploit or at least a program to test for vulnerability?
>
>Thanks,
>
>-- 
>/sd
>_______________________________________________
>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 23 16:48:06 2004
>Return-Path: <vendor-sec-admin@lst.de>
>Received: from Hermes.suse.de (Hermes.suse.de [10.0.0.1])
>	by wotan.suse.de (Postfix) with ESMTP id 687521073A
>	for <okir@wotan.suse.de>; Fri, 23 Jan 2004 16:48:06 +0100 (CET)
>Received: by Hermes.suse.de (Postfix)
>	id 6441212669; Fri, 23 Jan 2004 16:48:06 +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 5DF2F11EC6
>	for <okir@suse.de>; Fri, 23 Jan 2004 16:48:06 +0100 (CET)
>Received: from mail.lst.de (verein.lst.de [212.34.189.10])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by Cantor.suse.de (Postfix) with ESMTP id 252AD8EFE6
>	for <okir@suse.de>; Fri, 23 Jan 2004 16:48:06 +0100 (CET)
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NFm5e6030040
>	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
>	for <okir@suse.de>; Fri, 23 Jan 2004 16:48:05 +0100
>Received: (from cyrus@localhost)
>	by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i0NFm5ab030038
>	for okir@suse.de; Fri, 23 Jan 2004 16:48:05 +0100
>Received: from mail.lst.de ([unix socket])
>	by mail.lst.de (Cyrus v2.1.15-IPv6-Debian-2.1.15-0woody.1.0) with LMTP; Fri, 23 Jan 2004 16:48:05 +0100
>X-Sieve: CMU Sieve 2.2
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NFm4e5030035;
>	Fri, 23 Jan 2004 16:48:04 +0100
>Received: from isec.pl (isec.pl [193.110.121.50])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NFl2e5029997
>	for <vendor-sec@lst.de>; Fri, 23 Jan 2004 16:47:12 +0100
>Received: by isec.pl (Postfix, from userid 500)
>	id 0909E3F22; Fri, 23 Jan 2004 16:46:57 +0100 (CET)
>Received: from localhost (localhost [127.0.0.1])
>	by isec.pl (Postfix) with ESMTP
>	id E372817695; Fri, 23 Jan 2004 16:46:57 +0100 (CET)
>From: Paul Starzetz <ihaquer@isec.pl>
>To: Solar Designer <solar@openwall.com>
>Cc: security@isec.pl, vendor-sec <vendor-sec@lst.de>
>Subject: Re: [vendor-sec] Another serious mremap() vulnerability
>In-Reply-To: <20040123151947.GA28650@openwall.com>
>Message-ID: <Pine.LNX.4.44.0401231640000.21955-100000@isec.pl>
>MIME-Version: 1.0
>Content-Type: TEXT/PLAIN; charset=US-ASCII
>X-Spam-Score: -4.901 () BAYES_00
>X-Scanned-By: MIMEDefang 2.39
>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/>
>Date: Fri, 23 Jan 2004 16:46:57 +0100 (CET)
>X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on 
>	wotan.suse.de
>X-Spam-Level: 
>X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
>	version=2.61
>Status: RO
>Content-Length: 577
>Lines: 22
>
>On Fri, 23 Jan 2004, Solar Designer wrote:
>
>> Have you checked 2.4.23-ow2 / 2.4.24-ow1?  I think I had that fixed.
>> 
>> Do you have an exploit or at least a program to test for vulnerability?
>
>Seems to be fixed there, indeed.
>Does it mean it has been silently fixed?
>
>We have a proof-of-concept for the max VMA case, however it is not yet 
>uid=0, just an Ooops.
>
>-- 
>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  Fri Jan 23 17:05:12 2004
>Return-Path: <vendor-sec-admin@lst.de>
>Received: from Hermes.suse.de (Hermes.suse.de [10.0.0.1])
>	by wotan.suse.de (Postfix) with ESMTP id 5A7AD75FB
>	for <okir@wotan.suse.de>; Fri, 23 Jan 2004 17:05:12 +0100 (CET)
>Received: by Hermes.suse.de (Postfix)
>	id 51410129D9; Fri, 23 Jan 2004 17:05:12 +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 47C58129D6
>	for <okir@suse.de>; Fri, 23 Jan 2004 17:05:12 +0100 (CET)
>Received: from mail.lst.de (verein.lst.de [212.34.189.10])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by Cantor.suse.de (Postfix) with ESMTP id 184198F297
>	for <okir@suse.de>; Fri, 23 Jan 2004 17:05:12 +0100 (CET)
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NG5Be6030421
>	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
>	for <okir@suse.de>; Fri, 23 Jan 2004 17:05:11 +0100
>Received: (from cyrus@localhost)
>	by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i0NG5Bg5030419
>	for okir@suse.de; Fri, 23 Jan 2004 17:05:11 +0100
>Received: from mail.lst.de ([unix socket])
>	by mail.lst.de (Cyrus v2.1.15-IPv6-Debian-2.1.15-0woody.1.0) with LMTP; Fri, 23 Jan 2004 17:05:11 +0100
>X-Sieve: CMU Sieve 2.2
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NG5Be5030415;
>	Fri, 23 Jan 2004 17:05:11 +0100
>Received: from president.dataforce.net (president.dataforce.net [195.42.160.21])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with SMTP id i0NG4Oe5030387
>	for <vendor-sec@lst.de>; Fri, 23 Jan 2004 17:04:24 +0100
>Received: (qmail 30339 invoked from network); 23 Jan 2004 16:04:23 -0000
>Received: from localhost (HELO openwall.com) (127.0.0.1)
>  by localhost with SMTP; 23 Jan 2004 16:04:23 -0000
>Received: by openwall.com (Postfix, from userid 503)
>	id A147D2A0E7; Fri, 23 Jan 2004 18:54:29 +0300 (MSK)
>From: Solar Designer <solar@openwall.com>
>To: Paul Starzetz <ihaquer@isec.pl>
>Cc: security@isec.pl, vendor-sec <vendor-sec@lst.de>
>Subject: Re: [vendor-sec] Another serious mremap() vulnerability
>Message-ID: <20040123155429.GA28899@openwall.com>
>References: <20040123151947.GA28650@openwall.com> <Pine.LNX.4.44.0401231640000.21955-100000@isec.pl>
>Mime-Version: 1.0
>Content-Type: text/plain; charset=us-ascii
>Content-Disposition: inline
>In-Reply-To: <Pine.LNX.4.44.0401231640000.21955-100000@isec.pl>
>User-Agent: Mutt/1.4.1i
>X-Spam-Score: -4.901 () BAYES_00
>X-Scanned-By: MIMEDefang 2.39
>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/>
>Date: Fri, 23 Jan 2004 18:54:29 +0300
>X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on 
>	wotan.suse.de
>X-Spam-Level: 
>X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
>	version=2.61
>Status: RO
>Content-Length: 1122
>Lines: 31
>
>On Fri, Jan 23, 2004 at 04:46:57PM +0100, Paul Starzetz wrote:
>> On Fri, 23 Jan 2004, Solar Designer wrote:
>> 
>> > Have you checked 2.4.23-ow2 / 2.4.24-ow1?  I think I had that fixed.
>> > 
>> > Do you have an exploit or at least a program to test for vulnerability?
>> 
>> Seems to be fixed there, indeed.
>
>Then Owl 1.1 is not vulnerable.  Good. :-)
>
>Just to make sure, -- is your comment based on code review or on
>running your proof-of-concept on a 2.4.23-ow2 / 2.4.24-ow1 kernel, or
>both?
>
>> Does it mean it has been silently fixed?
>
>I did not realize full impact, -- I just fixed what looked wrong
>without further investigation.  Andrea Arcangeli has opposed my
>changes for various reasons, so they did not get into 2.4.24 and into
>most vendors' updates, -- although I know that we (Owl) are not the
>only distribution which used my bigger mremap() patch including this
>fix.  I think it's also Immunix, Mandrake, perhaps ALT Linux(?), and
>there may be more.
>
>-- 
>/sd
>_______________________________________________
>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 23 17:17:13 2004
>Return-Path: <vendor-sec-admin@lst.de>
>Received: from Hermes.suse.de (Hermes.suse.de [10.0.0.1])
>	by wotan.suse.de (Postfix) with ESMTP id 150BCE27F
>	for <okir@wotan.suse.de>; Fri, 23 Jan 2004 17:17:13 +0100 (CET)
>Received: by Hermes.suse.de (Postfix)
>	id 0DE3011E1C; Fri, 23 Jan 2004 17:17:13 +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 08E6311E14
>	for <okir@suse.de>; Fri, 23 Jan 2004 17:17:13 +0100 (CET)
>Received: from mail.lst.de (verein.lst.de [212.34.189.10])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by Cantor.suse.de (Postfix) with ESMTP id DBB408F3F9
>	for <okir@suse.de>; Fri, 23 Jan 2004 17:17:12 +0100 (CET)
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NGHCe6030614
>	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
>	for <okir@suse.de>; Fri, 23 Jan 2004 17:17:12 +0100
>Received: (from cyrus@localhost)
>	by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i0NGHCrm030612
>	for okir@suse.de; Fri, 23 Jan 2004 17:17:12 +0100
>Received: from mail.lst.de ([unix socket])
>	by mail.lst.de (Cyrus v2.1.15-IPv6-Debian-2.1.15-0woody.1.0) with LMTP; Fri, 23 Jan 2004 17:17:12 +0100
>X-Sieve: CMU Sieve 2.2
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NGHBe5030608;
>	Fri, 23 Jan 2004 17:17: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-6.6) with ESMTP id i0NGGae6030589
>	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
>	for <vendor-sec@lst.de>; Fri, 23 Jan 2004 17:16:37 +0100
>Received: from viro by www.linux.org.uk with local (Exim 4.22)
>	id 1Ak3z1-0001zX-Ed; Fri, 23 Jan 2004 16:16:35 +0000
>From: viro@parcelfarce.linux.theplanet.co.uk
>To: Paul Starzetz <ihaquer@isec.pl>
>Cc: Solar Designer <solar@openwall.com>, security@isec.pl,
>	vendor-sec <vendor-sec@lst.de>
>Subject: Re: [vendor-sec] Another serious mremap() vulnerability
>Message-ID: <20040123161635.GG21151@parcelfarce.linux.theplanet.co.uk>
>References: <20040123151947.GA28650@openwall.com> <Pine.LNX.4.44.0401231640000.21955-100000@isec.pl>
>Mime-Version: 1.0
>Content-Type: text/plain; charset=us-ascii
>Content-Disposition: inline
>In-Reply-To: <Pine.LNX.4.44.0401231640000.21955-100000@isec.pl>
>User-Agent: Mutt/1.4.1i
>X-Spam-Score: -4.562 () BAYES_00,NO_REAL_NAME
>X-Scanned-By: MIMEDefang 2.39
>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/>
>Date: Fri, 23 Jan 2004 16:16:35 +0000
>X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on 
>	wotan.suse.de
>X-Spam-Level: 
>X-Spam-Status: No, hits=-4.6 required=5.0 tests=BAYES_00,NO_REAL_NAME 
>	autolearn=no version=2.61
>Status: RO
>Content-Length: 938
>Lines: 24
>
>On Fri, Jan 23, 2004 at 04:46:57PM +0100, Paul Starzetz wrote:
>> On Fri, 23 Jan 2004, Solar Designer wrote:
>> 
>> > Have you checked 2.4.23-ow2 / 2.4.24-ow1?  I think I had that fixed.
>> > 
>> > Do you have an exploit or at least a program to test for vulnerability?
>> 
>> Seems to be fixed there, indeed.
>> Does it mean it has been silently fixed?
>> 
>> We have a proof-of-concept for the max VMA case, however it is not yet 
>> uid=0, just an Ooops.
>
>That looks more realistic.  Getting it to BUG() is certainly doable;
>getting those PTEs and using it would be much trickier and I don't
>see any obvious cases.  Care to give details?
>
>Note that after BUG() is hit we are left with ->mmap_sem being held.
>Which means that there will be no page faults in any tasks that share
>the same VM.
>_______________________________________________
>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 23 17:27:14 2004
>Return-Path: <vendor-sec-admin@lst.de>
>Received: from Hermes.suse.de (Hermes.suse.de [10.0.0.1])
>	by wotan.suse.de (Postfix) with ESMTP id EEFD41072A
>	for <okir@wotan.suse.de>; Fri, 23 Jan 2004 17:27:13 +0100 (CET)
>Received: by Hermes.suse.de (Postfix)
>	id E884111797; Fri, 23 Jan 2004 17:27:13 +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 E3DDD3657
>	for <okir@suse.de>; Fri, 23 Jan 2004 17:27:13 +0100 (CET)
>Received: from mail.lst.de (verein.lst.de [212.34.189.10])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by Cantor.suse.de (Postfix) with ESMTP id A3808B125
>	for <okir@suse.de>; Fri, 23 Jan 2004 17:26:06 +0100 (CET)
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NGQ6e6030959
>	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
>	for <okir@suse.de>; Fri, 23 Jan 2004 17:26:06 +0100
>Received: (from cyrus@localhost)
>	by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i0NGQ6EC030957
>	for okir@suse.de; Fri, 23 Jan 2004 17:26:06 +0100
>Received: from mail.lst.de ([unix socket])
>	by mail.lst.de (Cyrus v2.1.15-IPv6-Debian-2.1.15-0woody.1.0) with LMTP; Fri, 23 Jan 2004 17:26:05 +0100
>X-Sieve: CMU Sieve 2.2
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NGQ5e5030954;
>	Fri, 23 Jan 2004 17:26:05 +0100
>Received: from isec.pl (isec.pl [193.110.121.50])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NGPHe5030930
>	for <vendor-sec@lst.de>; Fri, 23 Jan 2004 17:25:17 +0100
>Received: by isec.pl (Postfix, from userid 500)
>	id 877FA3F22; Fri, 23 Jan 2004 17:25:16 +0100 (CET)
>Received: from localhost (localhost [127.0.0.1])
>	by isec.pl (Postfix) with ESMTP
>	id 761F417695; Fri, 23 Jan 2004 17:25:16 +0100 (CET)
>From: Paul Starzetz <ihaquer@isec.pl>
>To: viro@parcelfarce.linux.theplanet.co.uk
>Cc: Solar Designer <solar@openwall.com>,
>	vendor-sec <vendor-sec@lst.de>
>Subject: Re: [vendor-sec] Another serious mremap() vulnerability
>In-Reply-To: <20040123161635.GG21151@parcelfarce.linux.theplanet.co.uk>
>Message-ID: <Pine.LNX.4.44.0401231721330.21955-100000@isec.pl>
>MIME-Version: 1.0
>Content-Type: TEXT/PLAIN; charset=US-ASCII
>X-Spam-Score: -4.901 () BAYES_00
>X-Scanned-By: MIMEDefang 2.39
>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/>
>Date: Fri, 23 Jan 2004 17:25:16 +0100 (CET)
>X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on 
>	wotan.suse.de
>X-Spam-Level: 
>X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
>	version=2.61
>Status: RO
>Content-Length: 797
>Lines: 25
>
>On Fri, 23 Jan 2004 viro@parcelfarce.linux.theplanet.co.uk wrote:
>
>> That looks more realistic.  Getting it to BUG() is certainly doable;
>> getting those PTEs and using it would be much trickier and I don't
>> see any obvious cases.  Care to give details?
>
>I said in the advisory that the second do_munmap is the realistic (however 
>difficult) path...
> 
>> Note that after BUG() is hit we are left with ->mmap_sem being held.
>> Which means that there will be no page faults in any tasks that share
>> the same VM.
>
>Yes sure - we have shortend the advisory not to include such details.
>
>-- 
>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  Fri Jan 23 17:58:16 2004
>Return-Path: <vendor-sec-admin@lst.de>
>Received: from Hermes.suse.de (Hermes.suse.de [10.0.0.1])
>	by wotan.suse.de (Postfix) with ESMTP id B99ED10743
>	for <okir@wotan.suse.de>; Fri, 23 Jan 2004 17:58:16 +0100 (CET)
>Received: by Hermes.suse.de (Postfix)
>	id ACDCC12089; Fri, 23 Jan 2004 17:58:16 +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 A7D5B11F55
>	for <okir@suse.de>; Fri, 23 Jan 2004 17:58:16 +0100 (CET)
>Received: from mail.lst.de (verein.lst.de [212.34.189.10])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by Cantor.suse.de (Postfix) with ESMTP id 803B58DFF9
>	for <okir@suse.de>; Fri, 23 Jan 2004 17: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-6.6) with ESMTP id i0NGwFe6031485
>	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
>	for <okir@suse.de>; Fri, 23 Jan 2004 17:58:16 +0100
>Received: (from cyrus@localhost)
>	by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i0NGwFNH031479
>	for okir@suse.de; Fri, 23 Jan 2004 17:58:15 +0100
>Received: from mail.lst.de ([unix socket])
>	by mail.lst.de (Cyrus v2.1.15-IPv6-Debian-2.1.15-0woody.1.0) with LMTP; Fri, 23 Jan 2004 17:58:15 +0100
>X-Sieve: CMU Sieve 2.2
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NGwCe5031472;
>	Fri, 23 Jan 2004 17:58:12 +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-6.6) with ESMTP id i0NGv0e6031429
>	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
>	for <vendor-sec@lst.de>; Fri, 23 Jan 2004 17:57:00 +0100
>Received: from viro by www.linux.org.uk with local (Exim 4.22)
>	id 1Ak4c8-0002TU-0K; Fri, 23 Jan 2004 16:57:00 +0000
>From: viro@parcelfarce.linux.theplanet.co.uk
>To: Paul Starzetz <ihaquer@isec.pl>
>Cc: Solar Designer <solar@openwall.com>,
>	vendor-sec <vendor-sec@lst.de>
>Subject: Re: [vendor-sec] Another serious mremap() vulnerability
>Message-ID: <20040123165659.GH21151@parcelfarce.linux.theplanet.co.uk>
>References: <20040123161635.GG21151@parcelfarce.linux.theplanet.co.uk> <Pine.LNX.4.44.0401231721330.21955-100000@isec.pl>
>Mime-Version: 1.0
>Content-Type: text/plain; charset=us-ascii
>Content-Disposition: inline
>In-Reply-To: <Pine.LNX.4.44.0401231721330.21955-100000@isec.pl>
>User-Agent: Mutt/1.4.1i
>X-Spam-Score: -4.562 () BAYES_00,NO_REAL_NAME
>X-Scanned-By: MIMEDefang 2.39
>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/>
>Date: Fri, 23 Jan 2004 16:56:59 +0000
>X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on 
>	wotan.suse.de
>X-Spam-Level: 
>X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME 
>	autolearn=no version=2.61
>Status: RO
>Content-Length: 1212
>Lines: 24
>
>On Fri, Jan 23, 2004 at 05:25:16PM +0100, Paul Starzetz wrote:
>> On Fri, 23 Jan 2004 viro@parcelfarce.linux.theplanet.co.uk wrote:
>> 
>> > That looks more realistic.  Getting it to BUG() is certainly doable;
>> > getting those PTEs and using it would be much trickier and I don't
>> > see any obvious cases.  Care to give details?
>> 
>> I said in the advisory that the second do_munmap is the realistic (however 
>> difficult) path...
>
>All right, call me dense, but I don't see where the PTEs pointing to those
>pages and having different flags would be able to appear.  Ones we copy
>are copied completely - with flags.  So move_page_tables() is not going
>to do that.  make_pages_present() might cause r/o -> r/w transition, but
>AFAICS it won't hit the PTEs we'd copied.  And after we hit BUG(), there
>won't be any changes at all, so we are limited to the stuff in do_mremap().
>
>I agree that not checking return value of munmap() is a user-exploitable
>bug that should be fixed ASAP, but I still don't see where it would give
>privelege elevation you've mentioned.
>_______________________________________________
>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 23 18:09:08 2004
>Return-Path: <vendor-sec-admin@lst.de>
>Received: from Hermes.suse.de (Hermes.suse.de [10.0.0.1])
>	by wotan.suse.de (Postfix) with ESMTP id C95351072A
>	for <okir@wotan.suse.de>; Fri, 23 Jan 2004 18:09:08 +0100 (CET)
>Received: by Hermes.suse.de (Postfix)
>	id C08A911DEA; Fri, 23 Jan 2004 18:09:08 +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 BA1F111D04
>	for <okir@suse.de>; Fri, 23 Jan 2004 18:09:08 +0100 (CET)
>Received: from mail.lst.de (verein.lst.de [212.34.189.10])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by Cantor.suse.de (Postfix) with ESMTP id 96D348FA1A
>	for <okir@suse.de>; Fri, 23 Jan 2004 18:09:08 +0100 (CET)
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NH98e6031692
>	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
>	for <okir@suse.de>; Fri, 23 Jan 2004 18:09:08 +0100
>Received: (from cyrus@localhost)
>	by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i0NH981V031690
>	for okir@suse.de; Fri, 23 Jan 2004 18:09:08 +0100
>Received: from mail.lst.de ([unix socket])
>	by mail.lst.de (Cyrus v2.1.15-IPv6-Debian-2.1.15-0woody.1.0) with LMTP; Fri, 23 Jan 2004 18:09:07 +0100
>X-Sieve: CMU Sieve 2.2
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NH97e5031684;
>	Fri, 23 Jan 2004 18:09:07 +0100
>Received: from isec.pl (isec.pl [193.110.121.50])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NH8le5031661
>	for <vendor-sec@lst.de>; Fri, 23 Jan 2004 18:08:47 +0100
>Received: by isec.pl (Postfix, from userid 500)
>	id 90C923F22; Fri, 23 Jan 2004 18:08:47 +0100 (CET)
>Received: from localhost (localhost [127.0.0.1])
>	by isec.pl (Postfix) with ESMTP
>	id 804B417695; Fri, 23 Jan 2004 18:08:47 +0100 (CET)
>From: Paul Starzetz <ihaquer@isec.pl>
>To: viro@parcelfarce.linux.theplanet.co.uk
>Cc: Solar Designer <solar@openwall.com>,
>	vendor-sec <vendor-sec@lst.de>
>Subject: Re: [vendor-sec] Another serious mremap() vulnerability
>In-Reply-To: <20040123165659.GH21151@parcelfarce.linux.theplanet.co.uk>
>Message-ID: <Pine.LNX.4.44.0401231804140.21955-100000@isec.pl>
>MIME-Version: 1.0
>Content-Type: TEXT/PLAIN; charset=US-ASCII
>X-Spam-Score: -4.901 () BAYES_00
>X-Scanned-By: MIMEDefang 2.39
>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/>
>Date: Fri, 23 Jan 2004 18:08:47 +0100 (CET)
>X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on 
>	wotan.suse.de
>X-Spam-Level: 
>X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
>	version=2.61
>Status: RO
>Content-Length: 981
>Lines: 27
>
>On Fri, 23 Jan 2004 viro@parcelfarce.linux.theplanet.co.uk wrote:
>
>> All right, call me dense, but I don't see where the PTEs pointing to those
>> pages and having different flags would be able to appear.  Ones we copy
>> are copied completely - with flags.  So move_page_tables() is not going
>
>We learned a technique while writing an exploit for mremap #1 - yes we 
>have code which works without the 2 hours mentioned in the mremap advisory 
>from 05.01.2004 and we are not going to disclose it at this time for 
>obvious reasons.
>
>However I say the second unchecked do_munmap (low mem condition) is _VERY_ 
>easy exploitable assuming we can trigger it.
>
>You can understand that disclosing those details now leads to knowledge 
>how to exploit remap #1 in miliseconds...
>
>-- 
>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  Fri Jan 23 17:21:06 2004
>Return-Path: <vendor-sec-admin@lst.de>
>Received: from Hermes.suse.de (Hermes.suse.de [10.0.0.1])
>	by wotan.suse.de (Postfix) with ESMTP id 0761FE27F
>	for <okir@wotan.suse.de>; Fri, 23 Jan 2004 17:21:06 +0100 (CET)
>Received: by Hermes.suse.de (Postfix)
>	id F402D11E14; Fri, 23 Jan 2004 17:21:05 +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 EEB7711DEA
>	for <okir@suse.de>; Fri, 23 Jan 2004 17:21:05 +0100 (CET)
>Received: from mail.lst.de (verein.lst.de [212.34.189.10])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by Cantor.suse.de (Postfix) with ESMTP id C584E8F550
>	for <okir@suse.de>; Fri, 23 Jan 2004 17:21:05 +0100 (CET)
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NGL5e6030810
>	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
>	for <okir@suse.de>; Fri, 23 Jan 2004 17:21:05 +0100
>Received: (from cyrus@localhost)
>	by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i0NGL5XU030808
>	for okir@suse.de; Fri, 23 Jan 2004 17:21:05 +0100
>Received: from mail.lst.de ([unix socket])
>	by mail.lst.de (Cyrus v2.1.15-IPv6-Debian-2.1.15-0woody.1.0) with LMTP; Fri, 23 Jan 2004 17:21:05 +0100
>X-Sieve: CMU Sieve 2.2
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NGL4e5030805;
>	Fri, 23 Jan 2004 17:21:04 +0100
>Received: from fed1mtao02.cox.net (fed1mtao02.cox.net [68.6.19.243])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NGKde5030786
>	for <vendor-sec@lst.de>; Fri, 23 Jan 2004 17:20:40 +0100
>Received: from Bill-The-Cat ([68.107.142.198]) by fed1mtao02.cox.net
>          (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP
>          id <20040123162023.ESSO27510.fed1mtao02.cox.net@Bill-The-Cat>;
>          Fri, 23 Jan 2004 11:20:23 -0500
>Received: from trini by Bill-The-Cat with local (Exim 3.36 #1 (Debian))
>	id 1Ak42b-0005wH-00; Fri, 23 Jan 2004 09:20:17 -0700
>From: Tom Rini <trini@mvista.com>
>To: Paul Starzetz <ihaquer@isec.pl>
>Cc: Solar Designer <solar@openwall.com>, security@isec.pl,
>	vendor-sec <vendor-sec@lst.de>
>Subject: Re: [vendor-sec] Another serious mremap() vulnerability
>Message-ID: <20040123162017.GN24332@mvista.com>
>References: <20040123151947.GA28650@openwall.com> <Pine.LNX.4.44.0401231640000.21955-100000@isec.pl>
>Mime-Version: 1.0
>Content-Type: multipart/signed; micalg=pgp-sha1;
>	protocol="application/pgp-signature"; boundary="MnLPg7ZWsaic7Fhd"
>Content-Disposition: inline
>In-Reply-To: <Pine.LNX.4.44.0401231640000.21955-100000@isec.pl>
>User-Agent: Mutt/1.5.5.1+cvs20040105i
>X-Spam-Score: -4.901 () BAYES_00
>X-Scanned-By: MIMEDefang 2.39
>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/>
>Date: Fri, 23 Jan 2004 09:20:17 -0700
>X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on 
>	wotan.suse.de
>X-Spam-Level: 
>X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
>	version=2.61
>Status: RO
>Content-Length: 2244
>Lines: 76
>
>
>--MnLPg7ZWsaic7Fhd
>Content-Type: text/plain; charset=us-ascii
>Content-Disposition: inline
>Content-Transfer-Encoding: quoted-printable
>
>On Fri, Jan 23, 2004 at 04:46:57PM +0100, Paul Starzetz wrote:
>> On Fri, 23 Jan 2004, Solar Designer wrote:
>>=20
>> > Have you checked 2.4.23-ow2 / 2.4.24-ow1?  I think I had that fixed.
>> >=20
>> > Do you have an exploit or at least a program to test for vulnerability?
>>=20
>> Seems to be fixed there, indeed.
>
>My read of the ow2 kernel diff shows that the first call do do_munmap()
>doesn't have the return value checked, just a comment about how mappings
>might remain.  So it can't be fixed for all of the possible issue, yes?
>
>And, taken from that patch, a partial fix for the issues would be:
>--- linux-2.4.23/mm/mremap.c	Mon Aug 25 11:44:44 2003
>+++ linux/mm/mremap.c	Thu Dec 18 23:48:06 2003
>@@ -192,6 +192,7 @@
> 			insert_vm_struct(current->mm, new_vma);
> 		}
>=20
>+		/* XXX: possible errors masked, mapping might remain */
> 		do_munmap(current->mm, addr, old_len);
>=20
> 		current->mm->total_vm +=3D new_len >> PAGE_SHIFT;
>@@ -251,16 +264,20 @@
> 		if ((addr <=3D new_addr) && (addr+old_len) > new_addr)
> 			goto out;
>=20
>-		do_munmap(current->mm, new_addr, new_len);
>+		ret =3D do_munmap(current->mm, new_addr, new_len);
>+		if (ret && new_len)
>+			goto out;
> 	}
>=20
> 	/*
> 	 * Always allow a shrinking remap: that just unmaps
> 	 * the unnecessary pages..
> 	 */
>-	ret =3D addr;
> 	if (old_len >=3D new_len) {
>-		do_munmap(current->mm, addr+new_len, old_len - new_len);
>+		ret =3D do_munmap(current->mm, addr+new_len, old_len - new_len);
>+		if (ret && old_len !=3D new_len)
>+			goto out;
>+		ret =3D addr;
> 		if (!(flags & MREMAP_FIXED) || (new_addr =3D=3D addr))
> 			goto out;
> 	}
>
>--=20
>Tom
>
>--MnLPg7ZWsaic7Fhd
>Content-Type: application/pgp-signature; name="signature.asc"
>Content-Description: Digital signature
>Content-Disposition: inline
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.3 (GNU/Linux)
>
>iD8DBQFAEUnBdZngf2G4WwMRAlYlAJ9vR+wOBI4dpOtSa+LQNC9GmejBSgCbBqkZ
>E0HG5Wsw12VfOBXorFAK/kc=
>=MT65
>-----END PGP SIGNATURE-----
>
>--MnLPg7ZWsaic7Fhd--
>_______________________________________________
>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 23 18:29:14 2004
>Return-Path: <vendor-sec-admin@lst.de>
>Received: from Hermes.suse.de (Hermes.suse.de [10.0.0.1])
>	by wotan.suse.de (Postfix) with ESMTP id 0098175FB
>	for <okir@wotan.suse.de>; Fri, 23 Jan 2004 18:29:14 +0100 (CET)
>Received: by Hermes.suse.de (Postfix)
>	id ED93F11DF2; Fri, 23 Jan 2004 18:29:13 +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 DDEE711DEA
>	for <okir@suse.de>; Fri, 23 Jan 2004 18:29:13 +0100 (CET)
>Received: from mail.lst.de (verein.lst.de [212.34.189.10])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by Cantor.suse.de (Postfix) with ESMTP id B5D1F8FC79
>	for <okir@suse.de>; Fri, 23 Jan 2004 18:29:13 +0100 (CET)
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NHTDe6032165
>	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
>	for <okir@suse.de>; Fri, 23 Jan 2004 18:29:13 +0100
>Received: (from cyrus@localhost)
>	by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i0NHTD29032163
>	for okir@suse.de; Fri, 23 Jan 2004 18:29:13 +0100
>Received: from mail.lst.de ([unix socket])
>	by mail.lst.de (Cyrus v2.1.15-IPv6-Debian-2.1.15-0woody.1.0) with LMTP; Fri, 23 Jan 2004 18:29:13 +0100
>X-Sieve: CMU Sieve 2.2
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NHTBe5032159;
>	Fri, 23 Jan 2004 18:29:11 +0100
>Received: from president.dataforce.net (president.dataforce.net [195.42.160.21])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with SMTP id i0NHSDe5032129
>	for <vendor-sec@lst.de>; Fri, 23 Jan 2004 18:28:13 +0100
>Received: (qmail 5184 invoked from network); 23 Jan 2004 17:28:12 -0000
>Received: from localhost (HELO openwall.com) (127.0.0.1)
>  by localhost with SMTP; 23 Jan 2004 17:28:12 -0000
>Received: by openwall.com (Postfix, from userid 503)
>	id EC5E22A0E7; Fri, 23 Jan 2004 20:18:17 +0300 (MSK)
>From: Solar Designer <solar@openwall.com>
>To: Tom Rini <trini@mvista.com>
>Cc: Paul Starzetz <ihaquer@isec.pl>, security@isec.pl,
>	vendor-sec <vendor-sec@lst.de>
>Subject: Re: [vendor-sec] Another serious mremap() vulnerability
>Message-ID: <20040123171817.GA29349@openwall.com>
>References: <20040123151947.GA28650@openwall.com> <Pine.LNX.4.44.0401231640000.21955-100000@isec.pl> <20040123162017.GN24332@mvista.com>
>Mime-Version: 1.0
>Content-Type: text/plain; charset=us-ascii
>Content-Disposition: inline
>In-Reply-To: <20040123162017.GN24332@mvista.com>
>User-Agent: Mutt/1.4.1i
>X-Spam-Score: -4.901 () BAYES_00
>X-Scanned-By: MIMEDefang 2.39
>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/>
>Date: Fri, 23 Jan 2004 20:18:17 +0300
>X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on 
>	wotan.suse.de
>X-Spam-Level: 
>X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
>	version=2.61
>Status: RO
>Content-Length: 1347
>Lines: 36
>
>On Fri, Jan 23, 2004 at 09:20:17AM -0700, Tom Rini wrote:
>> On Fri, Jan 23, 2004 at 04:46:57PM +0100, Paul Starzetz wrote:
>> > On Fri, 23 Jan 2004, Solar Designer wrote:
>> > > Have you checked 2.4.23-ow2 / 2.4.24-ow1?  I think I had that fixed.
>> > > 
>> > > Do you have an exploit or at least a program to test for vulnerability?
>> > 
>> > Seems to be fixed there, indeed.
>> 
>> My read of the ow2 kernel diff shows that the first call do do_munmap()
>> doesn't have the return value checked, just a comment about how mappings
>> might remain.  So it can't be fixed for all of the possible issue, yes?
>
>I don't know a proper action on error for the one (out of three) that
>I did not fix.  I think the code needs to be re-done for that.
>
>But I think Paul's attack does not apply to this one.
>
>> And, taken from that patch, a partial fix for the issues would be:
>
>Yes, -- or you can just use the 2.4.23 mremap patch I had posted to
>vendor-sec previously:
>
>Date: Tue, 30 Dec 2003 03:41:44 +0300
>From: Solar Designer <solar@openwall.com>
>To: Vincent Danen <vdanen@mandrakesoft.com>
>Cc: vendor-sec@lst.de
>Subject: Re: [vendor-sec] Re: mremap
>Message-ID: <20031230004144.GA22863@openwall.com>
>
>-- 
>/sd
>_______________________________________________
>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 23 18:36:25 2004
>Return-Path: <vendor-sec-admin@lst.de>
>Received: from Hermes.suse.de (Hermes.suse.de [10.0.0.1])
>	by wotan.suse.de (Postfix) with ESMTP id F13C8E27F
>	for <okir@wotan.suse.de>; Fri, 23 Jan 2004 18:36:24 +0100 (CET)
>Received: by Hermes.suse.de (Postfix)
>	id ECD7311E0E; Fri, 23 Jan 2004 18:36:24 +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 DCE0311E0A
>	for <okir@suse.de>; Fri, 23 Jan 2004 18:36:24 +0100 (CET)
>Received: from mail.lst.de (verein.lst.de [212.34.189.10])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by Cantor.suse.de (Postfix) with ESMTP id 81FB911E03
>	for <okir@suse.de>; Fri, 23 Jan 2004 18:33:06 +0100 (CET)
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NHX5e6032314
>	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
>	for <okir@suse.de>; Fri, 23 Jan 2004 18:33:06 +0100
>Received: (from cyrus@localhost)
>	by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i0NHX5ax032312
>	for okir@suse.de; Fri, 23 Jan 2004 18:33:05 +0100
>Received: from mail.lst.de ([unix socket])
>	by mail.lst.de (Cyrus v2.1.15-IPv6-Debian-2.1.15-0woody.1.0) with LMTP; Fri, 23 Jan 2004 18:33:05 +0100
>X-Sieve: CMU Sieve 2.2
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NHX5e5032309;
>	Fri, 23 Jan 2004 18:33:05 +0100
>Received: from fed1mtao01.cox.net (fed1mtao01.cox.net [68.6.19.244])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NHWVe5032275
>	for <vendor-sec@lst.de>; Fri, 23 Jan 2004 18:32:32 +0100
>Received: from Bill-The-Cat ([68.107.142.198]) by fed1mtao01.cox.net
>          (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP
>          id <20040123173216.XMYS3322.fed1mtao01.cox.net@Bill-The-Cat>;
>          Fri, 23 Jan 2004 12:32:16 -0500
>Received: from trini by Bill-The-Cat with local (Exim 3.36 #1 (Debian))
>	id 1Ak5AA-0008Md-00; Fri, 23 Jan 2004 10:32:10 -0700
>From: Tom Rini <trini@mvista.com>
>To: Solar Designer <solar@openwall.com>
>Cc: Paul Starzetz <ihaquer@isec.pl>, security@isec.pl,
>	vendor-sec <vendor-sec@lst.de>
>Subject: Re: [vendor-sec] Another serious mremap() vulnerability
>Message-ID: <20040123173210.GS24332@mvista.com>
>References: <20040123151947.GA28650@openwall.com> <Pine.LNX.4.44.0401231640000.21955-100000@isec.pl> <20040123162017.GN24332@mvista.com> <20040123171817.GA29349@openwall.com>
>Mime-Version: 1.0
>Content-Type: multipart/signed; micalg=pgp-sha1;
>	protocol="application/pgp-signature"; boundary="LKTjZJSUETSlgu2t"
>Content-Disposition: inline
>In-Reply-To: <20040123171817.GA29349@openwall.com>
>User-Agent: Mutt/1.5.5.1+cvs20040105i
>X-Spam-Score: -4.901 () BAYES_00
>X-Scanned-By: MIMEDefang 2.39
>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/>
>Date: Fri, 23 Jan 2004 10:32:10 -0700
>X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on 
>	wotan.suse.de
>X-Spam-Level: 
>X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
>	version=2.61
>Status: RO
>Content-Length: 1878
>Lines: 55
>
>
>--LKTjZJSUETSlgu2t
>Content-Type: text/plain; charset=us-ascii
>Content-Disposition: inline
>Content-Transfer-Encoding: quoted-printable
>
>On Fri, Jan 23, 2004 at 08:18:17PM +0300, Solar Designer wrote:
>> On Fri, Jan 23, 2004 at 09:20:17AM -0700, Tom Rini wrote:
>> > On Fri, Jan 23, 2004 at 04:46:57PM +0100, Paul Starzetz wrote:
>> > > On Fri, 23 Jan 2004, Solar Designer wrote:
>> > > > Have you checked 2.4.23-ow2 / 2.4.24-ow1?  I think I had that fixed.
>> > > >=20
>> > > > Do you have an exploit or at least a program to test for vulnerabil=
>ity?
>> > >=20
>> > > Seems to be fixed there, indeed.
>> >=20
>> > My read of the ow2 kernel diff shows that the first call do do_munmap()
>> > doesn't have the return value checked, just a comment about how mappings
>> > might remain.  So it can't be fixed for all of the possible issue, yes?
>>=20
>> I don't know a proper action on error for the one (out of three) that
>> I did not fix.  I think the code needs to be re-done for that.
>>=20
>> But I think Paul's attack does not apply to this one.
>>=20
>> > And, taken from that patch, a partial fix for the issues would be:
>>=20
>> Yes, -- or you can just use the 2.4.23 mremap patch I had posted to
>> vendor-sec previously:
>
>FWIW, what I posted was just the do_munmap portions of that patch (under
>the assumption that the rest of Andrea's comments still are valid).
>
>--=20
>Tom
>
>--LKTjZJSUETSlgu2t
>Content-Type: application/pgp-signature; name="signature.asc"
>Content-Description: Digital signature
>Content-Disposition: inline
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.3 (GNU/Linux)
>
>iD8DBQFAEVqadZngf2G4WwMRAu49AKCXloQtpzaDd3c2y2UqjLu2R/mNpACdEhrH
>1EhvtYxvyLdVJbwrhyh4tiQ=
>=Fl7U
>-----END PGP SIGNATURE-----
>
>--LKTjZJSUETSlgu2t--
>_______________________________________________
>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 23 18:38:00 2004
>Return-Path: <vendor-sec-admin@lst.de>
>Received: from Hermes.suse.de (Hermes.suse.de [10.0.0.1])
>	by wotan.suse.de (Postfix) with ESMTP id 9F95975FB
>	for <okir@wotan.suse.de>; Fri, 23 Jan 2004 18:38:00 +0100 (CET)
>Received: by Hermes.suse.de (Postfix)
>	id 9BA9111D04; Fri, 23 Jan 2004 18:38:00 +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 96D94112E5
>	for <okir@suse.de>; Fri, 23 Jan 2004 18:38:00 +0100 (CET)
>Received: from mail.lst.de (verein.lst.de [212.34.189.10])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by Cantor.suse.de (Postfix) with ESMTP id 38F2F8C024
>	for <okir@suse.de>; Fri, 23 Jan 2004 18:34:06 +0100 (CET)
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NHY5e6032421
>	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
>	for <okir@suse.de>; Fri, 23 Jan 2004 18:34:05 +0100
>Received: (from cyrus@localhost)
>	by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i0NHY5PT032419
>	for okir@suse.de; Fri, 23 Jan 2004 18:34:05 +0100
>Received: from mail.lst.de ([unix socket])
>	by mail.lst.de (Cyrus v2.1.15-IPv6-Debian-2.1.15-0woody.1.0) with LMTP; Fri, 23 Jan 2004 18:34:05 +0100
>X-Sieve: CMU Sieve 2.2
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NHY5e5032416;
>	Fri, 23 Jan 2004 18:34:05 +0100
>Received: from isec.pl (isec.pl [193.110.121.50])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NHX6e5032316
>	for <vendor-sec@lst.de>; Fri, 23 Jan 2004 18:33:06 +0100
>Received: by isec.pl (Postfix, from userid 500)
>	id 465553F22; Fri, 23 Jan 2004 18:32:56 +0100 (CET)
>Received: from localhost (localhost [127.0.0.1])
>	by isec.pl (Postfix) with ESMTP
>	id 361DF17695; Fri, 23 Jan 2004 18:32:56 +0100 (CET)
>From: Paul Starzetz <ihaquer@isec.pl>
>To: Solar Designer <solar@openwall.com>
>Cc: Tom Rini <trini@mvista.com>, <security@isec.pl>,
>	vendor-sec <vendor-sec@lst.de>
>Subject: Re: [vendor-sec] Another serious mremap() vulnerability
>In-Reply-To: <20040123171817.GA29349@openwall.com>
>Message-ID: <Pine.LNX.4.44.0401231830270.21955-100000@isec.pl>
>MIME-Version: 1.0
>Content-Type: TEXT/PLAIN; charset=US-ASCII
>X-Spam-Score: -4.901 () BAYES_00
>X-Scanned-By: MIMEDefang 2.39
>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/>
>Date: Fri, 23 Jan 2004 18:32:56 +0100 (CET)
>X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on 
>	wotan.suse.de
>X-Spam-Level: 
>X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
>	version=2.61
>Status: RO
>Content-Length: 697
>Lines: 23
>
>On Fri, 23 Jan 2004, Solar Designer wrote:
>
>> I don't know a proper action on error for the one (out of three) that
>> I did not fix.  I think the code needs to be re-done for that.
>> 
>> But I think Paul's attack does not apply to this one.
>
>You mean that one unmapping the old location after moving page tables? For 
>me it seems harmless...
>
>Anyway we should consider that the mmap_count should be checked and a vma 
>descriptor allocated before performing any actions in do_mremap.
>
>-- 
>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 29 14:58:19 2004
>Return-Path: <vendor-sec-admin@lst.de>
>Received: from Hermes.suse.de (Hermes.suse.de [10.0.0.1])
>	by wotan.suse.de (Postfix) with ESMTP id F088CEA75
>	for <okir@wotan.suse.de>; Thu, 29 Jan 2004 14:58:18 +0100 (CET)
>Received: by Hermes.suse.de (Postfix)
>	id EC150876A; Thu, 29 Jan 2004 14:58:18 +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 DE886837D
>	for <okir@suse.de>; Thu, 29 Jan 2004 14:58:18 +0100 (CET)
>Received: from mail.lst.de (verein.lst.de [212.34.189.10])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by Cantor.suse.de (Postfix) with ESMTP id 43589CF6DA
>	for <okir@suse.de>; Thu, 29 Jan 2004 14:55:12 +0100 (CET)
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0TDtBQc029973
>	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
>	for <okir@suse.de>; Thu, 29 Jan 2004 14:55:11 +0100
>Received: (from cyrus@localhost)
>	by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i0TDtBqr029971
>	for okir@suse.de; Thu, 29 Jan 2004 14:55:11 +0100
>Received: from mail.lst.de ([unix socket])
>	by mail.lst.de (Cyrus v2.1.15-IPv6-Debian-2.1.15-0woody.1.0) with LMTP; Thu, 29 Jan 2004 14:55:11 +0100
>X-Sieve: CMU Sieve 2.2
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0TDtAQb029967;
>	Thu, 29 Jan 2004 14:55:10 +0100
>Received: from intra.cyclades.com (intra.cyclades.com [64.186.161.6])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0TDsuQb029944
>	for <vendor-sec@lst.de>; Thu, 29 Jan 2004 14:54:56 +0100
>Received: from cm-net-poa-C8B025C6.brdterra.com.br (unknown [200.176.37.198])
>	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
>	(No client certificate requested)
>	by intra.cyclades.com (Postfix) with ESMTP
>	id 6205F8001B4; Thu, 29 Jan 2004 05:50:40 -0800 (PST)
>From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
>X-X-Sender: marcelo@logos.cnet
>To: Tom Rini <trini@mvista.com>
>Cc: Paul Starzetz <ihaquer@isec.pl>,
>	Solar Designer <solar@openwall.com>, security@isec.pl,
>	vendor-sec <vendor-sec@lst.de>,
>	viro@parcelfarce.linux.theplanet.co.uk, andrea@suse.de
>Subject: Re: [vendor-sec] Another serious mremap() vulnerability
>In-Reply-To: <20040123162017.GN24332@mvista.com>
>Message-ID: <Pine.LNX.4.58L.0401291143520.5460@logos.cnet>
>References: <20040123151947.GA28650@openwall.com> <Pine.LNX.4.44.0401231640000.21955-100000@isec.pl>
> <20040123162017.GN24332@mvista.com>
>MIME-Version: 1.0
>Content-Type: TEXT/PLAIN; charset=US-ASCII
>X-Cyclades-MailScanner-Information: Please contact the ISP for more information
>X-Cyclades-MailScanner: Found to be clean
>X-Spam-Score: -4.901 () BAYES_00
>X-Scanned-By: MIMEDefang 2.39
>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/>
>Date: Thu, 29 Jan 2004 11:50:40 -0200 (BRST)
>X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on wotan.suse.de
>X-Spam-Level: 
>X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS 
>	autolearn=no version=2.63
>Status: RO
>Content-Length: 1970
>Lines: 61
>
>
>On Fri, 23 Jan 2004, Tom Rini wrote:
>
>> On Fri, Jan 23, 2004 at 04:46:57PM +0100, Paul Starzetz wrote:
>> > On Fri, 23 Jan 2004, Solar Designer wrote:
>> >
>> > > Have you checked 2.4.23-ow2 / 2.4.24-ow1?  I think I had that fixed.
>> > >
>> > > Do you have an exploit or at least a program to test for vulnerability?
>> >
>> > Seems to be fixed there, indeed.
>>
>> My read of the ow2 kernel diff shows that the first call do do_munmap()
>> doesn't have the return value checked, just a comment about how mappings
>> might remain.  So it can't be fixed for all of the possible issue, yes?
>
>Hum,
>
>About the first do_munmap() call in mremap().
>
>--- linux-2.4.23/mm/mremap.c    Mon Aug 25 11:44:44 2003
>+++ linux/mm/mremap.c   Thu Dec 18 23:48:06 2003
>@@ -192,6 +192,7 @@
>                        insert_vm_struct(current->mm, new_vma);
>                }
>
>+               /* XXX: possible errors masked, mapping might remain */
>                do_munmap(current->mm, addr, old_len);
>
>                current->mm->total_vm += new_len >> PAGE_SHIFT;
>
>
>Why can't we check and propagate the error value of it?
>
>The error return cases in do_munmap() are the following:
>
>	if ((addr & ~PAGE_MASK) || addr > TASK_SIZE || len > TASK_SIZE-addr)
>                return -EINVAL;
>        if ((len = PAGE_ALIGN(len)) == 0)
>                return -EINVAL;
>later on
>        /* If we'll make "hole", check the vm areas limit */
>        if ((mpnt->vm_start < addr && mpnt->vm_end > addr+len)
>            && mm->map_count >= max_map_count)
>                return -ENOMEM;
>        /*
>         * We may need one additional vma to fix up the mappings ...
>         * and this is the last chance for an easy error exit.
>         */
>        extra = kmem_cache_alloc(vm_area_cachep, SLAB_KERNEL);
>        if (!extra)
>                return -ENOMEM;
>
>
>
>
>
>_______________________________________________
>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 29 15:32:55 2004
>Return-Path: <vendor-sec-admin@lst.de>
>Received: from Hermes.suse.de (Hermes.suse.de [10.0.0.1])
>	by wotan.suse.de (Postfix) with ESMTP id B90E6EA75
>	for <okir@wotan.suse.de>; Thu, 29 Jan 2004 15:32:55 +0100 (CET)
>Received: by Hermes.suse.de (Postfix)
>	id B176311E0E; Thu, 29 Jan 2004 15:32:55 +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 AC6A8837D
>	for <okir@suse.de>; Thu, 29 Jan 2004 15:32:55 +0100 (CET)
>Received: from mail.lst.de (verein.lst.de [212.34.189.10])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by Cantor.suse.de (Postfix) with ESMTP id 7918FCFE5C
>	for <okir@suse.de>; Thu, 29 Jan 2004 15:27:10 +0100 (CET)
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0TER9Qc030454
>	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
>	for <okir@suse.de>; Thu, 29 Jan 2004 15:27:10 +0100
>Received: (from cyrus@localhost)
>	by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i0TER9nE030452
>	for okir@suse.de; Thu, 29 Jan 2004 15:27:09 +0100
>Received: from mail.lst.de ([unix socket])
>	by mail.lst.de (Cyrus v2.1.15-IPv6-Debian-2.1.15-0woody.1.0) with LMTP; Thu, 29 Jan 2004 15:27:09 +0100
>X-Sieve: CMU Sieve 2.2
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0TER8Qb030448;
>	Thu, 29 Jan 2004 15:27:08 +0100
>Received: from president.dataforce.net (president.dataforce.net [195.42.160.21])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with SMTP id i0TEQoQb030429
>	for <vendor-sec@lst.de>; Thu, 29 Jan 2004 15:26:50 +0100
>Received: (qmail 8108 invoked from network); 29 Jan 2004 14:26:49 -0000
>Received: from localhost (HELO openwall.com) (127.0.0.1)
>  by localhost with SMTP; 29 Jan 2004 14:26:49 -0000
>Received: by openwall.com (Postfix, from userid 503)
>	id D6EF92A0E7; Thu, 29 Jan 2004 17:16:02 +0300 (MSK)
>From: Solar Designer <solar@openwall.com>
>To: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
>Cc: Tom Rini <trini@mvista.com>, Paul Starzetz <ihaquer@isec.pl>,
>	security@isec.pl, vendor-sec <vendor-sec@lst.de>,
>	viro@parcelfarce.linux.theplanet.co.uk, andrea@suse.de
>Subject: Re: [vendor-sec] Another serious mremap() vulnerability
>Message-ID: <20040129141602.GB5113@openwall.com>
>References: <20040123151947.GA28650@openwall.com> <Pine.LNX.4.44.0401231640000.21955-100000@isec.pl> <20040123162017.GN24332@mvista.com> <Pine.LNX.4.58L.0401291143520.5460@logos.cnet>
>Mime-Version: 1.0
>Content-Type: text/plain; charset=us-ascii
>Content-Disposition: inline
>In-Reply-To: <Pine.LNX.4.58L.0401291143520.5460@logos.cnet>
>User-Agent: Mutt/1.4.1i
>X-Spam-Score: -4.901 () BAYES_00
>X-Scanned-By: MIMEDefang 2.39
>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/>
>Date: Thu, 29 Jan 2004 17:16:02 +0300
>X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on wotan.suse.de
>X-Spam-Level: 
>X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
>	version=2.63
>Status: RO
>Content-Length: 1180
>Lines: 37
>
>On Thu, Jan 29, 2004 at 11:50:40AM -0200, Marcelo Tosatti wrote:
>> About the first do_munmap() call in mremap().
>> 
>> --- linux-2.4.23/mm/mremap.c    Mon Aug 25 11:44:44 2003
>> +++ linux/mm/mremap.c   Thu Dec 18 23:48:06 2003
>> @@ -192,6 +192,7 @@
>>                         insert_vm_struct(current->mm, new_vma);
>>                 }
>> 
>> +               /* XXX: possible errors masked, mapping might remain */
>>                 do_munmap(current->mm, addr, old_len);
>> 
>>                 current->mm->total_vm += new_len >> PAGE_SHIFT;
>> 
>> 
>> Why can't we check and propagate the error value of it?
>
>Because mremap() has done much work at this point, so neither error
>nor successful return would be entirely right.
>
>> The error return cases in do_munmap() are the following:
>
>> later on
>
>>         extra = kmem_cache_alloc(vm_area_cachep, SLAB_KERNEL);
>>         if (!extra)
>>                 return -ENOMEM;
>
>I think this one is the most problematic because it can't be reliably
>predicted at the start of mremap.
>
>-- 
>/sd
>_______________________________________________
>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 29 15:38:01 2004
>Return-Path: <vendor-sec-admin@lst.de>
>Received: from Hermes.suse.de (Hermes.suse.de [10.0.0.1])
>	by wotan.suse.de (Postfix) with ESMTP id 3A566EAC8
>	for <okir@wotan.suse.de>; Thu, 29 Jan 2004 15:38:01 +0100 (CET)
>Received: by Hermes.suse.de (Postfix)
>	id 32CAB11E1C; Thu, 29 Jan 2004 15:38:01 +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 2CEA88974
>	for <okir@suse.de>; Thu, 29 Jan 2004 15:38:01 +0100 (CET)
>Received: from mail.lst.de (verein.lst.de [212.34.189.10])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by Cantor.suse.de (Postfix) with ESMTP id 8BB06CEFBB
>	for <okir@suse.de>; Thu, 29 Jan 2004 15:32:12 +0100 (CET)
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0TEWCQc030605
>	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
>	for <okir@suse.de>; Thu, 29 Jan 2004 15:32:12 +0100
>Received: (from cyrus@localhost)
>	by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i0TEWCK7030603
>	for okir@suse.de; Thu, 29 Jan 2004 15:32:12 +0100
>Received: from mail.lst.de ([unix socket])
>	by mail.lst.de (Cyrus v2.1.15-IPv6-Debian-2.1.15-0woody.1.0) with LMTP; Thu, 29 Jan 2004 15:32:11 +0100
>X-Sieve: CMU Sieve 2.2
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0TEWBQb030599;
>	Thu, 29 Jan 2004 15:32:11 +0100
>Received: from isec.pl (isec.pl [193.110.121.50])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0TEVLQb030571
>	for <vendor-sec@lst.de>; Thu, 29 Jan 2004 15:31:21 +0100
>Received: by isec.pl (Postfix, from userid 500)
>	id 0710D3F80; Thu, 29 Jan 2004 15:31:00 +0100 (CET)
>Received: from localhost (localhost [127.0.0.1])
>	by isec.pl (Postfix) with ESMTP
>	id EC93F176DD; Thu, 29 Jan 2004 15:31:00 +0100 (CET)
>From: Paul Starzetz <ihaquer@isec.pl>
>To: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
>Cc: Tom Rini <trini@mvista.com>, Solar Designer <solar@openwall.com>,
>	<security@isec.pl>, vendor-sec <vendor-sec@lst.de>,
>	<viro@parcelfarce.linux.theplanet.co.uk>, <andrea@suse.de>
>Subject: Re: [vendor-sec] Another serious mremap() vulnerability
>In-Reply-To: <Pine.LNX.4.58L.0401291143520.5460@logos.cnet>
>Message-ID: <Pine.LNX.4.44.0401291527480.21463-100000@isec.pl>
>MIME-Version: 1.0
>Content-Type: TEXT/PLAIN; charset=US-ASCII
>X-Spam-Score: -4.901 () BAYES_00
>X-Scanned-By: MIMEDefang 2.39
>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/>
>Date: Thu, 29 Jan 2004 15:31:00 +0100 (CET)
>X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on wotan.suse.de
>X-Spam-Level: 
>X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
>	version=2.63
>Content-Length: 564
>Lines: 21
>
>> Hum,
>> 
>> Why can't we check and propagate the error value of it?
>
>We even must do that. In my opinion a kernel API should not have any side 
>effect. That would be the case if unmapping of the old location could 
>fail and potentially confuse / break the application.
>
>A kernel call should do something or do nothing on error (in the ideal 
>case).
>
>-- 
>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 29 15:47:00 2004
>Return-Path: <vendor-sec-admin@lst.de>
>Received: from Hermes.suse.de (Hermes.suse.de [10.0.0.1])
>	by wotan.suse.de (Postfix) with ESMTP id 8C10315547
>	for <okir@wotan.suse.de>; Thu, 29 Jan 2004 15:47:00 +0100 (CET)
>Received: by Hermes.suse.de (Postfix)
>	id 8417711E0B; Thu, 29 Jan 2004 15:47:00 +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 7DCB011EFD
>	for <okir@suse.de>; Thu, 29 Jan 2004 15:47:00 +0100 (CET)
>Received: from mail.lst.de (verein.lst.de [212.34.189.10])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by Cantor.suse.de (Postfix) with ESMTP id 301D9CF3A3
>	for <okir@suse.de>; Thu, 29 Jan 2004 15:40:09 +0100 (CET)
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0TEe8Qc030790
>	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
>	for <okir@suse.de>; Thu, 29 Jan 2004 15:40:08 +0100
>Received: (from cyrus@localhost)
>	by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i0TEe8P7030788
>	for okir@suse.de; Thu, 29 Jan 2004 15:40:08 +0100
>Received: from mail.lst.de ([unix socket])
>	by mail.lst.de (Cyrus v2.1.15-IPv6-Debian-2.1.15-0woody.1.0) with LMTP; Thu, 29 Jan 2004 15:40:08 +0100
>X-Sieve: CMU Sieve 2.2
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0TEe7Qb030784;
>	Thu, 29 Jan 2004 15:40:07 +0100
>Received: from isec.pl (isec.pl [193.110.121.50])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0TEdtQb030765
>	for <vendor-sec@lst.de>; Thu, 29 Jan 2004 15:39:56 +0100
>Received: by isec.pl (Postfix, from userid 500)
>	id D04413F7F; Thu, 29 Jan 2004 15:39:55 +0100 (CET)
>Received: from localhost (localhost [127.0.0.1])
>	by isec.pl (Postfix) with ESMTP
>	id C076E176D1; Thu, 29 Jan 2004 15:39:55 +0100 (CET)
>From: Paul Starzetz <ihaquer@isec.pl>
>To: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
>Cc: Tom Rini <trini@mvista.com>, Solar Designer <solar@openwall.com>,
>	<security@isec.pl>, vendor-sec <vendor-sec@lst.de>,
>	<viro@parcelfarce.linux.theplanet.co.uk>, <andrea@suse.de>
>In-Reply-To: <Pine.LNX.4.58L.0401291143520.5460@logos.cnet>
>Message-ID: <Pine.LNX.4.44.0401291538220.22565-100000@isec.pl>
>MIME-Version: 1.0
>Content-Type: TEXT/PLAIN; charset=US-ASCII
>X-Spam-Score: -4.901 () BAYES_00
>X-Scanned-By: MIMEDefang 2.39
>Subject: [vendor-sec] Btw kernel 2.2.25 also vulnerable to mremap bug #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/>
>Date: Thu, 29 Jan 2004 15:39:55 +0100 (CET)
>X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on wotan.suse.de
>X-Spam-Level: 
>X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
>	version=2.63
>Content-Length: 332
>Lines: 15
>
>Hi,
>
>do not forget that one in your patches. The exploitation is slightly 
>different on <=2.2.25 but also very easy.
>
>-- 
>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 29 15:50:44 2004
>Return-Path: <vendor-sec-admin@lst.de>
>Received: from Hermes.suse.de (Hermes.suse.de [10.0.0.1])
>	by wotan.suse.de (Postfix) with ESMTP id 05278EA88
>	for <okir@wotan.suse.de>; Thu, 29 Jan 2004 15:50:44 +0100 (CET)
>Received: by Hermes.suse.de (Postfix)
>	id ED66811E0B; Thu, 29 Jan 2004 15:50:43 +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 E25E611E52
>	for <okir@suse.de>; Thu, 29 Jan 2004 15:50:43 +0100 (CET)
>Received: from mail.lst.de (verein.lst.de [212.34.189.10])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by Cantor.suse.de (Postfix) with ESMTP id 212E29D25A
>	for <okir@suse.de>; Thu, 29 Jan 2004 15:50:11 +0100 (CET)
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0TEoAQc030991
>	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
>	for <okir@suse.de>; Thu, 29 Jan 2004 15:50:10 +0100
>Received: (from cyrus@localhost)
>	by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i0TEoA53030989
>	for okir@suse.de; Thu, 29 Jan 2004 15:50:10 +0100
>Received: from mail.lst.de ([unix socket])
>	by mail.lst.de (Cyrus v2.1.15-IPv6-Debian-2.1.15-0woody.1.0) with LMTP; Thu, 29 Jan 2004 15:50:10 +0100
>X-Sieve: CMU Sieve 2.2
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0TEo9Qb030985;
>	Thu, 29 Jan 2004 15:50:09 +0100
>Received: from president.dataforce.net (president.dataforce.net [195.42.160.21])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with SMTP id i0TEnnQb030966
>	for <vendor-sec@lst.de>; Thu, 29 Jan 2004 15:49:49 +0100
>Received: (qmail 11477 invoked from network); 29 Jan 2004 14:49:48 -0000
>Received: from localhost (HELO openwall.com) (127.0.0.1)
>  by localhost with SMTP; 29 Jan 2004 14:49:48 -0000
>Received: by openwall.com (Postfix, from userid 503)
>	id 7B9FE2A0E7; Thu, 29 Jan 2004 17:39:21 +0300 (MSK)
>From: Solar Designer <solar@openwall.com>
>To: Paul Starzetz <ihaquer@isec.pl>
>Cc: Marcelo Tosatti <marcelo.tosatti@cyclades.com>,
>	Tom Rini <trini@mvista.com>, security@isec.pl,
>	vendor-sec <vendor-sec@lst.de>,
>	viro@parcelfarce.linux.theplanet.co.uk, andrea@suse.de
>Message-ID: <20040129143921.GA5300@openwall.com>
>References: <Pine.LNX.4.58L.0401291143520.5460@logos.cnet> <Pine.LNX.4.44.0401291538220.22565-100000@isec.pl>
>Mime-Version: 1.0
>Content-Type: text/plain; charset=us-ascii
>Content-Disposition: inline
>In-Reply-To: <Pine.LNX.4.44.0401291538220.22565-100000@isec.pl>
>User-Agent: Mutt/1.4.1i
>X-Spam-Score: -4.901 () BAYES_00
>X-Scanned-By: MIMEDefang 2.39
>Subject: [vendor-sec] Re: Btw kernel 2.2.25 also vulnerable to mremap bug #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/>
>Date: Thu, 29 Jan 2004 17:39:21 +0300
>X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on wotan.suse.de
>X-Spam-Level: 
>X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
>	version=2.63
>Content-Length: 921
>Lines: 26
>
>On Thu, Jan 29, 2004 at 03:39:55PM +0100, Paul Starzetz wrote:
>> do not forget that one in your patches. The exploitation is slightly 
>> different on <=2.2.25 but also very easy.
>
>Are you sure?  Can you provide more details?
>
>On 2.2.x, there're two calls to do_munmap() from mremap.c.  One is in
>move_vma() and it's the same one that we aren't fixing on 2.4.x yet
>and that you previously said is mostly harmless.  The other is:
>
>        if (old_len >= new_len) {
>                do_munmap(addr+new_len, old_len - new_len);
>                goto out;
>
>But it's immediately followed by the "goto out", which leaves the
>syscall.  There's no error return to the application which is bad, but
>there's no in-kernel problem caused by this.
>
>Am I missing something?
>
>-- 
>/sd
>_______________________________________________
>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 29 16:07:09 2004
>Return-Path: <vendor-sec-admin@lst.de>
>Received: from Hermes.suse.de (Hermes.suse.de [10.0.0.1])
>	by wotan.suse.de (Postfix) with ESMTP id CB05F156BB
>	for <okir@wotan.suse.de>; Thu, 29 Jan 2004 16:07:09 +0100 (CET)
>Received: by Hermes.suse.de (Postfix)
>	id C6EC1C71F; Thu, 29 Jan 2004 16:07:09 +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 C2812876A
>	for <okir@suse.de>; Thu, 29 Jan 2004 16:07:09 +0100 (CET)
>Received: from mail.lst.de (verein.lst.de [212.34.189.10])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by Cantor.suse.de (Postfix) with ESMTP id A2469B46D1
>	for <okir@suse.de>; Thu, 29 Jan 2004 16:07:09 +0100 (CET)
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0TF79Qc031368
>	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
>	for <okir@suse.de>; Thu, 29 Jan 2004 16:07:09 +0100
>Received: (from cyrus@localhost)
>	by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i0TF79YC031366
>	for okir@suse.de; Thu, 29 Jan 2004 16:07:09 +0100
>Received: from mail.lst.de ([unix socket])
>	by mail.lst.de (Cyrus v2.1.15-IPv6-Debian-2.1.15-0woody.1.0) with LMTP; Thu, 29 Jan 2004 16:07:08 +0100
>X-Sieve: CMU Sieve 2.2
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0TF78Qb031363;
>	Thu, 29 Jan 2004 16:07:08 +0100
>Received: from isec.pl (isec.pl [193.110.121.50])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0TF6hQb031344
>	for <vendor-sec@lst.de>; Thu, 29 Jan 2004 16:06:44 +0100
>Received: by isec.pl (Postfix, from userid 500)
>	id BFC103F7F; Thu, 29 Jan 2004 16:06:38 +0100 (CET)
>Received: from localhost (localhost [127.0.0.1])
>	by isec.pl (Postfix) with ESMTP
>	id ADCD8176DD; Thu, 29 Jan 2004 16:06:38 +0100 (CET)
>From: Paul Starzetz <ihaquer@isec.pl>
>To: Solar Designer <solar@openwall.com>
>Cc: Marcelo Tosatti <marcelo.tosatti@cyclades.com>,
>	Tom Rini <trini@mvista.com>, <security@isec.pl>,
>	vendor-sec <vendor-sec@lst.de>,
>	<viro@parcelfarce.linux.theplanet.co.uk>, <andrea@suse.de>
>In-Reply-To: <20040129143921.GA5300@openwall.com>
>Message-ID: <Pine.LNX.4.44.0401291603310.22565-100000@isec.pl>
>MIME-Version: 1.0
>Content-Type: TEXT/PLAIN; charset=US-ASCII
>X-Spam-Score: -4.901 () BAYES_00
>X-Scanned-By: MIMEDefang 2.39
>Subject: [vendor-sec] Re: Btw kernel 2.2.25 also vulnerable to mremap bug #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/>
>Date: Thu, 29 Jan 2004 16:06:38 +0100 (CET)
>X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on wotan.suse.de
>X-Spam-Level: 
>X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
>	version=2.63
>Status: RO
>Content-Length: 760
>Lines: 24
>
>On Thu, 29 Jan 2004, Solar Designer wrote:
>
>> On 2.2.x, there're two calls to do_munmap() from mremap.c.  One is in
>> move_vma() and it's the same one that we aren't fixing on 2.4.x yet
>> and that you previously said is mostly harmless.  The other is:
>> 
>>         if (old_len >= new_len) {
>>                 do_munmap(addr+new_len, old_len - new_len);
>>                 goto out;
>
>Uhh you are right.
>I missed that goto, just looked roughly at move_vma. However it is looking 
>like that on 2.2.25 mremap is exploitable through bad TLB handling.
>
>-- 
>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 29 16:22:34 2004
>Return-Path: <vendor-sec-admin@lst.de>
>Received: from Hermes.suse.de (Hermes.suse.de [10.0.0.1])
>	by wotan.suse.de (Postfix) with ESMTP id 752E8156CD
>	for <okir@wotan.suse.de>; Thu, 29 Jan 2004 16:22:34 +0100 (CET)
>Received: by Hermes.suse.de (Postfix)
>	id 6C343123E7; Thu, 29 Jan 2004 16:22:34 +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 6419812591
>	for <okir@suse.de>; Thu, 29 Jan 2004 16:22:34 +0100 (CET)
>Received: from mail.lst.de (verein.lst.de [212.34.189.10])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by Cantor.suse.de (Postfix) with ESMTP id BA387CE1D1
>	for <okir@suse.de>; Thu, 29 Jan 2004 16:17:09 +0100 (CET)
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0TFH9Qc031571
>	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
>	for <okir@suse.de>; Thu, 29 Jan 2004 16:17:09 +0100
>Received: (from cyrus@localhost)
>	by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i0TFH9QC031569
>	for okir@suse.de; Thu, 29 Jan 2004 16:17:09 +0100
>Received: from mail.lst.de ([unix socket])
>	by mail.lst.de (Cyrus v2.1.15-IPv6-Debian-2.1.15-0woody.1.0) with LMTP; Thu, 29 Jan 2004 16:17:09 +0100
>X-Sieve: CMU Sieve 2.2
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0TFH8Qb031565;
>	Thu, 29 Jan 2004 16:17:08 +0100
>Received: from president.dataforce.net (president.dataforce.net [195.42.160.21])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with SMTP id i0TFGcQb031546
>	for <vendor-sec@lst.de>; Thu, 29 Jan 2004 16:16:38 +0100
>Received: (qmail 15428 invoked from network); 29 Jan 2004 15:16:37 -0000
>Received: from localhost (HELO openwall.com) (127.0.0.1)
>  by localhost with SMTP; 29 Jan 2004 15:16:37 -0000
>Received: by openwall.com (Postfix, from userid 503)
>	id E6DF82A0E8; Thu, 29 Jan 2004 18:06:06 +0300 (MSK)
>From: Solar Designer <solar@openwall.com>
>To: Paul Starzetz <ihaquer@isec.pl>
>Cc: Marcelo Tosatti <marcelo.tosatti@cyclades.com>,
>	Tom Rini <trini@mvista.com>, security@isec.pl,
>	vendor-sec <vendor-sec@lst.de>,
>	viro@parcelfarce.linux.theplanet.co.uk, andrea@suse.de
>Message-ID: <20040129150606.GB5414@openwall.com>
>References: <20040129143921.GA5300@openwall.com> <Pine.LNX.4.44.0401291603310.22565-100000@isec.pl>
>Mime-Version: 1.0
>Content-Type: text/plain; charset=us-ascii
>Content-Disposition: inline
>In-Reply-To: <Pine.LNX.4.44.0401291603310.22565-100000@isec.pl>
>User-Agent: Mutt/1.4.1i
>X-Spam-Score: -4.901 () BAYES_00
>X-Scanned-By: MIMEDefang 2.39
>Subject: [vendor-sec] Re: Btw kernel 2.2.25 also vulnerable to mremap bug #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/>
>Date: Thu, 29 Jan 2004 18:06:06 +0300
>X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on wotan.suse.de
>X-Spam-Level: 
>X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
>	version=2.63
>Status: RO
>Content-Length: 717
>Lines: 19
>
>On Thu, Jan 29, 2004 at 04:06:38PM +0100, Paul Starzetz wrote:
>> However it is looking 
>> like that on 2.2.25 mremap is exploitable through bad TLB handling.
>
>Can you elaborate, or better yet produce a proof-of-concept?  I doubt
>anyone would look into that and especially not get a fix into a 2.2.26
>otherwise. :-(
>
>A lot of systems still use 2.2.x.  I am co-administering some with
>uptimes of 400-500 days, which, unlike the 2.4.x's, didn't require to
>be rebooted as they were not vulnerable to the worst of the security
>holes discovered in that time.
>
>-- 
>/sd
>_______________________________________________
>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 29 16:38:39 2004
>Return-Path: <vendor-sec-admin@lst.de>
>Received: from Hermes.suse.de (Hermes.suse.de [10.0.0.1])
>	by wotan.suse.de (Postfix) with ESMTP id 5DD877D07
>	for <okir@wotan.suse.de>; Thu, 29 Jan 2004 16:38:39 +0100 (CET)
>Received: by Hermes.suse.de (Postfix)
>	id 57AAB11E0B; Thu, 29 Jan 2004 16:38:39 +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 52BE4C71F
>	for <okir@suse.de>; Thu, 29 Jan 2004 16:38:39 +0100 (CET)
>Received: from mail.lst.de (verein.lst.de [212.34.189.10])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by Cantor.suse.de (Postfix) with ESMTP id EFE64CEC49
>	for <okir@suse.de>; Thu, 29 Jan 2004 16:30:18 +0100 (CET)
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0TFUGQc031797
>	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
>	for <okir@suse.de>; Thu, 29 Jan 2004 16:30:16 +0100
>Received: (from cyrus@localhost)
>	by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i0TFUGRp031795
>	for okir@suse.de; Thu, 29 Jan 2004 16:30:16 +0100
>Received: from mail.lst.de ([unix socket])
>	by mail.lst.de (Cyrus v2.1.15-IPv6-Debian-2.1.15-0woody.1.0) with LMTP; Thu, 29 Jan 2004 16:30:16 +0100
>X-Sieve: CMU Sieve 2.2
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0TFUFQb031792;
>	Thu, 29 Jan 2004 16:30:15 +0100
>Received: from isec.pl (isec.pl [193.110.121.50])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0TFTWQb031763
>	for <vendor-sec@lst.de>; Thu, 29 Jan 2004 16:29:33 +0100
>Received: by isec.pl (Postfix, from userid 500)
>	id 84C463F7F; Thu, 29 Jan 2004 16:29:27 +0100 (CET)
>Received: from localhost (localhost [127.0.0.1])
>	by isec.pl (Postfix) with ESMTP
>	id 734B4176C9; Thu, 29 Jan 2004 16:29:27 +0100 (CET)
>From: Paul Starzetz <ihaquer@isec.pl>
>To: Solar Designer <solar@openwall.com>
>Cc: Marcelo Tosatti <marcelo.tosatti@cyclades.com>,
>	Tom Rini <trini@mvista.com>, <security@isec.pl>,
>	vendor-sec <vendor-sec@lst.de>,
>	<viro@parcelfarce.linux.theplanet.co.uk>, <andrea@suse.de>
>In-Reply-To: <20040129150606.GB5414@openwall.com>
>Message-ID: <Pine.LNX.4.44.0401291623180.22784-100000@isec.pl>
>MIME-Version: 1.0
>Content-Type: TEXT/PLAIN; charset=US-ASCII
>X-Spam-Score: -4.901 () BAYES_00
>X-Scanned-By: MIMEDefang 2.39
>Subject: [vendor-sec] Re: Btw kernel 2.2.25 also vulnerable to mremap bug #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/>
>Date: Thu, 29 Jan 2004 16:29:27 +0100 (CET)
>X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on wotan.suse.de
>X-Spam-Level: 
>X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
>	version=2.63
>Status: RO
>Content-Length: 1546
>Lines: 52
>
>On Thu, 29 Jan 2004, Solar Designer wrote:
>
>> Can you elaborate, or better yet produce a proof-of-concept?  I doubt
>> anyone would look into that and especially not get a fix into a 2.2.26
>> otherwise. :-(
>
>lets take a look at:
>
>
>static int move_page_tables(struct mm_struct * mm,
>	unsigned long new_addr, unsigned long old_addr, unsigned long len)
>{
>	unsigned long offset = len;
>
>	flush_cache_range(mm, old_addr, old_addr + len);
>[*]	flush_tlb_range(mm, old_addr, old_addr + len);
>
>	/*
>	 * This is not the clever way to do this, but we're taking the
>	 * easy way out on the assumption that most remappings will be
>	 * only a few pages.. This also makes error recovery easier.
>	 */
>	while (offset) {
>		offset -= PAGE_SIZE;
>		if (move_one_page(mm, old_addr + offset, new_addr + 
>offset))
>			goto oops_we_failed;
>	}
>	return 0;
>......
>}
>
>at [*] the TLBs for the old location are invalidated, but the PTEs are 
>moved in the loop later. That means: if we sleep in move_one_page (I can 
>do that ;-) another thread with shared VM could populate the TLB just 
>accessing the old location. Then the new location may be unmapped, thus 
>the page counters would go to 0, pages would be released to the MM but we 
>could hold the TLB as long as the PGD is not switched. The released pages 
>may be allocated to the fd array etc..
>
>does this help?
>
>-- 
>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  Tue Jan 27 15:29:17 2004
>Return-Path: <vendor-sec-admin@lst.de>
>Received: from Hermes.suse.de (Hermes.suse.de [10.0.0.1])
>	by wotan.suse.de (Postfix) with ESMTP id CEFE8EAC7
>	for <okir@wotan.suse.de>; Tue, 27 Jan 2004 15:29:17 +0100 (CET)
>Received: by Hermes.suse.de (Postfix)
>	id C9F9711E72; Tue, 27 Jan 2004 15:29:17 +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 C438A11E55
>	for <okir@suse.de>; Tue, 27 Jan 2004 15:29:17 +0100 (CET)
>Received: from mail.lst.de (verein.lst.de [212.34.189.10])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by Cantor.suse.de (Postfix) with ESMTP id A2525B54AC
>	for <okir@suse.de>; Tue, 27 Jan 2004 15:29:17 +0100 (CET)
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0RETHQc020036
>	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
>	for <okir@suse.de>; Tue, 27 Jan 2004 15:29:17 +0100
>Received: (from cyrus@localhost)
>	by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i0RETH3i020034
>	for okir@suse.de; Tue, 27 Jan 2004 15:29:17 +0100
>Received: from mail.lst.de ([unix socket])
>	by mail.lst.de (Cyrus v2.1.15-IPv6-Debian-2.1.15-0woody.1.0) with LMTP; Tue, 27 Jan 2004 15:29:17 +0100
>X-Sieve: CMU Sieve 2.2
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0RETFQb020031;
>	Tue, 27 Jan 2004 15:29:15 +0100
>Received: from isec.pl (isec.pl [193.110.121.50])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0RESYQb020002
>	for <vendor-sec@lst.de>; Tue, 27 Jan 2004 15:28:35 +0100
>Received: by isec.pl (Postfix, from userid 500)
>	id 7ED5B3F47; Tue, 27 Jan 2004 15:28:19 +0100 (CET)
>Received: from localhost (localhost [127.0.0.1])
>	by isec.pl (Postfix) with ESMTP
>	id 6E2C7176C3; Tue, 27 Jan 2004 15:28:19 +0100 (CET)
>From: Paul Starzetz <ihaquer@isec.pl>
>Reply-To: security@isec.pl
>To: vendor-sec <vendor-sec@lst.de>
>Message-ID: <Pine.LNX.4.44.0401271522360.8787-100000@isec.pl>
>MIME-Version: 1.0
>Content-Type: TEXT/PLAIN; charset=US-ASCII
>X-Spam-Score: -4.901 () BAYES_00
>X-Scanned-By: MIMEDefang 2.39
>Subject: [vendor-sec] mremap bug very serious
>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/>
>Date: Tue, 27 Jan 2004 15:28:13 +0100 (CET)
>X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on 
>	wotan.suse.de
>X-Spam-Level: 
>X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham 
>	version=2.61
>Status: RO
>Content-Length: 771
>Lines: 32
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Hi,
>
>I would really like to fix the disclosure date for the mremap() 
>do_munmap bug. So can we agree on the 09-02-2004?
>
>The issue is much more serious that I originally thought. We were able to 
>create a proof-of-concept giving uid=0 immediatelly (without hitting any 
>races etc). Tested on vanilla 2.4.24.
>
>regards
>
>- -- 
>Paul Starzetz
>iSEC Security Research
>http://isec.pl/
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.0.7 (GNU/Linux)
>
>iD8DBQFAFnWDC+8U3Z5wpu4RAqk7AJsFg3ShdmtHwbJolnb+ZrBBD0GHMgCfS8zc
>53zWJ46x/KN66gPfoA9zGi4=
>=btFh
>-----END PGP SIGNATURE-----
>
>
>_______________________________________________
>Vendor Security mailing list
>Vendor Security@lst.de
>https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec
>
>From vendor-sec-admin@lst.de  Tue Jan 27 15:43:18 2004
>Return-Path: <vendor-sec-admin@lst.de>
>Received: from Hermes.suse.de (Hermes.suse.de [10.0.0.1])
>	by wotan.suse.de (Postfix) with ESMTP id 7A4B9EAC7
>	for <okir@wotan.suse.de>; Tue, 27 Jan 2004 15:43:18 +0100 (CET)
>Received: by Hermes.suse.de (Postfix)
>	id 77C21C6DC; Tue, 27 Jan 2004 15:43:18 +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 726D6821C
>	for <okir@suse.de>; Tue, 27 Jan 2004 15:43:18 +0100 (CET)
>Received: from mail.lst.de (verein.lst.de [212.34.189.10])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by Cantor.suse.de (Postfix) with ESMTP id BA890B45A1
>	for <okir@suse.de>; Tue, 27 Jan 2004 15:43:09 +0100 (CET)
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0REh9Qc020460
>	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
>	for <okir@suse.de>; Tue, 27 Jan 2004 15:43:09 +0100
>Received: (from cyrus@localhost)
>	by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i0REh907020458
>	for okir@suse.de; Tue, 27 Jan 2004 15:43:09 +0100
>Received: from mail.lst.de ([unix socket])
>	by mail.lst.de (Cyrus v2.1.15-IPv6-Debian-2.1.15-0woody.1.0) with LMTP; Tue, 27 Jan 2004 15:43:09 +0100
>X-Sieve: CMU Sieve 2.2
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0REh7Qb020454;
>	Tue, 27 Jan 2004 15:43:07 +0100
>Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0REgdQb020432
>	for <vendor-sec@lst.de>; Tue, 27 Jan 2004 15:42:39 +0100
>Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
>	by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id i0REgQr00995;
>	Tue, 27 Jan 2004 09:42:26 -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 i0REgQa14583;
>	Tue, 27 Jan 2004 09:42:26 -0500
>Received: from dell1.moose.awe.com (mjc-cipe.stuttgart.redhat.com [172.16.3.26])
>	by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id i0REgPR2005790;
>	Tue, 27 Jan 2004 09:42:25 -0500
>Received: from dell1.moose.awe.com ([127.0.0.1] helo=localhost)
>	by dell1.moose.awe.com with esmtp (Exim 4.05)
>	id 1AlUQ9-0004dY-00; Tue, 27 Jan 2004 14:42:30 +0000
>From: Mark J Cox <mjc@redhat.com>
>X-X-Sender: mark@dell1.moose.awe.com
>To: security@isec.pl
>Cc: vendor-sec <vendor-sec@lst.de>
>Subject: Re: [vendor-sec] mremap bug very serious
>In-Reply-To: <Pine.LNX.4.44.0401271522360.8787-100000@isec.pl>
>Message-ID: <Pine.LNX.4.58.0401271440160.17782@dell1.moose.awe.com>
>References: <Pine.LNX.4.44.0401271522360.8787-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
>X-Spam-Score: -4.901 () BAYES_00
>X-Scanned-By: MIMEDefang 2.39
>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/>
>Date: Tue, 27 Jan 2004 14:42:29 +0000 (GMT)
>X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on 
>	wotan.suse.de
>X-Spam-Level: 
>X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
>	version=2.61
>Status: RO
>Content-Length: 1291
>Lines: 39
>
>We always prefer Wednesdays for updates (because usually on Mondays
>administrators are busy removing a weekends worth of spam from their
>mailboxes), so whilst Feb11 would be better, Feb09 is okay.
>
>(reminder: CAN-2003-0077)
>
>Thanks, Mark
>-- 
>Mark J Cox / Red Hat Security Response Team
>
>On Tue, 27 Jan 2004, Paul Starzetz wrote:
>
>> --[PinePGP]--------------------------------------------------[begin]--
>> Hi,
>> 
>> I would really like to fix the disclosure date for the mremap()
>> do_munmap bug. So can we agree on the 09-02-2004?
>> 
>> The issue is much more serious that I originally thought. We were able to
>> create a proof-of-concept giving uid=0 immediatelly (without hitting any
>> races etc). Tested on vanilla 2.4.24.
>> 
>> regards
>> 
>> --
>> Paul Starzetz
>> iSEC Security Research
>> http://isec.pl/
>> 
>> --[PinePGP]-----------------------------------------------------------
>> gpg: Signature made Tue 27 Jan 2004 02:28:19 PM GMT using DSA key ID 9E70A6EE
>> gpg: Can't check signature: public key not found
>> PinePGP: Encryption backend encountered error.
>> --[PinePGP]----------------------------------------------------[end]--
>> 
>_______________________________________________
>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 29 16:51:00 2004
>Return-Path: <vendor-sec-admin@lst.de>
>Received: from Hermes.suse.de (Hermes.suse.de [10.0.0.1])
>	by wotan.suse.de (Postfix) with ESMTP id 807D0154D2
>	for <okir@wotan.suse.de>; Thu, 29 Jan 2004 16:51:00 +0100 (CET)
>Received: by Hermes.suse.de (Postfix)
>	id 7B0F611F19; Thu, 29 Jan 2004 16:51:00 +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 7669111E1F
>	for <okir@suse.de>; Thu, 29 Jan 2004 16:51:00 +0100 (CET)
>Received: from mail.lst.de (verein.lst.de [212.34.189.10])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by Cantor.suse.de (Postfix) with ESMTP id B0CCECEC18
>	for <okir@suse.de>; Thu, 29 Jan 2004 16:46:10 +0100 (CET)
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0TFk9Qc032114
>	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
>	for <okir@suse.de>; Thu, 29 Jan 2004 16:46:10 +0100
>Received: (from cyrus@localhost)
>	by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i0TFk9cO032112
>	for okir@suse.de; Thu, 29 Jan 2004 16:46:09 +0100
>Received: from mail.lst.de ([unix socket])
>	by mail.lst.de (Cyrus v2.1.15-IPv6-Debian-2.1.15-0woody.1.0) with LMTP; Thu, 29 Jan 2004 16:46:09 +0100
>X-Sieve: CMU Sieve 2.2
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0TFk8Qb032108;
>	Thu, 29 Jan 2004 16:46:08 +0100
>Received: from luonnotar.infodrom.org (luonnotar.infodrom.org [195.124.48.78])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0TFjaQb032015
>	for <vendor-sec@lst.de>; Thu, 29 Jan 2004 16:45:36 +0100
>Received: by luonnotar.infodrom.org (Postfix, from userid 10)
>	id E2526366B8F; Thu, 29 Jan 2004 16:45:21 +0100 (CET)
>Received: at Infodrom Oldenburg (/\##/\ Smail-3.2.0.102 1998-Aug-2 #2)
>	from infodrom.org by finlandia.Infodrom.North.DE
>	via smail from stdin
>	id <m1AmEN6-000pCkC@finlandia.Infodrom.North.DE>
>	for security@isec.pl; Thu, 29 Jan 2004 16:46:24 +0100 (CET) 
>From: Martin Schulze <joey@infodrom.org>
>To: security@isec.pl, vendor-sec <vendor-sec@lst.de>
>Message-ID: <20040129154624.GA9951@finlandia.infodrom.north.de>
>References: <Pine.LNX.4.44.0401271522360.8787-100000@isec.pl> <Pine.LNX.4.58.0401271440160.17782@dell1.moose.awe.com>
>Mime-Version: 1.0
>Content-Type: text/plain; charset=iso-8859-1
>Content-Disposition: inline
>In-Reply-To: <Pine.LNX.4.58.0401271440160.17782@dell1.moose.awe.com>
>User-Agent: Mutt/1.5.4i
>X-Spam-Score: -4.901 () BAYES_00
>X-Scanned-By: MIMEDefang 2.39
>Subject: [vendor-sec] Re: mremap bug very serious
>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/>
>Date: Thu, 29 Jan 2004 16:46:24 +0100
>X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on wotan.suse.de
>X-Spam-Level: 
>X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
>	version=2.63
>Status: RO
>Content-Length: 757
>Lines: 20
>
>Mark J Cox wrote:
>> We always prefer Wednesdays for updates (because usually on Mondays
>> administrators are busy removing a weekends worth of spam from their
>> mailboxes), so whilst Feb11 would be better, Feb09 is okay.
>
>I'd still like to postpone this issue until Feb 16th.  That's only
>slightly more than two weeks from now and we're still discussing the
>quick fix.  Also, kernels still need to go through QA as well.
>
>> (reminder: CAN-2003-0077)
>                 ~~~~
>             CAN-2004-0077
>
>-- 
>The good thing about standards is that there are so many to choose from.
>		-- Andrew S. Tanenbaum
>_______________________________________________
>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 29 17:08:41 2004
>Return-Path: <vendor-sec-admin@lst.de>
>Received: from Hermes.suse.de (Hermes.suse.de [10.0.0.1])
>	by wotan.suse.de (Postfix) with ESMTP id CA3CE15547
>	for <okir@wotan.suse.de>; Thu, 29 Jan 2004 17:08:41 +0100 (CET)
>Received: by Hermes.suse.de (Postfix)
>	id C48B211E1F; Thu, 29 Jan 2004 17:08:41 +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 BFA5F88CE
>	for <okir@suse.de>; Thu, 29 Jan 2004 17:08:41 +0100 (CET)
>Received: from mail.lst.de (verein.lst.de [212.34.189.10])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by Cantor.suse.de (Postfix) with ESMTP id A2B1DD0068
>	for <okir@suse.de>; Thu, 29 Jan 2004 17:03:09 +0100 (CET)
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0TG39Qc032424
>	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
>	for <okir@suse.de>; Thu, 29 Jan 2004 17:03:09 +0100
>Received: (from cyrus@localhost)
>	by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i0TG39tA032422
>	for okir@suse.de; Thu, 29 Jan 2004 17:03:09 +0100
>Received: from mail.lst.de ([unix socket])
>	by mail.lst.de (Cyrus v2.1.15-IPv6-Debian-2.1.15-0woody.1.0) with LMTP; Thu, 29 Jan 2004 17:03:08 +0100
>X-Sieve: CMU Sieve 2.2
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0TG38Qb032419;
>	Thu, 29 Jan 2004 17:03:08 +0100
>Received: from intra.cyclades.com (intra.cyclades.com [64.186.161.6])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0TG2wQb032390
>	for <vendor-sec@lst.de>; Thu, 29 Jan 2004 17:02:58 +0100
>Received: from cm-net-poa-C8B025C6.brdterra.com.br (unknown [200.176.37.198])
>	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
>	(No client certificate requested)
>	by intra.cyclades.com (Postfix) with ESMTP
>	id 7AA5C8001C7; Thu, 29 Jan 2004 07:52:17 -0800 (PST)
>From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
>X-X-Sender: marcelo@logos.cnet
>To: Martin Schulze <joey@infodrom.org>
>Cc: security@isec.pl, vendor-sec <vendor-sec@lst.de>,
>	Paul Starzetz <ihaquer@isec.pl>
>Subject: Re: [vendor-sec] Re: mremap bug very serious
>In-Reply-To: <20040129154624.GA9951@finlandia.infodrom.north.de>
>Message-ID: <Pine.LNX.4.58L.0401291350510.5460@logos.cnet>
>References: <Pine.LNX.4.44.0401271522360.8787-100000@isec.pl>
> <Pine.LNX.4.58.0401271440160.17782@dell1.moose.awe.com>
> <20040129154624.GA9951@finlandia.infodrom.north.de>
>MIME-Version: 1.0
>Content-Type: TEXT/PLAIN; charset=US-ASCII
>X-Cyclades-MailScanner-Information: Please contact the ISP for more information
>X-Cyclades-MailScanner: Found to be clean
>X-Spam-Score: -4.901 () BAYES_00
>X-Scanned-By: MIMEDefang 2.39
>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/>
>Date: Thu, 29 Jan 2004 13:52:13 -0200 (BRST)
>X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on wotan.suse.de
>X-Spam-Level: 
>X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS 
>	autolearn=no version=2.63
>Content-Length: 749
>Lines: 22
>
>
>
>On Thu, 29 Jan 2004, Martin Schulze wrote:
>
>> Mark J Cox wrote:
>> > We always prefer Wednesdays for updates (because usually on Mondays
>> > administrators are busy removing a weekends worth of spam from their
>> > mailboxes), so whilst Feb11 would be better, Feb09 is okay.
>>
>> I'd still like to postpone this issue until Feb 16th.  That's only
>> slightly more than two weeks from now and we're still discussing the
>> quick fix.  Also, kernels still need to go through QA as well.
>
>Agreed. I want to get 2.4.25 out on the disclosure date and Feb 9th is too
>early.
>
>Please change to Feb 16th.
>
>_______________________________________________
>Vendor Security mailing list
>Vendor Security@lst.de
>https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec
>
>From vendor-sec-admin@lst.de  Tue Jan 27 15:50:09 2004
>Return-Path: <vendor-sec-admin@lst.de>
>Received: from Hermes.suse.de (Hermes.suse.de [10.0.0.1])
>	by wotan.suse.de (Postfix) with ESMTP id 9EF4EEC04
>	for <okir@wotan.suse.de>; Tue, 27 Jan 2004 15:50:09 +0100 (CET)
>Received: by Hermes.suse.de (Postfix)
>	id 9851511EC7; Tue, 27 Jan 2004 15:50:09 +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 9090211DAE
>	for <okir@suse.de>; Tue, 27 Jan 2004 15:50:09 +0100 (CET)
>Received: from mail.lst.de (verein.lst.de [212.34.189.10])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by Cantor.suse.de (Postfix) with ESMTP id 0CC38B5771
>	for <okir@suse.de>; Tue, 27 Jan 2004 15:50:08 +0100 (CET)
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0REo8Qc020689
>	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
>	for <okir@suse.de>; Tue, 27 Jan 2004 15:50:08 +0100
>Received: (from cyrus@localhost)
>	by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i0REo8C2020687
>	for okir@suse.de; Tue, 27 Jan 2004 15:50:08 +0100
>Received: from mail.lst.de ([unix socket])
>	by mail.lst.de (Cyrus v2.1.15-IPv6-Debian-2.1.15-0woody.1.0) with LMTP; Tue, 27 Jan 2004 15:50:08 +0100
>X-Sieve: CMU Sieve 2.2
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0REo7Qb020684;
>	Tue, 27 Jan 2004 15:50:07 +0100
>Received: from fed1mtao02.cox.net (fed1mtao02.cox.net [68.6.19.243])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0REnVQb020648
>	for <vendor-sec@lst.de>; Tue, 27 Jan 2004 15:49:32 +0100
>Received: from Bill-The-Cat ([68.107.142.198]) by fed1mtao02.cox.net
>          (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP
>          id <20040127144916.VREW27510.fed1mtao02.cox.net@Bill-The-Cat>;
>          Tue, 27 Jan 2004 09:49:16 -0500
>Received: from trini by Bill-The-Cat with local (Exim 3.36 #1 (Debian))
>	id 1AlUWc-0001uj-00; Tue, 27 Jan 2004 07:49:10 -0700
>From: Tom Rini <trini@mvista.com>
>To: security@isec.pl
>Cc: vendor-sec <vendor-sec@lst.de>
>Subject: Re: [vendor-sec] mremap bug very serious
>Message-ID: <20040127144910.GR3793@mvista.com>
>References: <Pine.LNX.4.44.0401271522360.8787-100000@isec.pl>
>Mime-Version: 1.0
>Content-Type: multipart/signed; micalg=pgp-sha1;
>	protocol="application/pgp-signature"; boundary="0IvGJv3f9h+YhkrH"
>Content-Disposition: inline
>In-Reply-To: <Pine.LNX.4.44.0401271522360.8787-100000@isec.pl>
>User-Agent: Mutt/1.5.5.1+cvs20040105i
>X-Spam-Score: -4.901 () BAYES_00
>X-Scanned-By: MIMEDefang 2.39
>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/>
>Date: Tue, 27 Jan 2004 07:49:10 -0700
>X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on 
>	wotan.suse.de
>X-Spam-Level: 
>X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
>	version=2.61
>Content-Length: 1246
>Lines: 44
>
>
>--0IvGJv3f9h+YhkrH
>Content-Type: text/plain; charset=us-ascii
>Content-Disposition: inline
>Content-Transfer-Encoding: quoted-printable
>
>On Tue, Jan 27, 2004 at 03:28:13PM +0100, Paul Starzetz wrote:
>
>> Hi,
>>=20
>> I would really like to fix the disclosure date for the mremap()=20
>> do_munmap bug. So can we agree on the 09-02-2004?
>>=20
>> The issue is much more serious that I originally thought. We were able to=
>=20
>> create a proof-of-concept giving uid=3D0 immediatelly (without hitting an=
>y=20
>> races etc). Tested on vanilla 2.4.24.
>
>Have we settled on a patch that fixes these issues?  I assume that it
>would be one that ignores/comments the first do_munmap() call and checks
>the return value of the last two..
>
>--=20
>Tom
>
>--0IvGJv3f9h+YhkrH
>Content-Type: application/pgp-signature; name="signature.asc"
>Content-Description: Digital signature
>Content-Disposition: inline
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.3 (GNU/Linux)
>
>iD8DBQFAFnpmdZngf2G4WwMRAnKsAJ9hKAi5hQQEW84Q6vgkS45+bu0mMgCcCF+E
>loW+LiPdGcZMXl61o7CmruY=
>=saVn
>-----END PGP SIGNATURE-----
>
>--0IvGJv3f9h+YhkrH--
>_______________________________________________
>Vendor Security mailing list
>Vendor Security@lst.de
>https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec
>
>From vendor-sec-admin@lst.de  Wed Jan 28 22:36:18 2004
>Return-Path: <vendor-sec-admin@lst.de>
>Received: from Hermes.suse.de (Hermes.suse.de [10.0.0.1])
>	by wotan.suse.de (Postfix) with ESMTP id 9326C1105C
>	for <okir@wotan.suse.de>; Wed, 28 Jan 2004 22:36:18 +0100 (CET)
>Received: by Hermes.suse.de (Postfix)
>	id 9024C1256D; Wed, 28 Jan 2004 22:36:18 +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 897FC123E8
>	for <okir@suse.de>; Wed, 28 Jan 2004 22:36:18 +0100 (CET)
>Received: from mail.lst.de (verein.lst.de [212.34.189.10])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by Cantor.suse.de (Postfix) with ESMTP id 692A8C5DF1
>	for <okir@suse.de>; Wed, 28 Jan 2004 22:36:18 +0100 (CET)
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0SLaHQc016513
>	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
>	for <okir@suse.de>; Wed, 28 Jan 2004 22:36:17 +0100
>Received: (from cyrus@localhost)
>	by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i0SLaHcq016511
>	for okir@suse.de; Wed, 28 Jan 2004 22:36:17 +0100
>Received: from mail.lst.de ([unix socket])
>	by mail.lst.de (Cyrus v2.1.15-IPv6-Debian-2.1.15-0woody.1.0) with LMTP; Wed, 28 Jan 2004 22:36:17 +0100
>X-Sieve: CMU Sieve 2.2
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0SLaGQb016507;
>	Wed, 28 Jan 2004 22:36:16 +0100
>Received: from mitzu.mi.org (mitzu.mi.org [198.22.64.42])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0SLZMQb016483
>	for <vendor-sec@lst.de>; Wed, 28 Jan 2004 22:35:22 +0100
>Received: from dojo.mi.org (mojo.mi.org [198.22.64.44])
>	by mitzu.mi.org (Postfix) with ESMTP id 8AEC84087
>	for <vendor-sec@lst.de>; Wed, 28 Jan 2004 16:35:05 -0500 (EST)
>Received: by dojo.mi.org
>	id 3148B648A9C; Wed, 28 Jan 2004 16:26:07 -0500 (EST)
>To: vendor-sec@lst.de (vendor-sec List)
>From: "Mike O'Connor" <mjo@dojo.mi.org>
>Reply-To: "Mike O'Connor" <mjo@dojo.mi.org>
>Message-Id: <040128162607.mjo@dojo.mi.org>
>X-Organization: :noitazinagrO-X
>X-Spam-Score: -4.901 () BAYES_00
>X-Scanned-By: MIMEDefang 2.39
>Subject: [vendor-sec] where are we with the latest mremap() vulnerability?
>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/>
>Date: Wed, 28 Jan 2004 16:26:07 -0500 (EST)
>X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on wotan.suse.de
>X-Spam-Level: 
>X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
>	version=2.63
>Status: RO
>Content-Length: 2804
>Lines: 69
>
>I'm a little confused about where we're going with this, and
>somewhat hammered by all this MyDoom business.  Is the intent to:
>
>a) patch Paul Starzetz known reported mremap() issues piecemeal
>b) reimplement mremap() altogether
>c) a + b
>d) none of the above
>
>If "a", then what are the patches going to be?  Do we have 
>any confidence that Paul Starzetz (or perhaps someone else)
>isn't just going to ring our bell in a month or two?  Are
>we going to be able to make some sort of February 11th date?
>
>If "b", are there any implementation ideas?  FWIW, SGI has 
>some clean vma handling code that we've had in place for a 
>couple years as part of our CPUset implementation.  If there
>was interest in reimplementing, we'd be happy to contribute.
>A description of what we do is underneath my sig.
>
>If "c", what's the target for this work?  Would it be 2.6
>only or backported to 2.4?
>
>If "d", then what are people doing?
>
>Just trying to get a sense of where we're at...
>
>-- 
> Mail: mjo@dojo.mi.org  WWW: http://dojo.mi.org/~mjo/  Phone: +1 248 427 4481
> =--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--=
>"From now on, I'll connect the dots my own way."                      -Calvin
>
>-----
>
>/*
> * If a vma straddles either end of the specified address
> * range (start, start+len), split it at the range boundary.
> * Return:
> *      zero    - Success
> *      -EINVAL - Start of range not page alligned or invalid range.
> *      -ENOMEM - This process already owns > MAX_MAP_COUNT vma's.
> *      -EAGAIN - A kernel resource was temporarily unavailable.
> *
> * Caller should be holding vma->mm->mmap_sem so that a parallel
> * vma_merge won't undo these split(s) before they are put to use,
> * and to otherwise protect these vma list operations.
> *
> * This single routine should replace the duplicated portions
> * of the several fixup_{start,end,middle} routines otherwise
> * needed by mlock, mprotect, madvise and CpuMemSet's
> * cms_set_cmm(CMS_VMAREA, ..).
> *
> * The caller of vma_split_range typically does three steps:
> * 1) First ensure that every vma in the process address space
> *    is either entirely within, or entirely outside, the desired
> *    range, by calling vma_split_range() to split any vma that
> *    that straddles either boundary of the range.
> * 2) Then for each vma in the range, apply the desired mlock,
> *    mprotect, madvise or cms policy, without the complications
> *    of vma boundary conditions.
> * 3) Then finally, if it has a chance, such as with mprotect,
> *    see if it can_vma_merge() at either end of the range.
> */
>
>int vma_split_range (struct mm_struct * mm, unsigned long start, size_t len);
>
>_______________________________________________
>Vendor Security mailing list
>Vendor Security@lst.de
>https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec
>
>From vendor-sec-admin@lst.de  Wed Jan 28 23:06:01 2004
>Return-Path: <vendor-sec-admin@lst.de>
>Received: from Hermes.suse.de (Hermes.suse.de [10.0.0.1])
>	by wotan.suse.de (Postfix) with ESMTP id C6404ACEC
>	for <okir@wotan.suse.de>; Wed, 28 Jan 2004 23:06:01 +0100 (CET)
>Received: by Hermes.suse.de (Postfix)
>	id C217E11EA9; Wed, 28 Jan 2004 23:06:01 +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 BD1A611E52
>	for <okir@suse.de>; Wed, 28 Jan 2004 23:06:01 +0100 (CET)
>Received: from mail.lst.de (verein.lst.de [212.34.189.10])
>	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
>	(No client certificate requested)
>	by Cantor.suse.de (Postfix) with ESMTP id ADF65C401C
>	for <okir@suse.de>; Wed, 28 Jan 2004 23:00:09 +0100 (CET)
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0SM08Qc016969
>	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
>	for <okir@suse.de>; Wed, 28 Jan 2004 23:00:08 +0100
>Received: (from cyrus@localhost)
>	by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i0SM08dQ016967
>	for okir@suse.de; Wed, 28 Jan 2004 23:00:08 +0100
>Received: from mail.lst.de ([unix socket])
>	by mail.lst.de (Cyrus v2.1.15-IPv6-Debian-2.1.15-0woody.1.0) with LMTP; Wed, 28 Jan 2004 23:00:08 +0100
>X-Sieve: CMU Sieve 2.2
>Received: from verein.lst.de (localhost [127.0.0.1])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0SM07Qb016963;
>	Wed, 28 Jan 2004 23:00:07 +0100
>Received: from fed1mtao05.cox.net (fed1mtao05.cox.net [68.6.19.126])
>	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0SLx9Qb016943
>	for <vendor-sec@lst.de>; Wed, 28 Jan 2004 22:59:10 +0100
>Received: from Bill-The-Cat ([68.107.142.198]) by fed1mtao05.cox.net
>          (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP
>          id <20040128215854.YLQO9536.fed1mtao05.cox.net@Bill-The-Cat>;
>          Wed, 28 Jan 2004 16:58:54 -0500
>Received: from trini by Bill-The-Cat with local (Exim 3.36 #1 (Debian))
>	id 1Alxi6-0001Js-00; Wed, 28 Jan 2004 14:58:58 -0700
>From: Tom Rini <trini@mvista.com>
>To: "Mike O'Connor" <mjo@dojo.mi.org>
>Cc: vendor-sec List <vendor-sec@lst.de>
>Subject: Re: [vendor-sec] where are we with the latest mremap() vulnerability?
>Message-ID: <20040128215858.GM3793@mvista.com>
>References: <040128162607.mjo@dojo.mi.org>
>Mime-Version: 1.0
>Content-Type: multipart/signed; micalg=pgp-sha1;
>	protocol="application/pgp-signature"; boundary="mrJd9p1Ce66CJMxE"
>Content-Disposition: inline
>In-Reply-To: <040128162607.mjo@dojo.mi.org>
>User-Agent: Mutt/1.5.5.1+cvs20040105i
>X-Spam-Score: -4.901 () BAYES_00
>X-Scanned-By: MIMEDefang 2.39
>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/>
>Date: Wed, 28 Jan 2004 14:58:58 -0700
>X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on wotan.suse.de
>X-Spam-Level: 
>X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS 
>	autolearn=no version=2.63
>Status: RO
>Content-Length: 2088
>Lines: 61
>
>
>--mrJd9p1Ce66CJMxE
>Content-Type: text/plain; charset=us-ascii
>Content-Disposition: inline
>Content-Transfer-Encoding: quoted-printable
>
>On Wed, Jan 28, 2004 at 04:26:07PM -0500, Mike O'Connor wrote:
>
>> I'm a little confused about where we're going with this, and
>> somewhat hammered by all this MyDoom business.  Is the intent to:
>>=20
>> a) patch Paul Starzetz known reported mremap() issues piecemeal
>> b) reimplement mremap() altogether
>> c) a + b
>> d) none of the above
>>=20
>> If "a", then what are the patches going to be?  Do we have=20
>> any confidence that Paul Starzetz (or perhaps someone else)
>> isn't just going to ring our bell in a month or two?  Are
>> we going to be able to make some sort of February 11th date?
>
>Since no one has really proposed anything better, right now I've yanked
>out the fixes from Owl, which Paul has said isn't vulnerable to this
>particular issue.  I've posted what I believe are all of the bits to the
>list twice now, so it's in the archives.
>
>> If "b", are there any implementation ideas?  FWIW, SGI has=20
>> some clean vma handling code that we've had in place for a=20
>> couple years as part of our CPUset implementation.  If there
>> was interest in reimplementing, we'd be happy to contribute.
>> A description of what we do is underneath my sig.
>>=20
>> If "c", what's the target for this work?  Would it be 2.6
>> only or backported to 2.4?
>>=20
>> If "d", then what are people doing?
>
>Perhaps someone else could audit mremap (and maybe munmap/mmap?) for
>unchecked return values and that parameters are sanity checked?
>
>--=20
>Tom
>
>--mrJd9p1Ce66CJMxE
>Content-Type: application/pgp-signature; name="signature.asc"
>Content-Description: Digital signature
>Content-Disposition: inline
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.3 (GNU/Linux)
>
>iD8DBQFAGDCidZngf2G4WwMRAqy1AKCQQco+8jPd0ux2IMe1AG/yF1n3YwCggXrG
>gWWNFfb6D6zw5sTHe0dUqLM=
>=uebQ
>-----END PGP SIGNATURE-----
>
>--mrJd9p1Ce66CJMxE--
>_______________________________________________
>Vendor Security mailing list
>Vendor Security@lst.de
>https://www.lst.de/cgi-bin/mailman/listinfo/vendor-sec
>

Actions: View

Attachments on bug 49117: 15737 | 15808 | 16076