linux-kernel - Re: A commit between 2.6.16.4 and 2.6.16.5 failed crashme

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20061129083310.GC11084@stusta.de>
Date:	Wed, 29 Nov 2006 09:33:10 +0100
From:	Adrian Bunk <bunk@...sta.de>
To:	Zhao Forrest <forrest.zhao@...il.com>
Cc:	Andi Kleen <ak@...e.de>, discuss@...-64.org,
	linux-kernel@...r.kernel.org
Subject: Re: A commit between 2.6.16.4 and 2.6.16.5 failed crashme

On Wed, Nov 29, 2006 at 12:18:18AM -0800, Zhao Forrest wrote:
> On 11/28/06, Andi Kleen <ak@...e.de> wrote:
> >
> >> I first need to contact the author of test case if we could send the
> >> test case to open source. The test case is called "crashme",
> >
> >Is that the classical crashme as found in LTP or an enhanced one?
> >Do you run it in a special way? Is the crash reproducible?
> >
> >We normally run crashme regularly as part of LTP, Cerberus etc.
> >so at least any obvious bugs should in theory be caught.
> >
> 
> Let me change the subject of this thread.
> I just read our private version of crashme. It's based on crashme
> version 2.4 and add some logging capability, no other enhancement. So
> it should be the same as crashme in LTP.
> 
> It is solidly reproducible within 3 minutes of running crashme.
> 
> The current status is: we know it's a commit between 2.6.16.4 and
> 2.6.16.5 that introduce this bug.
> 
> Our network is very slow(only 5-6K/second). So we'll start the
> git-bisect tomorrow after finishing downloading the 2.6.16 stable git
> tree.

Thanks for your report.

A git-bisect might be a bit of overkill considering that there were only 
two patches applied beween 2.6.16.4 and 2.6.16.5:

Andi Kleen (2):
      x86_64: Clean up execve
      x86_64: When user could have changed RIP always force IRET (CVE-2006-0744)

I've attached both patches.

Could you manually bisect first applying "x86_64: Clean up execve" 
(patch-2.6.16.4-5-1) against 2.6.16.4?

Then we'll know which of Andi's pacthes caused this bug.

> Thanks,
> Forrest

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


View attachment "patch-2.6.16.4-5-1" of type "text/plain" (1068 bytes)

View attachment "patch-2.6.16.4-5-2" of type "text/plain" (2035 bytes)