BUG in read_chan (read from console)?

Carsten Gross (carsten@sol.wohnheim.uni-ulm.de)
Wed, 26 Feb 1997 19:08:14 +0100 (MET)


Hello everone!

I think I've found a bug in the latest Kernel 2.1.26. I'm using a SMP Kernel
on a SMP Intel machine and tried out some small programs. The following few
lines crashed the system completly... (from a normal user account - started
with strace ./a.out)

int main() {

if (read(0, NULL, 4096)< 0)
perror("read");
exit(0);
}

I expected the program to print "read: Bad address". But instead the cursor
was waiting for input (read from stdin) and after typing some characters
followed by return the following appeared on the screen:

Unable to handle kernel NULL pointer dereference at virtual address
00000000
current->tss.cr3 = 018b3000, Pr3 = 018b3000
*pde = 00000000
Oops: 0002
CPU: 0
EIP: 0010:[<c0198238>]
EFLAGS: 00010213
eax: c1f37018 ebx: 00000061 ecx: 00000000 edx: 00000000
esi: 00000001 edi: 00000000 ebp: c1f72000 esp: c1720f40
ds: 0018 es: 0018 ss: 0018
Process a.out (pid: 447, process nr: 22, stackpage=c1720000)
Stack: c1f72000 c19a3540 c1bc02e8 00001000 00000000 c0123d26 00000030
00000000
00000000 00000000 00000001 c1f37018 c1f72938 c0194735 c1f72000
c19a3540
00000000 00001000 c19a3540 ffffffea 00001000 c1bc02e8 c012ea1f
c1bc02e8
Call Trace: [<c0123d26>] [<c0194735>] [<c012ea1f>] [<c010ae18>]
Code: 88 1f 8b 44 24 44 48 89 44 24 44 0f 85 73 ff ff ff e9 bc 01

This translates to (with ksymoops):
Using /System.map' to map addresses to symbols.

>>EIP: c0198238 <read_chan+548/870>
Trace: c0123d26 <do_no_page+10e/340>
Trace: c0194735 <tty_read+9d/bc>
Trace: c012ea1f <sys_read+df/140>
Trace: c010ae18 <tracesys+18/26>

Code: c0198238 <read_chan+548/870> movb %bl,(%edi)
Code: c019823a <read_chan+54a/870> movl 0x44(%esp,1),%eax
Code: c019823e <read_chan+54e/870> decl %eax
Code: c019823f <read_chan+54f/870> movl %eax,0x44(%esp,1)
Code: c0198243 <read_chan+553/870> jne ffffff84 <_EIP+ffffff84>
Code: c0198249 <read_chan+559/870> jmp 900001d2 <_EIP+900001d2>
Code: c019824e <read_chan+55e/870> nop

I looked at "read_chan" (this is in the file drivers/char/n_tty.c) and there
is no check that the pointer "unsigned char *buf" is not NULL or a
"verify_area" call... perhaps this is the problem?

Carsten

-- 
Carsten Gross		Internet: carsten@sol.wohnheim.uni-ulm.de
Wohnheim Heilmeyersteige:  Sebastian Kneipp Weg 6, 89075 Ulm