> trevor's password:
> Last login: Tue Jan 27 07:43:43 1998
> ~ logout
> general protection: 0000
> CPU: 0
> EIP: 0010:[<c0109954>]
> EFLAGS: 00010282
> eax: 00000001 ebx: 0000000a ecx: bffff7c0 edx: bffff740
> esi: 00000000 edi: bffff6c0 ebp: bffff6c8 esp: c0a99fec
> ds: 002b es: 002b ss: 0018
> Process sshd (pid: 840, process nr: 30, stackpage=c0a99000)
> Call Trace:
> Code: cf 8d 76 00 f7 44 24 30 00 00 02 00 54 75 19 6a 00 e8 56 fc
^^
iret opcode, recently there have been a few oopses on iret's to user mode
> Stack: 400c485e 00000023 00000286 bffff690 00000000
%eip %cs %eflags %esp %ss
(ok) (ok) (ok) (ok) (bad)
something has corrupted the kernel stack during a system call. An strace
would be a great help in this case. I've already tracked one down which
happened because a signal handler would corrupt its register area, but
that one seems impossible (the sys_sigreturn code checks that the
stack segment selector is more or less valid and it definitely disallows
null selectors).
Last wild idea: the stack selector is the last word of the stack, after
this starts another page. If the code that has the page allocated writes
just below its limit, it might give this type of errors, but this
would be highly unreproducible IMHO.
Gabriel.