[oops] lib/vsprintf.c

[oops] lib/vsprintf.c

[Paweł Sikora]

[-- Attachment #1: Type: text/plain, Size: 409 bytes --]

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);

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

                           #define say(x) lie(x)

[-- Attachment #2: oops-dump.txt --]
[-- Type: text/plain, Size: 1852 bytes --]

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

[-- Attachment #3: oops.c --]
[-- Type: text/x-csrc, Size: 368 bytes --]

#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/module.h>

MODULE_DESCRIPTION("buggy kernel module");
MODULE_LICENSE("GPL");

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

static void km_exit_module(void)
{
    printk(KERN_DEBUG "km exit\n");
}

module_init(km_init_module);
module_exit(km_exit_module);

Re: [oops] lib/vsprintf.c

[Nick Piggin]

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?

Re: [oops] lib/vsprintf.c

[Pawel Sikora]

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.

Re: [oops] lib/vsprintf.c

[Bernd Petrovitsch]

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

Re: [oops] lib/vsprintf.c

[Jan Engelhardt]

>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, www.gwdg.de

Re: [oops] lib/vsprintf.c

[Paweł Sikora]

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)

Re: [oops] lib/vsprintf.c

[Jan Engelhardt]

>> 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, www.gwdg.de

Re: [oops] lib/vsprintf.c

[Randy.Dunlap]

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

Re: [oops] lib/vsprintf.c

[Bernd Petrovitsch]

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

Re: [oops] lib/vsprintf.c

[Jan Engelhardt]

>> 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, www.gwdg.de