2004-11-02 06:21:01

by Paweł Sikora

[permalink] [raw]
Subject: [oops] lib/vsprintf.c

Unable to handle kernel paging request at virtual address 66666666
printing eip:
c01b6f3e
*pde = 00131313
*pte = 0c55b70f
Oops: 0000 [#1]
Modules linked in: oops videodev agpgart nvidia ipt_unclean ipt_state
ipt_REJECT iptable_nat ip_conntrack iptable_mangle iptable_filter
ip_tables vmmon snd_seq_oss snd_seq_midi_event snd_seq snd_pcm_oss
snd_mixer_oss snd_ens1371 snd_rawmidi snd_seq_device snd_ac97_codec
snd_pcm snd_page_alloc gameport snd_rtctimer snd_timer snd soundcore
usbhid uhci_hcd usbcore via_rhine mii crc32 capability commoncap
processor via686a w83781d i2c_sensor i2c_isa i2c_core msr cpuid
ide_disk ext3 mbcache jbd via82cxxx ide_core
CPU: 0
EIP: 0060:[<c01b6f3e>] Tainted: P VLI
EFLAGS: 00010097 (2.6.10)
EIP is at vsnprintf+0x30e/0x4f0
eax: 66666666 ebx: 0000000a ecx: 66666666 edx: fffffffe
esi: c03bfde3 edi: 00000000 ebp: c46d3f38 esp: c46d3efc
ds: 007b es: 007b ss: 0068
Process insmod (pid: 26344, threadinfo=c46d2000 task=c33f2140)
Stack: c46d3f0c c014fa0a c4245da0 00000001 c46d3f9c c0134526 d0a51000 0000000f
ffffffff ffffffff ffffffff c03c01df 00000400 00000246 c02d9660 c46d3f54
c01b7147 c03bfde0 00000400 d0a53038 c46d3f98 c03bfde0 c46d3f78 c011dda2
Call Trace:
[<c0106d0f>] show_stack+0x7f/0xa0
[<c0106ea6>] show_registers+0x156/0x1d0
[<c01070a8>] die+0xc8/0x150
[<c0118410>] do_page_fault+0x440/0x707
[<c01069a1>] error_code+0x2d/0x38
[<c01b7147>] vscnprintf+0x27/0x40
[<c011dda2>] vprintk+0x42/0x140
[<c011dd58>] printk+0x18/0x20
[<d0a5301c>] km_init_module+0x1c/0x20 [oops]
[<c0134724>] sys_init_module+0x134/0x1c0
[<c0105ecd>] sysenter_past_esp+0x52/0x71
Code: fd ff ff 83 cf 40 bb 10 00 00 00 eb 88 8b 45 14 8b
55 e8 83 45 14 04 8b 08 b8 6c 45 2b c0 81 f9 ff 0f 00 00
0f 46 c8 89 c8 eb 06 <80> 38 00 74 07 40 4a 83 fa ff 75
f4 29 c8 83 e7 10 89 c3 0f 85


Attachments:
(No filename) (409.00 B)
oops-dump.txt (1.81 kB)
oops.c (368.00 B)
Download all attachments

2004-11-02 06:27:38

by Nick Piggin

[permalink] [raw]
Subject: Re: [oops] lib/vsprintf.c

Paweł Sikora wrote:
> Hi,
>
> vsprintf.c- case 's':
> vsprintf.c- s = va_arg(args, char *);
> vsprintf.c- if ((unsigned long)s < PAGE_SIZE)
> vsprintf.c- s = "<NULL>";
> vsprintf.c-
> vsprintf.c: OOPS! => len = strnlen(s, precision);
>

But it is the kernel module that's buggy. What's the problem?

2004-11-02 07:03:15

by Jan Engelhardt

[permalink] [raw]
Subject: Re: [oops] lib/vsprintf.c

>Hi,


>static int km_init_module(void)
>{
> printk(KERN_DEBUG "%s init\n", 1.4);
> return 0;
>}

You do know that %s does not mix with 1.4?


>vsprintf.c- case 's':
>vsprintf.c- s = va_arg(args, char *);
>vsprintf.c- if ((unsigned long)s < PAGE_SIZE)
>vsprintf.c- s = "<NULL>";
>vsprintf.c-
>vsprintf.c: OOPS! => len = strnlen(s, precision);




Jan Engelhardt
--
Gesellschaft für Wissenschaftliche Datenverarbeitung
Am Fassberg, 37077 Göttingen, http://www.gwdg.de

2004-11-02 07:36:12

by Paweł Sikora

[permalink] [raw]
Subject: Re: [oops] lib/vsprintf.c


On Tue, 2 Nov 2004, Nick Piggin wrote:

> Pawe Sikora wrote:
>> Hi,
>>
>> vsprintf.c- case 's':
>> vsprintf.c- s = va_arg(args, char *);
>> vsprintf.c- if ((unsigned long)s < PAGE_SIZE)
>> vsprintf.c- s = "<NULL>";
>> vsprintf.c-
>> vsprintf.c: OOPS! => len = strnlen(s, precision);
>>
>
> But it is the kernel module that's buggy. What's the problem?
>
>

I think that block similar to setjmp/longjmp should be placed
around such dangerous places to refues future oops.
That's all.

2004-11-02 09:08:57

by Bernd Petrovitsch

[permalink] [raw]
Subject: Re: [oops] lib/vsprintf.c

On Tue, 2004-11-02 at 08:35 +0100, Pawel Sikora wrote:
> On Tue, 2 Nov 2004, Nick Piggin wrote:
> > Pawe Sikora wrote:
> >> vsprintf.c- case 's':
> >> vsprintf.c- s = va_arg(args, char *);
> >> vsprintf.c- if ((unsigned long)s < PAGE_SIZE)
> >> vsprintf.c- s = "<NULL>";
> >> vsprintf.c-
> >> vsprintf.c: OOPS! => len = strnlen(s, precision);
> >
> > But it is the kernel module that's buggy. What's the problem?
>
> I think that block similar to setjmp/longjmp should be placed
> around such dangerous places to refues future oops.

How do you want to find such bugs then?

Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services

2004-11-02 18:34:51

by Paweł Sikora

[permalink] [raw]
Subject: Re: [oops] lib/vsprintf.c

On Tuesday 02 of November 2004 08:03, you wrote:
> >Hi,
> >
> >
> >static int km_init_module(void)
> >{
> > printk(KERN_DEBUG "%s init\n", 1.4);
> > return 0;
> >}
>
> You do know that %s does not mix with 1.4?

Yes, I known. I did it intentionally.
IMHO kernel should be more resistant to accidental programmers errors.
Be secure, trust no one ;)
... and catch bugs with http://netlab.ru.is/exception/KernelExceptions.pdf

--
/* Copyright (C) 2003, SCO, Inc. This is valuable Intellectual Property. */

#define say(x) lie(x)

2004-11-02 18:38:47

by Jan Engelhardt

[permalink] [raw]
Subject: Re: [oops] lib/vsprintf.c

>> You do know that %s does not mix with 1.4?
>
>Yes, I known. I did it intentionally.
>IMHO kernel should be more resistant to accidental programmers errors.
>Be secure, trust no one ;)

Well usually it should be. include/linux/kernel.h has the __attribute__(printf)
stuff for the print[fk]* family.


Jan Engelhardt
--
Gesellschaft für Wissenschaftliche Datenverarbeitung
Am Fassberg, 37077 Göttingen, http://www.gwdg.de

2004-11-02 18:46:27

by Bernd Petrovitsch

[permalink] [raw]
Subject: Re: [oops] lib/vsprintf.c

On Tue, 2004-11-02 at 19:34 +0100, Pawe? Sikora wrote:
> On Tuesday 02 of November 2004 08:03, you wrote:
> > >static int km_init_module(void)
> > >{
> > > printk(KERN_DEBUG "%s init\n", 1.4);
> > > return 0;
> > >}
> >
> > You do know that %s does not mix with 1.4?
>
> Yes, I known. I did it intentionally.

"Doctor, it hurts when I do that."
"Then do not do it."

> IMHO kernel should be more resistant to accidental programmers errors.

What for? Simply fix them immediately.

> Be secure, trust no one ;)

ACK. Therefore the kernel oopses, rendering the machine useless for the
moment and forces the programmer to look for the bug.

> ... and catch bugs with http://netlab.ru.is/exception/KernelExceptions.pdf

What should happen afterwards?
Write a line to syslog which is probably ignored anyway?

Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services

2004-11-02 19:00:46

by Jan Engelhardt

[permalink] [raw]
Subject: Re: [oops] lib/vsprintf.c

>> Yes, I known. I did it intentionally.
>> IMHO kernel should be more resistant to accidental programmers errors.
>> Be secure, trust no one ;)
>
>ACK. Therefore the kernel oopses, rendering the machine useless for the
>moment and forces the programmer to look for the bug.

And thanks to the "stupidity" of the >> poster, the Debian Group found out that
their box was h4x0r3d when the machine oopsed repeatedly. :-)



Jan Engelhardt
--
Gesellschaft für Wissenschaftliche Datenverarbeitung
Am Fassberg, 37077 Göttingen, http://www.gwdg.de

2004-11-02 19:17:10

by Randy.Dunlap

[permalink] [raw]
Subject: Re: [oops] lib/vsprintf.c

Jan Engelhardt wrote:
>>>You do know that %s does not mix with 1.4?
>>
>>Yes, I known. I did it intentionally.

And you intentionally ignored the gcc warning...
it's all yours.
I.e., a normal user couldn't load the kernel module.

>>IMHO kernel should be more resistant to accidental programmers errors.
>>Be secure, trust no one ;)
>
>
> Well usually it should be. include/linux/kernel.h has the __attribute__(printf)
> stuff for the print[fk]* family.


--
~Randy