On Wed, Nov 29, 2006 at 12:18:18AM -0800, Zhao Forrest wrote:
> On 11/28/06, Andi Kleen <ak@suse.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