lkml.org 
[lkml]   [1998]   [Jun]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: crashme & 2.1.104pre1: oops in restore_sigcontext


On Tue, 2 Jun 1998, Meelis Roos wrote:

> Having run crashme 2.4 for about 4 days, I looked at kernel logs
> and found 5 oopses (about one a day). Machine is still running.
>
> So the running of crashme on 2.1.x was not absolutely useless
> at least :) At the moment I'm at 31057.
>
> All of them are mostly the same:
>
> general protection: 0004 (also 15e8, 000c, 0008)
> CPU: 0
> EIP: 0010:[<c0108c5e>]
> EFLAGS: 00010202 (also 00050246)
> eax: 00000000 ebx: bffff658 ecx: 00000005 edx: 00000005
> (this line varies)
>
> esi: 00000000 edi: c11e3fc4 ebp: c11e3fc4 esp: c11e3f84
> ds: 0018 es: 0018 ss: 0018
> Process crashme (pid: 13210, process nr: 70, stackpage=c11e3000)
> Stack: bffff650 00000000 c11e3fc4 c11e2000 00000005 c0108f07 c11e3fc4 bffff658
> c11e2000 00000007 0804b2a9 bffff650 c11e3fc4 bffbf6d4 bffffa8c c0109824
> 0804f360 080490dd 0804b2a9 00000007 0804b2a9 bffff650 00000077 0000002b
> Call Trace: [<c0108f07>] [<c0109824>]
> Code: 8e e9 31 c0 66 8b 53 04 81 e2 ff ff 00 00 89 54 24 10 66 f7
>
> Using `/boot/System.map' to map addresses to symbols.
>
> >>EIP: c0108c5e <restore_sigcontext+3e/228>
> Trace: c0108f07 <sys_sigreturn+bf/d4>
> Trace: c0109824 <system_call+38/3c>
> Code: c0108c5e <restore_sigcontext+3e/228>
> Code: c0108c5e <restore_sigcontext+3e/228> 8e e9 movw %cx,%gs
> Code: c0108c60 <restore_sigcontext+40/228> 31 c0 xorl %eax,%eax
> Code: c0108c62 <restore_sigcontext+42/228> 66 8b 53 04 movw 0x4(%ebx),%dx
> Code: c0108c66 <restore_sigcontext+46/228> 81 e2 ff ff 00 andl $0xffff,%edx
> Code: c0108c72 <restore_sigcontext+52/228> 89 54 24 10 movl %edx,0x10(%esp,1)
> Code: c0108c76 <restore_sigcontext+56/228> 66 f7 00 90 90 testw $0x9090,(%eax)
> Code: c0108c81 <restore_sigcontext+61/228> 90 nop
>
> ksymoops output is always the same, oops number, flags, eax,ebx,ecx,edx
> vary.
>
> Seems to be in restore_sigcontext. I looked at the code, this seems to be
> the GET_SEG(gs); statement:
>
> restore_sigcontext(struct pt_regs *regs, struct sigcontext *sc)
> {
> unsigned int tmp;
>
> // some macros skipped
>
> #define GET_SEG(seg) \
> { __get_user(tmp, &sc->seg); \
> if ((tmp & 0xfffc) /* not a NULL selectors */ \
> && (tmp & 0x4) != 0x4 /* not a LDT selector */ \
> && (tmp & 3) != 3) /* not a RPL3 GDT selector */ \
> goto badframe; \
> __asm__ __volatile__("movl %w0,%%" #seg : : "r"(tmp)); }
>
> GET_SEG(gs);
>
> (end of excerpt)
>
> Any ideas?
>

Yeah, the code only checks that the segment might be put into gs (or any
other segment register) in a crude way. But if you don't have an LDT or
try to load an invalid or empty ldt and/or gdt entry, you will get this
oops. But it can only be used to fill your logs and does not open any
security hole AFAICT...

It means that crashme tries to see what happens when thrashing the CPU
context in a signal handler and that Linux should handle some of these
extreme situations more elegantly...

Regards,
Gabriel.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:42    [W:0.037 / U:3.660 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site