local DDOS? Kernel panic when accessing /proc/ioports

local DDOS? Kernel panic when accessing /proc/ioports

[Martin Loschwitz]

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

Hi folks,

I just ran into the following problem: Having updated my box to 2.6.12.3, 
I tried to start YaST2 and noticed a kernel panic (see below). Some quick
debugging brought the result that the kernel crashes while some user (not
even root ...) tries to access /proc/ioports. Is this a known problem and
if so, is a fix available?

Ooops and ksymoops-output is attached.

=============
Oops
=============

Unable to handle kernel paging request at virtual address e081e6a8
 printing eip:
c01d16b2
*pde = 1ff5b067
*pte = 00000000
Oops: 0000 [#1]
Modules linked in: snd_mixer_oss snd radeon drm dm_mod autofs4 af_packet ext3 jbd i810_audio ac97_codec soundcore b44 mii intel_agp agpgart i2c_i801 i2c_core ipw2200 firmware_class ieee80211 ieee80211_crypt parport_pc parport 8250 serial_core usbhid ohci_hcd uhci_hcd pcmcia yenta_socket rsrc_nonstatic pcmcia_core video thermal processor fan container button battery ac genrtc unionfs loop sbp2 ohci1394 ieee1394 usb_storage ub ehci_hcd usbcore
CPU:    0
EIP:    0060:[<c01d16b2>]    Not tainted VLI
EFLAGS: 00210297   (2.6.12.3) 
EIP is at vsnprintf+0x332/0x4d0
eax: e081e6a8   ebx: 0000000a   ecx: e081e6a8   edx: fffffffe
esi: c71760e9   edi: 00000000   ebp: c7176fff   esp: c457deb4
ds: 007b   es: 007b   ss: 0068
Process cat (pid: 3275, threadinfo=c457c000 task=c5052020)
Stack: c71760e2 c7176fff 00000323 00000000 00000010 00000004 00000002 00000001 
       ffffffff ffffffff c4f7d640 c031f3ad c4f7d640 000000dd c01789c7 c71760dd 
       00000f23 c03265ef c457df2c c03265dd c011e934 c4f7d640 c03265dd 00000000 
Call Trace:
 [<c01789c7>] seq_printf+0x37/0x60
 [<c011e934>] r_show+0x84/0x90
 [<c01784c6>] seq_read+0x1d6/0x2d0
 [<c0158b85>] vfs_read+0xe5/0x160
 [<c0158ea1>] sys_read+0x51/0x80
 [<c0102f79>] syscall_call+0x7/0xb
Code: 00 83 cf 01 89 44 24 24 eb bb 8b 44 24 48 8b 54 24 20 83 44 24 48 04 8b 08 b8 ec 2b 33 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 75 20 

=============
Ksymoops
=============

>>EIP; c01d16b2 <vsnprintf+332/4d0>   <=====

>>eax; e081e6a8 <pg0+203236a8/3fb03400>
>>ecx; e081e6a8 <pg0+203236a8/3fb03400>
>>edx; fffffffe <__kernel_rt_sigreturn+1bbe/????>
>>esi; c71760e9 <pg0+6c7b0e9/3fb03400>
>>ebp; c7176fff <pg0+6c7bfff/3fb03400>
>>esp; c457deb4 <pg0+4082eb4/3fb03400>

Trace; c01789c7 <seq_printf+37/60>
Trace; c011e934 <r_show+84/90>
Trace; c01784c6 <seq_read+1d6/2d0>
Trace; c0158b85 <vfs_read+e5/160>
Trace; c0158ea1 <sys_read+51/80>
Trace; c0102f79 <syscall_call+7/b>

This architecture has variable length instructions, decoding before eip
is unreliable, take these instructions with a pinch of salt.

Code;  c01d1687 <vsnprintf+307/4d0>
00000000 <_EIP>:
Code;  c01d1687 <vsnprintf+307/4d0>
   0:   00 83 cf 01 89 44         add    %al,0x448901cf(%ebx)
Code;  c01d168d <vsnprintf+30d/4d0>
   6:   24 24                     and    $0x24,%al
Code;  c01d168f <vsnprintf+30f/4d0>
   8:   eb bb                     jmp    ffffffc5 <_EIP+0xffffffc5>
Code;  c01d1691 <vsnprintf+311/4d0>
   a:   8b 44 24 48               mov    0x48(%esp),%eax
Code;  c01d1695 <vsnprintf+315/4d0>
   e:   8b 54 24 20               mov    0x20(%esp),%edx
Code;  c01d1699 <vsnprintf+319/4d0>
  12:   83 44 24 48 04            addl   $0x4,0x48(%esp)
Code;  c01d169e <vsnprintf+31e/4d0>
  17:   8b 08                     mov    (%eax),%ecx
Code;  c01d16a0 <vsnprintf+320/4d0>
  19:   b8 ec 2b 33 c0            mov    $0xc0332bec,%eax
Code;  c01d16a5 <vsnprintf+325/4d0>
  1e:   81 f9 ff 0f 00 00         cmp    $0xfff,%ecx
Code;  c01d16ab <vsnprintf+32b/4d0>
  24:   0f 46 c8                  cmovbe %eax,%ecx
Code;  c01d16ae <vsnprintf+32e/4d0>
  27:   89 c8                     mov    %ecx,%eax
Code;  c01d16b0 <vsnprintf+330/4d0>
  29:   eb 06                     jmp    31 <_EIP+0x31>

This decode from eip onwards should be reliable

Code;  c01d16b2 <vsnprintf+332/4d0>
00000000 <_EIP>:
Code;  c01d16b2 <vsnprintf+332/4d0>   <=====
   0:   80 38 00                  cmpb   $0x0,(%eax)   <=====
Code;  c01d16b5 <vsnprintf+335/4d0>
   3:   74 07                     je     c <_EIP+0xc>
Code;  c01d16b7 <vsnprintf+337/4d0>
   5:   40                        inc    %eax
Code;  c01d16b8 <vsnprintf+338/4d0>
   6:   4a                        dec    %edx
Code;  c01d16b9 <vsnprintf+339/4d0>
   7:   83 fa ff                  cmp    $0xffffffff,%edx
Code;  c01d16bc <vsnprintf+33c/4d0>
   a:   75 f4                     jne    0 <_EIP>
Code;  c01d16be <vsnprintf+33e/4d0>
   c:   29 c8                     sub    %ecx,%eax
Code;  c01d16c0 <vsnprintf+340/4d0>
   e:   83 e7 10                  and    $0x10,%edi
Code;  c01d16c3 <vsnprintf+343/4d0>
  11:   89 c3                     mov    %eax,%ebx
Code;  c01d16c5 <vsnprintf+345/4d0>
  13:   75 20                     jne    35 <_EIP+0x35>

-- 
  .''`.   Martin Loschwitz           Debian GNU/Linux developer
 : :'  :  madkiss@madkiss.org        madkiss@debian.org
 `. `'`   http://www.madkiss.org/    people.debian.org/~madkiss/
   `-     Use Debian GNU/Linux 3.0!  See http://www.debian.org/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: local DDOS? Kernel panic when accessing /proc/ioports

[linux-os (Dick Johnson)]

On Fri, 5 Aug 2005, Martin Loschwitz wrote:

> Hi folks,
>
> I just ran into the following problem: Having updated my box to 2.6.12.3,
> I tried to start YaST2 and noticed a kernel panic (see below). Some quick
> debugging brought the result that the kernel crashes while some user (not
> even root ...) tries to access /proc/ioports. Is this a known problem and
> if so, is a fix available?
>
> Ooops and ksymoops-output is attached.
>

This can happen if a module is unloaded that doesn't free its
resources! Been there, done that.

> =============
> Oops
> =============
>
> Unable to handle kernel paging request at virtual address e081e6a8
> printing eip:
> c01d16b2
> *pde = 1ff5b067
> *pte = 00000000
> Oops: 0000 [#1]
> Modules linked in: snd_mixer_oss snd radeon drm dm_mod autofs4 af_packet ext3 jbd i810_audio ac97_codec soundcore b44 mii intel_agp agpgart i2c_i801 i2c_core ipw2200 firmware_class ieee80211 ieee80211_crypt parport_pc parport 8250 serial_core usbhid ohci_hcd uhci_hcd pcmcia yenta_socket rsrc_nonstatic pcmcia_core video thermal processor fan container button battery ac genrtc unionfs loop sbp2 ohci1394 ieee1394 usb_storage ub ehci_hcd usbcore
> CPU:    0
> EIP:    0060:[<c01d16b2>]    Not tainted VLI
> EFLAGS: 00210297   (2.6.12.3)
> EIP is at vsnprintf+0x332/0x4d0
> eax: e081e6a8   ebx: 0000000a   ecx: e081e6a8   edx: fffffffe
> esi: c71760e9   edi: 00000000   ebp: c7176fff   esp: c457deb4
> ds: 007b   es: 007b   ss: 0068
> Process cat (pid: 3275, threadinfo=c457c000 task=c5052020)
> Stack: c71760e2 c7176fff 00000323 00000000 00000010 00000004 00000002 00000001
>       ffffffff ffffffff c4f7d640 c031f3ad c4f7d640 000000dd c01789c7 c71760dd
>       00000f23 c03265ef c457df2c c03265dd c011e934 c4f7d640 c03265dd 00000000
> Call Trace:
> [<c01789c7>] seq_printf+0x37/0x60
> [<c011e934>] r_show+0x84/0x90
> [<c01784c6>] seq_read+0x1d6/0x2d0
> [<c0158b85>] vfs_read+0xe5/0x160
> [<c0158ea1>] sys_read+0x51/0x80
> [<c0102f79>] syscall_call+0x7/0xb
> Code: 00 83 cf 01 89 44 24 24 eb bb 8b 44 24 48 8b 54 24 20 83 44 24 48 04 8b 08 b8 ec 2b 33 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 75 20
>
> =============
> Ksymoops
> =============
>
>>> EIP; c01d16b2 <vsnprintf+332/4d0>   <=====
>
>>> eax; e081e6a8 <pg0+203236a8/3fb03400>
>>> ecx; e081e6a8 <pg0+203236a8/3fb03400>
>>> edx; fffffffe <__kernel_rt_sigreturn+1bbe/????>
>>> esi; c71760e9 <pg0+6c7b0e9/3fb03400>
>>> ebp; c7176fff <pg0+6c7bfff/3fb03400>
>>> esp; c457deb4 <pg0+4082eb4/3fb03400>
>
> Trace; c01789c7 <seq_printf+37/60>
> Trace; c011e934 <r_show+84/90>
> Trace; c01784c6 <seq_read+1d6/2d0>
> Trace; c0158b85 <vfs_read+e5/160>
> Trace; c0158ea1 <sys_read+51/80>
> Trace; c0102f79 <syscall_call+7/b>
>
> This architecture has variable length instructions, decoding before eip
> is unreliable, take these instructions with a pinch of salt.
>
> Code;  c01d1687 <vsnprintf+307/4d0>
> 00000000 <_EIP>:
> Code;  c01d1687 <vsnprintf+307/4d0>
>   0:   00 83 cf 01 89 44         add    %al,0x448901cf(%ebx)
> Code;  c01d168d <vsnprintf+30d/4d0>
>   6:   24 24                     and    $0x24,%al
> Code;  c01d168f <vsnprintf+30f/4d0>
>   8:   eb bb                     jmp    ffffffc5 <_EIP+0xffffffc5>
> Code;  c01d1691 <vsnprintf+311/4d0>
>   a:   8b 44 24 48               mov    0x48(%esp),%eax
> Code;  c01d1695 <vsnprintf+315/4d0>
>   e:   8b 54 24 20               mov    0x20(%esp),%edx
> Code;  c01d1699 <vsnprintf+319/4d0>
>  12:   83 44 24 48 04            addl   $0x4,0x48(%esp)
> Code;  c01d169e <vsnprintf+31e/4d0>
>  17:   8b 08                     mov    (%eax),%ecx
> Code;  c01d16a0 <vsnprintf+320/4d0>
>  19:   b8 ec 2b 33 c0            mov    $0xc0332bec,%eax
> Code;  c01d16a5 <vsnprintf+325/4d0>
>  1e:   81 f9 ff 0f 00 00         cmp    $0xfff,%ecx
> Code;  c01d16ab <vsnprintf+32b/4d0>
>  24:   0f 46 c8                  cmovbe %eax,%ecx
> Code;  c01d16ae <vsnprintf+32e/4d0>
>  27:   89 c8                     mov    %ecx,%eax
> Code;  c01d16b0 <vsnprintf+330/4d0>
>  29:   eb 06                     jmp    31 <_EIP+0x31>
>
> This decode from eip onwards should be reliable
>
> Code;  c01d16b2 <vsnprintf+332/4d0>
> 00000000 <_EIP>:
> Code;  c01d16b2 <vsnprintf+332/4d0>   <=====
>   0:   80 38 00                  cmpb   $0x0,(%eax)   <=====
> Code;  c01d16b5 <vsnprintf+335/4d0>
>   3:   74 07                     je     c <_EIP+0xc>
> Code;  c01d16b7 <vsnprintf+337/4d0>
>   5:   40                        inc    %eax
> Code;  c01d16b8 <vsnprintf+338/4d0>
>   6:   4a                        dec    %edx
> Code;  c01d16b9 <vsnprintf+339/4d0>
>   7:   83 fa ff                  cmp    $0xffffffff,%edx
> Code;  c01d16bc <vsnprintf+33c/4d0>
>   a:   75 f4                     jne    0 <_EIP>
> Code;  c01d16be <vsnprintf+33e/4d0>
>   c:   29 c8                     sub    %ecx,%eax
> Code;  c01d16c0 <vsnprintf+340/4d0>
>   e:   83 e7 10                  and    $0x10,%edi
> Code;  c01d16c3 <vsnprintf+343/4d0>
>  11:   89 c3                     mov    %eax,%ebx
> Code;  c01d16c5 <vsnprintf+345/4d0>
>  13:   75 20                     jne    35 <_EIP+0x35>
>
> --
>  .''`.   Martin Loschwitz           Debian GNU/Linux developer
> : :'  :  madkiss@madkiss.org        madkiss@debian.org
> `. `'`   http://www.madkiss.org/    people.debian.org/~madkiss/
>   `-     Use Debian GNU/Linux 3.0!  See http://www.debian.org/
>

Cheers,
Dick Johnson
Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips).
Warning : 98.36% of all statistics are fiction.
.
I apologize for the following. I tried to kill it with the above dot :

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: local DDOS? Kernel panic when accessing /proc/ioports

[Chris Wright]

* Martin Loschwitz (madkiss@madkiss.org) wrote:
> I just ran into the following problem: Having updated my box to 2.6.12.3, 
> I tried to start YaST2 and noticed a kernel panic (see below). Some quick
> debugging brought the result that the kernel crashes while some user (not
> even root ...) tries to access /proc/ioports. Is this a known problem and
> if so, is a fix available?

First I've heard of it.  I can't trigger here with simple cat
/proc/ioports.  Must be specific to your setup.  What was the last
working kernel, and what's that ioport output look like?

thanks,
-chris

Re: local DDOS? Kernel panic when accessing /proc/ioports

[Lee Revell]

On Fri, 2005-08-05 at 21:26 +0200, Martin Loschwitz wrote:
> Ooops and ksymoops-output is attached.

Also, don't use ksymoops for 2.6, it's redundant at best and at worst
actually removes information.  Check oops-tracing.txt, the docs have
been updated.

Lee

Re: local DDOS? Kernel panic when accessing /proc/ioports

[Martin Loschwitz]

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

On Fri, Aug 05, 2005 at 03:40:26PM -0400, linux-os (Dick Johnson) wrote:
> 
> On Fri, 5 Aug 2005, Martin Loschwitz wrote:
> 
> > Hi folks,
> >
> > I just ran into the following problem: Having updated my box to 2.6.12.3,
> > I tried to start YaST2 and noticed a kernel panic (see below). Some quick
> > debugging brought the result that the kernel crashes while some user (not
> > even root ...) tries to access /proc/ioports. Is this a known problem and
> > if so, is a fix available?
> >
> > Ooops and ksymoops-output is attached.
> >
> 
> This can happen if a module is unloaded that doesn't free its
> resources! Been there, done that.
> 

"This can happen" is not an acceptable explanation, I think. Modules should
not be able to kill the kernel -- apart from that, I can trigger the bug in
the very early "ash-system" that KNOPPIX provides. At that time, the modules
listed below were the only ones loaded -- no others, and I am also sure that
until that point, no modules were unloaded.

sbp2 ohci1394 usb_storage ub ehci_hcd usbcore

-- 
  .''`.   Martin Loschwitz           Debian GNU/Linux developer
 : :'  :  madkiss@madkiss.org        madkiss@debian.org
 `. `'`   http://www.madkiss.org/    people.debian.org/~madkiss/
   `-     Use Debian GNU/Linux 3.0!  See http://www.debian.org/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: local DDOS? Kernel panic when accessing /proc/ioports

[Martin Loschwitz]

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

On Fri, Aug 05, 2005 at 12:50:56PM -0700, Chris Wright wrote:
> * Martin Loschwitz (madkiss@madkiss.org) wrote:
> > I just ran into the following problem: Having updated my box to 2.6.12.3, 
> > I tried to start YaST2 and noticed a kernel panic (see below). Some quick
> > debugging brought the result that the kernel crashes while some user (not
> > even root ...) tries to access /proc/ioports. Is this a known problem and
> > if so, is a fix available?
> 
> First I've heard of it.  I can't trigger here with simple cat
> /proc/ioports.  Must be specific to your setup.  What was the last
> working kernel, and what's that ioport output look like?
> 

The situation in this case is somewhat obscene ... Originally, I had exactly
this problem while using the Knoppix standard kernel (2.6.11 vanilla SMP). I
then went to compile 2.6.12.3, also with SMP, and it showed exactly the same
problem. I disable SMP, tried again -- voila, it worked.

The kernel that I am encountering this error again now is 2.6.12.3 -- without
SMP or whatsoever. I'm just out of ideas on how to fix it this time.

> thanks,
> -chris

-- 
  .''`.   Martin Loschwitz           Debian GNU/Linux developer
 : :'  :  madkiss@madkiss.org        madkiss@debian.org
 `. `'`   http://www.madkiss.org/    people.debian.org/~madkiss/
   `-     Use Debian GNU/Linux 3.0!  See http://www.debian.org/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: local DDOS? Kernel panic when accessing /proc/ioports

[Martin Loschwitz]

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

On Fri, Aug 05, 2005 at 04:03:07PM -0400, Lee Revell wrote:
> On Fri, 2005-08-05 at 21:26 +0200, Martin Loschwitz wrote:
> > Ooops and ksymoops-output is attached.
> 
> Also, don't use ksymoops for 2.6, it's redundant at best and at worst
> actually removes information.  Check oops-tracing.txt, the docs have
> been updated.
> 

Well, in this case, ksymoops output told me what I wanted to know -- the
thing explodes when reading /proc/ioports. I need to know why it does, if
the problem might be reproducible for others (that is the possible ddos
thing ...) and how to fix it ...

> Lee
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
  .''`.   Martin Loschwitz           Debian GNU/Linux developer
 : :'  :  madkiss@madkiss.org        madkiss@debian.org
 `. `'`   http://www.madkiss.org/    people.debian.org/~madkiss/
   `-     Use Debian GNU/Linux 3.0!  See http://www.debian.org/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: local DDOS? Kernel panic when accessing /proc/ioports

[Andrew Morton]

Martin Loschwitz <madkiss@madkiss.org> wrote:
>
> On Fri, Aug 05, 2005 at 03:40:26PM -0400, linux-os (Dick Johnson) wrote:
> > 
> > On Fri, 5 Aug 2005, Martin Loschwitz wrote:
> > 
> > > Hi folks,
> > >
> > > I just ran into the following problem: Having updated my box to 2.6.12.3,
> > > I tried to start YaST2 and noticed a kernel panic (see below). Some quick
> > > debugging brought the result that the kernel crashes while some user (not
> > > even root ...) tries to access /proc/ioports. Is this a known problem and
> > > if so, is a fix available?
> > >
> > > Ooops and ksymoops-output is attached.
> > >
> > 
> > This can happen if a module is unloaded that doesn't free its
> > resources! Been there, done that.
> > 
> 
> "This can happen" is not an acceptable explanation, I think.

It's a very accurate one though.

The most common cause of this bug is that some buggy kernel module has been
unloaded.  It forgot to release its I/O region.  When you later come along
to look in /proc/ioports the kernel goes to fetch information from the
memory which is "owned" by the module which isn't there any more.  Crash.

So if you can identify which kernel module was loaded and then unloaded,
we'll fix it up.

Re: local DDOS? Kernel panic when accessing /proc/ioports

[Martin Loschwitz]

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

On Fri, Aug 05, 2005 at 03:33:44PM -0700, Andrew Morton wrote:
> Martin Loschwitz <madkiss@madkiss.org> wrote:
> >
> > On Fri, Aug 05, 2005 at 03:40:26PM -0400, linux-os (Dick Johnson) wrote:
> > > 
> > > On Fri, 5 Aug 2005, Martin Loschwitz wrote:
> > > 
> > > > Hi folks,
> > > >
> > > > I just ran into the following problem: Having updated my box to 2.6.12.3,
> > > > I tried to start YaST2 and noticed a kernel panic (see below). Some quick
> > > > debugging brought the result that the kernel crashes while some user (not
> > > > even root ...) tries to access /proc/ioports. Is this a known problem and
> > > > if so, is a fix available?
> > > >
> > > > Ooops and ksymoops-output is attached.
> > > >
> > > 
> > > This can happen if a module is unloaded that doesn't free its
> > > resources! Been there, done that.
> > > 
> > 
> > "This can happen" is not an acceptable explanation, I think.
> 
> It's a very accurate one though.
> 
> The most common cause of this bug is that some buggy kernel module has been
> unloaded.  It forgot to release its I/O region.  When you later come along
> to look in /proc/ioports the kernel goes to fetch information from the
> memory which is "owned" by the module which isn't there any more.  Crash.
> 
> So if you can identify which kernel module was loaded and then unloaded,
> we'll fix it up.

uhm -- well, okay, once again: If you boot knoppix with the "debug" argument,
it will start init but throw you on a very limited shell called "ash" right
after that. At least the "cat" command is included in that shell, and lsmod 
is available as well.

I am pretty sure that until that very early moment, not a single module has
been unloaded -- infact, "rmmod" is not even called in the init script until
that moment. The only modules loaded were:

sbp2 ohci1394 usb_storage ub ehci_hcd usbcore

And that's it. So if you suspect some module to be the culprit, it must be
one of these.

-- 
  .''`.   Martin Loschwitz           Debian GNU/Linux developer
 : :'  :  madkiss@madkiss.org        madkiss@debian.org
 `. `'`   http://www.madkiss.org/    people.debian.org/~madkiss/
   `-     Use Debian GNU/Linux 3.0!  See http://www.debian.org/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: local DDOS? Kernel panic when accessing /proc/ioports

[Marc Ballarin]

On Fri, 5 Aug 2005 23:52:47 +0200
Martin Loschwitz <madkiss@madkiss.org> wrote:

> 
> The situation in this case is somewhat obscene ... Originally, I had exactly
> this problem while using the Knoppix standard kernel (2.6.11 vanilla SMP). I
> then went to compile 2.6.12.3, also with SMP, and it showed exactly the same
> problem. I disable SMP, tried again -- voila, it worked.
> 
> The kernel that I am encountering this error again now is 2.6.12.3 -- without
> SMP or whatsoever. I'm just out of ideas on how to fix it this time.

Did you always use the same machine? If so, can you rule out hardware
issues? Can you reproduce this Oops at will?

I can't reproduce this on various machines (all X86, kernels  2.6.11.9,
2.6.12.2, 2.6.13-rc4-mm1, no SMP)

Regards

Re: local DDOS? Kernel panic when accessing /proc/ioports

[Martin Loschwitz]

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

On Sat, Aug 06, 2005 at 01:29:09AM +0200, Marc Ballarin wrote:
> On Fri, 5 Aug 2005 23:52:47 +0200
> Martin Loschwitz <madkiss@madkiss.org> wrote:
> 
> > 
> > The situation in this case is somewhat obscene ... Originally, I had exactly
> > this problem while using the Knoppix standard kernel (2.6.11 vanilla SMP). I
> > then went to compile 2.6.12.3, also with SMP, and it showed exactly the same
> > problem. I disable SMP, tried again -- voila, it worked.
> > 
> > The kernel that I am encountering this error again now is 2.6.12.3 -- without
> > SMP or whatsoever. I'm just out of ideas on how to fix it this time.
> 
> Did you always use the same machine? If so, can you rule out hardware
> issues? Can you reproduce this Oops at will?
> 
I tried it on different machines -- same effect. Yes, I can reproduce it at
will.

> I can't reproduce this on various machines (all X86, kernels  2.6.11.9,
> 2.6.12.2, 2.6.13-rc4-mm1, no SMP)
> 
> Regards

-- 
  .''`.   Martin Loschwitz           Debian GNU/Linux developer
 : :'  :  madkiss@madkiss.org        madkiss@debian.org
 `. `'`   http://www.madkiss.org/    people.debian.org/~madkiss/
   `-     Use Debian GNU/Linux 3.0!  See http://www.debian.org/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: local DDOS? Kernel panic when accessing /proc/ioports

[Jan Engelhardt]

>>> I just ran into the following problem: Having updated my box to 2.6.12.3,
>>> I tried to start YaST2 and noticed a kernel panic (see below). Some quick

Hm I always have a slack feeling that vanilla does not play hand in hand with 
SUSE. (E.g.: showconsole)

>>> Ooops and ksymoops-output is attached.

ksymoops not needed for 2.6.

>> Been there, done that.

"...[and] threw it out"



Jan Engelhardt
-- 

Re: local DDOS? Kernel panic when accessing /proc/ioports

[linux-os (Dick Johnson)]

On Fri, 5 Aug 2005, Martin Loschwitz wrote:

> On Fri, Aug 05, 2005 at 03:40:26PM -0400, linux-os (Dick Johnson) wrote:
>>
>> On Fri, 5 Aug 2005, Martin Loschwitz wrote:
>>
>>> Hi folks,
>>>
>>> I just ran into the following problem: Having updated my box to 2.6.12.3,
>>> I tried to start YaST2 and noticed a kernel panic (see below). Some quick
>>> debugging brought the result that the kernel crashes while some user (not
>>> even root ...) tries to access /proc/ioports. Is this a known problem and
>>> if so, is a fix available?
>>>
>>> Ooops and ksymoops-output is attached.
>>>
>>
>> This can happen if a module is unloaded that doesn't free its
>> resources! Been there, done that.
>>
>
> "This can happen" is not an acceptable explanation, I think. Modules should

Of course it is. You find the module that isn't freeing it's
resources, fix it, and you don't get the panic when you access
/proc/ioports. It's really that simple.

Thinking that modules shouldn't be able to kill the kernel isn't
goint to help. Everything that runs inside the kernel has the
necessary priviliges to destroy anything in the kernel.

> not be able to kill the kernel -- apart from that, I can trigger the bug in
> the very early "ash-system" that KNOPPIX provides. At that time, the modules
> listed below were the only ones loaded -- no others, and I am also sure that
> until that point, no modules were unloaded.
>
> sbp2 ohci1394 usb_storage ub ehci_hcd usbcore
>
> --
>  .''`.   Martin Loschwitz           Debian GNU/Linux developer
> : :'  :  madkiss@madkiss.org        madkiss@debian.org
> `. `'`   http://www.madkiss.org/    people.debian.org/~madkiss/
>   `-     Use Debian GNU/Linux 3.0!  See http://www.debian.org/
>

Cheers,
Dick Johnson
Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips).
Warning : 98.36% of all statistics are fiction.
.
I apologize for the following. I tried to kill it with the above dot :

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.