Re: NULL pointer dereference in 2.0.27

Ion Badulescu (ionut@moisil.wal.rhno.columbia.edu)
Sun, 16 Feb 1997 18:52:49 -0500 (EST)


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.