On 11/28/06, Andi Kleen <[email protected]> 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,
Forrest
On Wed, Nov 29, 2006 at 12:18:18AM -0800, Zhao Forrest wrote:
> On 11/28/06, Andi Kleen <[email protected]> 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
On 11/29/06, Adrian Bunk <[email protected]> wrote:
> On Wed, Nov 29, 2006 at 12:18:18AM -0800, Zhao Forrest wrote:
> > On 11/28/06, Andi Kleen <[email protected]> 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?
>
Hi Adrian
It's the second patch(x86_64: When user could have changed RIP always
force IRET (CVE-2006-0744)) that trigger this bug.
We have run crashme on a IBM server with 2 Intel dual-core CPU, a SUN
server with 2 AMD Opteron single-core CPU and a SUN server with 8 AMD
Opteron dual-core CPU.
Running crashme can trigger kernel panic on all platforms after the
second patch is applied to 2.6.16.4. And when kernel panic happens,
there's only "Kernel panic - not syncing: Attempted to kill init" on
the screen.
Please let me know if you need any further information.
Thanks,
Forrest
>
> 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.
>
Hi Andi,
I found that this patch is also in 2.6.18.3, but crashme doesn't
trigger kernel panic for 2.6.18.3......weird.
Thanks,
Forrest