As a _normal user_ under the aforementioned kernels, an oops can be caused
by merely attempting to execute the wrong type of file. Define "wrong" as
a vmlinux image produced by making a kernel. For the following trace, a
vmlinux corresponding to my friend's 2.1.41 image was used. Perhaps a
2.0.30 vmlinux would have the same effect....
The repeatability of this OOPS suggests to me a suitable binary image
could perhaps be engineered, to lock the machine or even perform security
violations... from an _unprivileged_ _user_, on the flagship of Linux
kernels.
May 29 14:54:45 ferret kernel: general protection: 0000
May 29 14:54:45 ferret kernel: CPU: 0
May 29 14:54:45 ferret kernel: EIP: 0010:[ret_from_sys_call+133/136]
May 29 14:54:45 ferret kernel: EFLAGS: 00010202
May 29 14:54:45 ferret kernel: eax: 00000000 ebx: 0809e440 ecx: 0809e470 edx: 00000000
May 29 14:54:45 ferret kernel: esi: 0809e470 edi: bffffd3e ebp: bffffc2c esp: 02abafec
May 29 14:54:45 ferret kernel: ds: 002b es: 002b fs: 002b gs: 002b ss: 0018
May 29 14:54:45 ferret kernel: Process vmlinux (pid: 21048, process nr: 52, stackpage=02aba000)
May 29 14:54:45 ferret kernel: Stack: c0100000 00000023 00000296 bffffe30 0000002b
May 29 14:54:45 ferret kernel: Call Trace:
May 29 14:54:45 ferret kernel: Code: cf 8d 36 89 e1 51 f7 41 38 00 00 02 00 75 2c 53 e8 fa fb ff
May 29 14:55:01 ferret kernel: sys_connect; (e)uid = 0(0), address = 129.67.1.1, port = 53
May 29 14:55:01 ferret last message repeated 2 times
Methinks this should be fixed.... patches cc: to this address please,
since we're about to reboot after a memory upgrade....
Chris