Messages in this thread | | | Date | Sun, 16 Feb 1997 18:52:49 -0500 (EST) | From | Ion Badulescu <> | Subject | Re: NULL pointer dereference in 2.0.27 |
| |
On Sun, 16 Feb 1997, Jon Lewis wrote:
> Code: 00 00 00 44 24 20 03 44 24 24 89 c2 03 54 24 2c 8b 5c 24 40 > > Using `/kernels/System.map-2.0.27' to map addresses to symbols. > > >>EIP: 1333cd <load_aout_binary+4d/680> > Trace: 12bb7f <search_binary_handler+3f/160> > Trace: 12bde5 <do_execve+145/1c0> > Trace: 12be0a <do_execve+16a/1c0> > Trace: 109f42 <sys_execve+32/60> > Trace: 10a845 <system_call+55/80> > > Code: 1333cd <load_aout_binary+4d/680> addb %al,(%eax) > Code: 1333cf <load_aout_binary+4f/680> addb %al,0x20(%esp,1) > Code: 1333d3 <load_aout_binary+53/680> addl 0x24(%esp,1),%eax
Weird.. the actual code is supposed to be something like
00000578 <load_aout_binary+58> 83 7c 24 38 00 cmpl $0x0,0x38(%esp,1) >>EIP 0000057d <load_aout_binary+5d> 75 4b jne 000005ca <load_aout_binary+aa> 0000057f <load_aout_binary+5f> 8b 44 24 20 movl 0x20(%esp,1),%eax 00000583 <load_aout_binary+63> 03 44 24 24 addl 0x24(%esp,1),%eax
but in your case the first three bytes somehow got changed to 00. Notice that the byte just before EIP is already 0 and is also 32bit aligned (1333cc in your case), so my wild guess is that either your hardware wrote a 32-bit 0 to that address, or some other code in the kernel did it (less likely, but possible, I remember vaguely that the kernel text segment is writable).
Ionut
-- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt.
| |