kernel BUG at slab.c:1542! (2.4.1-pre9)

kernel BUG at slab.c:1542! (2.4.1-pre9)

[Jorge Nerin]

Hello, this is perfectly reproductable, fresh RH7.0 kernel 2.4.1-pre9
compiled with kgcc, and the same bug in pre1, pre4 & pre9. I only need
to run xfontsel and the xfs dies, every time, prefectly reproductable.

Using XFree86-xfs-4.0.1-1, and this XFree packages:
XFree86-4.0.1-1
XFree86-tools-4.0.1-1
XFree86-xdm-4.0.1-1
XFree86-libs-4.0.1-1
XFree86-xfs-4.0.1-1
XFree86-75dpi-fonts-4.0.1-1
XFree86-SVGA-3.3.6-33
XFree86-twm-4.0.1-1
XFree86-VGA16-3.3.6-33
XFree86-Xnest-4.0.1-1
XFree86-devel-4.0.1-1
XFree86-V4L-4.0.1-1

Pentium 2x200mmx 96mb ram, voodoo 3 200pci, more info as requested, and
also some patches are welcome.

ksymoops 2.3.4 on i586 2.4.1-pre9.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.4.1-pre9/ (default)
     -m /usr/src/linux/System.map (default)

Warning: You did not tell me where to find symbol information.  I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc.  ksymoops -h explains the options.

activating NMI Watchdog ... done.
cpu: 0, clocks: 668150, slice: 222716
cpu: 1, clocks: 668150, slice: 222716
8139too Fast Ethernet driver 0.9.13 loaded
invalid operand: 0000
CPU:    1
EIP:    0010:[<c012c056>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010292
eax: 0000001b   ebx: c27cc680   ecx: 00000008   edx: c5802ca0
esi: 00000003   edi: c4310000   ebp: c4310000   esp: c4311de4
ds: 0018   es: 0018   ss: 0018
Process xfs (pid: 909, stackpage=c4311000)
Stack: c01e97a5 c01e9825 00000606 c27cc680 00000003 c4310000 c4310000
c0111d3b 
       c5fe3f0c 000001a8 c0196cfa 0003fff4 00000003 00000000 c5c96c20
c4310000 
       00000ff0 00000206 c01963fe 0003fff0 00000003 c2f8a164 0003ffec
c01d1550 
Call Trace: [<c0111d3b>] [<c0196cfa>] [<c01963fe>] [<c01d1550>]
[<c01d167e>] [<c01d1550>] [<c0193fad>] 
       [<c01d1550>] [<c0194260>] [<c01942e2>] [<c0134763>] [<c01348c9>]
[<c0108fc7>] 
Code: 0f 0b 83 c4 0c 90 8d 74 26 00 31 c0 5b 5e 5f 5d 83 c4 0c c3 

>>EIP; c012c056 <kmalloc+112/128>   <=====
Trace; c0111d3b <smp_call_function_interrupt+1f/34>
Trace; c0196cfa <alloc_skb+102/1a0>
Trace; c01963fe <sock_alloc_send_skb+72/12c>
Trace; c01d1550 <unix_stream_sendmsg+0/310>
Trace; c01d167e <unix_stream_sendmsg+12e/310>
Trace; c01d1550 <unix_stream_sendmsg+0/310>
Trace; c0193fad <sock_sendmsg+81/a4>
Trace; c01d1550 <unix_stream_sendmsg+0/310>
Trace; c0194260 <sock_readv_writev+8c/98>
Trace; c01942e2 <sock_writev+36/40>
Trace; c0134763 <do_readv_writev+183/254>
Trace; c01348c9 <sys_writev+41/54>
Trace; c0108fc7 <system_call+37/40>
Code;  c012c056 <kmalloc+112/128>
00000000 <_EIP>:
Code;  c012c056 <kmalloc+112/128>   <=====
   0:   0f 0b                     ud2a      <=====
Code;  c012c058 <kmalloc+114/128>
   2:   83 c4 0c                  add    $0xc,%esp
Code;  c012c05b <kmalloc+117/128>
   5:   90                        nop    
Code;  c012c05c <kmalloc+118/128>
   6:   8d 74 26 00               lea    0x0(%esi,1),%esi
Code;  c012c060 <kmalloc+11c/128>
   a:   31 c0                     xor    %eax,%eax
Code;  c012c062 <kmalloc+11e/128>
   c:   5b                        pop    %ebx
Code;  c012c063 <kmalloc+11f/128>
   d:   5e                        pop    %esi
Code;  c012c064 <kmalloc+120/128>
   e:   5f                        pop    %edi
Code;  c012c065 <kmalloc+121/128>
   f:   5d                        pop    %ebp
Code;  c012c066 <kmalloc+122/128>
  10:   83 c4 0c                  add    $0xc,%esp
Code;  c012c069 <kmalloc+125/128>
  13:   c3                        ret    


1 warning issued.  Results may not be reliable.




kernel BUG at slab.c:1542!
invalid operand: 0000
CPU:    1
EIP:    0010:[kmalloc+274/296]
EFLAGS: 00010292
eax: 0000001b   ebx: c27cc680   ecx: 00000008   edx: c5802ca0
esi: 00000003   edi: c4310000   ebp: c4310000   esp: c4311de4
ds: 0018   es: 0018   ss: 0018
Process xfs (pid: 909, stackpage=c4311000)
Stack: c01e97a5 c01e9825 00000606 c27cc680 00000003 c4310000 c4310000
c0111d3b 
       c5fe3f0c 000001a8 c0196cfa 0003fff4 00000003 00000000 c5c96c20
c4310000 
       00000ff0 00000206 c01963fe 0003fff0 00000003 c2f8a164 0003ffec
c01d1550 
Call Trace: [smp_call_function_interrupt+31/52] [alloc_skb+258/416]
[sock_alloc_send_skb+114/300] [unix_stream_sendmsg+0/784]
[unix_stream_sendmsg+302/784] [unix_stream_sendmsg+0/784]
[sock_sendmsg+129/164] 
       [unix_stream_sendmsg+0/784] [sock_readv_writev+140/152]
[sock_writev+54/64] [do_readv_writev+387/596] [sys_writev+65/84]
[system_call+55/64] 

Code: 0f 0b 83 c4 0c 90 8d 74 26 00 31 c0 5b 5e 5f 5d 83 c4 0c c3 


-- 
Jorge Nerin
<comandante@zaralinux.com>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: kernel BUG at slab.c:1542!(2.4.1-pre9)

[Shawn Starr]

This is not a kernel bug, This is a bug in the XFree86 TrueType rendering
extention. This has been discussed on the Xpert XFree86 mailing list. There
is a fix in the works (depends on the TrueType fonts your using).

Unless otherwise, Im using 2.4.1-pre9 with no such faults (XFree86 CVS
X11R6.5.1 merge sources) not 4.0.2 stable.

Shawn.

Jorge Nerin wrote:


> Hello, this is perfectly reproductable, fresh RH7.0 kernel 2.4.1-pre9
> compiled with kgcc, and the same bug in pre1, pre4 & pre9. I only need
> to run xfontsel and the xfs dies, every time, prefectly reproductable.
>
> Using XFree86-xfs-4.0.1-1, and this XFree packages:
> XFree86-4.0.1-1
> XFree86-tools-4.0.1-1
> XFree86-xdm-4.0.1-1
> XFree86-libs-4.0.1-1
> XFree86-xfs-4.0.1-1
> XFree86-75dpi-fonts-4.0.1-1
> XFree86-SVGA-3.3.6-33
> XFree86-twm-4.0.1-1
> XFree86-VGA16-3.3.6-33
> XFree86-Xnest-4.0.1-1
> XFree86-devel-4.0.1-1
> XFree86-V4L-4.0.1-1
>
> Pentium 2x200mmx 96mb ram, voodoo 3 200pci, more info as requested, and
> also some patches are welcome.
>
> ksymoops 2.3.4 on i586 2.4.1-pre9.  Options used
>      -V (default)
>      -k /proc/ksyms (default)
>      -l /proc/modules (default)
>      -o /lib/modules/2.4.1-pre9/ (default)
>      -m /usr/src/linux/System.map (default)
>
> Warning: You did not tell me where to find symbol information.  I will
> assume that the log matches the kernel and modules that are running
> right now and I'll use the default options above for symbol resolution.
> If the current kernel and/or modules do not match the log, you can get
> more accurate output by telling me the kernel version and where to find
> map, modules, ksyms etc.  ksymoops -h explains the options.
>
> activating NMI Watchdog ... done.
> cpu: 0, clocks: 668150, slice: 222716
> cpu: 1, clocks: 668150, slice: 222716
> 8139too Fast Ethernet driver 0.9.13 loaded
> invalid operand: 0000
> CPU:    1
> EIP:    0010:[<c012c056>]
> Using defaults from ksymoops -t elf32-i386 -a i386
> EFLAGS: 00010292
> eax: 0000001b   ebx: c27cc680   ecx: 00000008   edx: c5802ca0
> esi: 00000003   edi: c4310000   ebp: c4310000   esp: c4311de4
> ds: 0018   es: 0018   ss: 0018
> Process xfs (pid: 909, stackpage=c4311000)
> Stack: c01e97a5 c01e9825 00000606 c27cc680 00000003 c4310000 c4310000
> c0111d3b
>        c5fe3f0c 000001a8 c0196cfa 0003fff4 00000003 00000000 c5c96c20
> c4310000
>        00000ff0 00000206 c01963fe 0003fff0 00000003 c2f8a164 0003ffec
> c01d1550
> Call Trace: [<c0111d3b>] [<c0196cfa>] [<c01963fe>] [<c01d1550>]
> [<c01d167e>] [<c01d1550>] [<c0193fad>]
>        [<c01d1550>] [<c0194260>] [<c01942e2>] [<c0134763>] [<c01348c9>]
> [<c0108fc7>]
> Code: 0f 0b 83 c4 0c 90 8d 74 26 00 31 c0 5b 5e 5f 5d 83 c4 0c c3
>
> >>EIP; c012c056 <kmalloc+112/128>   <=====
> Trace; c0111d3b <smp_call_function_interrupt+1f/34>
> Trace; c0196cfa <alloc_skb+102/1a0>
> Trace; c01963fe <sock_alloc_send_skb+72/12c>
> Trace; c01d1550 <unix_stream_sendmsg+0/310>
> Trace; c01d167e <unix_stream_sendmsg+12e/310>
> Trace; c01d1550 <unix_stream_sendmsg+0/310>
> Trace; c0193fad <sock_sendmsg+81/a4>
> Trace; c01d1550 <unix_stream_sendmsg+0/310>
> Trace; c0194260 <sock_readv_writev+8c/98>
> Trace; c01942e2 <sock_writev+36/40>
> Trace; c0134763 <do_readv_writev+183/254>
> Trace; c01348c9 <sys_writev+41/54>
> Trace; c0108fc7 <system_call+37/40>
> Code;  c012c056 <kmalloc+112/128>
> 00000000 <_EIP>:
> Code;  c012c056 <kmalloc+112/128>   <=====
>    0:   0f 0b                     ud2a      <=====
> Code;  c012c058 <kmalloc+114/128>
>    2:   83 c4 0c                  add    $0xc,%esp
> Code;  c012c05b <kmalloc+117/128>
>    5:   90                        nop
> Code;  c012c05c <kmalloc+118/128>
>    6:   8d 74 26 00               lea    0x0(%esi,1),%esi
> Code;  c012c060 <kmalloc+11c/128>
>    a:   31 c0                     xor    %eax,%eax
> Code;  c012c062 <kmalloc+11e/128>
>    c:   5b                        pop    %ebx
> Code;  c012c063 <kmalloc+11f/128>
>    d:   5e                        pop    %esi
> Code;  c012c064 <kmalloc+120/128>
>    e:   5f                        pop    %edi
> Code;  c012c065 <kmalloc+121/128>
>    f:   5d                        pop    %ebp
> Code;  c012c066 <kmalloc+122/128>
>   10:   83 c4 0c                  add    $0xc,%esp
> Code;  c012c069 <kmalloc+125/128>
>   13:   c3                        ret
>
> 1 warning issued.  Results may not be reliable.
>
> kernel BUG at slab.c:1542!
> invalid operand: 0000
> CPU:    1
> EIP:    0010:[kmalloc+274/296]
> EFLAGS: 00010292
> eax: 0000001b   ebx: c27cc680   ecx: 00000008   edx: c5802ca0
> esi: 00000003   edi: c4310000   ebp: c4310000   esp: c4311de4
> ds: 0018   es: 0018   ss: 0018
> Process xfs (pid: 909, stackpage=c4311000)
> Stack: c01e97a5 c01e9825 00000606 c27cc680 00000003 c4310000 c4310000
> c0111d3b
>        c5fe3f0c 000001a8 c0196cfa 0003fff4 00000003 00000000 c5c96c20
> c4310000
>        00000ff0 00000206 c01963fe 0003fff0 00000003 c2f8a164 0003ffec
> c01d1550
> Call Trace: [smp_call_function_interrupt+31/52] [alloc_skb+258/416]
> [sock_alloc_send_skb+114/300] [unix_stream_sendmsg+0/784]
> [unix_stream_sendmsg+302/784] [unix_stream_sendmsg+0/784]
> [sock_sendmsg+129/164]
>        [unix_stream_sendmsg+0/784] [sock_readv_writev+140/152]
> [sock_writev+54/64] [do_readv_writev+387/596] [sys_writev+65/84]
> [system_call+55/64]
>
> Code: 0f 0b 83 c4 0c 90 8d 74 26 00 31 c0 5b 5e 5f 5d 83 c4 0c c3
>
> --
> Jorge Nerin
> <comandante@zaralinux.com>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/

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

Re: kernel BUG at slab.c:1542!(2.4.1-pre9)

[David Ford]

If it makes the kernel do Bad Things, the kernel needs to be fixed.

-d

Shawn Starr wrote:

> This is not a kernel bug, This is a bug in the XFree86 TrueType rendering
> extention. This has been discussed on the Xpert XFree86 mailing list. There
> is a fix in the works (depends on the TrueType fonts your using).
>
> Unless otherwise, Im using 2.4.1-pre9 with no such faults (XFree86 CVS
> X11R6.5.1 merge sources) not 4.0.2 stable.

--
  There is a natural aristocracy among men. The grounds of this are virtue and talents. Thomas Jefferson
  The good thing about standards is that there are so many to choose from. Andrew S. Tanenbaum



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

Re: kernel BUG at slab.c:1542!(2.4.1-pre9)

[Daniel Phillips]

Shawn Starr wrote:
> This is not a kernel bug, This is a bug in the XFree86 TrueType rendering
> extention. This has been discussed on the Xpert XFree86 mailing list. There
> is a fix in the works (depends on the TrueType fonts your using).

A BUG is a BUG:
 
> > kernel BUG at slab.c:1542!

The kernel should never oops, no matter what user space does to it.

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

Re: kernel BUG at slab.c:1542!(2.4.1-pre9)

[Gregory Maxwell]

On Wed, Jan 24, 2001 at 01:58:22PM +0100, Daniel Phillips wrote:
> > This is not a kernel bug, This is a bug in the XFree86 TrueType rendering
> > extention. This has been discussed on the Xpert XFree86 mailing list. There
> > is a fix in the works (depends on the TrueType fonts your using).
> 
> A BUG is a BUG:
>  
> > > kernel BUG at slab.c:1542!
> 
> The kernel should never oops, no matter what user space does to it.

The kernel appears to run fine with this bug() removed.

BTW- gimp and a few other apps also manage to trigger it..
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: kernel BUG at slab.c:1542!(2.4.1-pre9)

[Daniel Phillips]

Gregory Maxwell wrote:
> 
> On Wed, Jan 24, 2001 at 01:58:22PM +0100, Daniel Phillips wrote:
> > > This is not a kernel bug, This is a bug in the XFree86 TrueType rendering
> > > extention. This has been discussed on the Xpert XFree86 mailing list. There
> > > is a fix in the works (depends on the TrueType fonts your using).
> >
> > A BUG is a BUG:
> >
> > > > kernel BUG at slab.c:1542!
> >
> > The kernel should never oops, no matter what user space does to it.
> 
> The kernel appears to run fine with this bug() removed.

I don't know much about the history of this bug but it's quite clear
it's deliberately inserted:

	void * kmalloc (size_t size, int flags)
		<if allocation succeeds, exit>
	        BUG(); // too big size
	        return NULL;

It says "kernel allocation will *never* fail, and if you try to kmalloc
something too large, that's a bug too" - not a reason to try again.  I'd
check with Linus before solving the problem that way ;-)

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

Re: kernel BUG at slab.c:1542!(2.4.1-pre9)

[Andrew Morton]

Daniel Phillips wrote:
> 
> I don't know much about the history of this bug but it's quite clear
> it's deliberately inserted:
> 
>         void * kmalloc (size_t size, int flags)
>                 <if allocation succeeds, exit>
>                 BUG(); // too big size
>                 return NULL;
> 

I sent the below patch to Linus earlier today.  I didn't copy
any mailing list because it's a bit security-related.  Oh well.

If wmem_max is set to > 256kbytes, an application can
set SO_SNDBUF on a unix domain stream socket to >256k
and do a write() of >256k.  unix_stream_sendmsg()
then tries to kmalloc >128k and the kernel dies.

I don't like the idea of simply returning NULL from kmalloc in
this case, because an application which does

	setsockopt(fd, SOL_SOCKET, SO_SNDBUF, 256kbytes);
	write(fd, buf, 256kbytes);

will work perfectly well, until someone increases wmem_max
to greater than 256k.  This administrative action will
cause the above application to mysteriously start failing.




--- linux-2.4.1-pre10/include/linux/slab.h	Mon Jan  1 18:29:35 2001
+++ linux-akpm/include/linux/slab.h	Wed Jan 24 12:29:34 2001
@@ -75,6 +75,9 @@
 extern kmem_cache_t	*fs_cachep;
 extern kmem_cache_t	*sigact_cachep;
 
+/* Largest kmalloc which we support */
+extern size_t kmalloc_max;
+
 #endif	/* __KERNEL__ */
 
 #endif	/* _LINUX_SLAB_H */
--- linux-2.4.1-pre10/mm/slab.c	Tue Jan 23 19:28:16 2001
+++ linux-akpm/mm/slab.c	Wed Jan 24 12:57:47 2001
@@ -360,6 +360,9 @@
 /* Place maintainer for reaping. */
 static kmem_cache_t *clock_searchp = &cache_cache;
 
+/* Largest kmalloc which we support */
+size_t kmalloc_max;
+
 #define cache_chain (cache_cache.next)
 
 #ifdef CONFIG_SMP
@@ -455,6 +458,7 @@
 			      SLAB_CACHE_DMA|SLAB_HWCACHE_ALIGN, NULL, NULL);
 		if (!sizes->cs_dmacachep)
 			BUG();
+		kmalloc_max = sizes->cs_size;
 		sizes++;
 	} while (sizes->cs_size);
 }
--- linux-2.4.1-pre10/kernel/ksyms.c	Tue Jan 23 19:28:16 2001
+++ linux-akpm/kernel/ksyms.c	Wed Jan 24 12:17:28 2001
@@ -104,6 +104,7 @@
 EXPORT_SYMBOL(kmem_cache_alloc);
 EXPORT_SYMBOL(kmem_cache_free);
 EXPORT_SYMBOL(kmalloc);
+EXPORT_SYMBOL(kmalloc_max);
 EXPORT_SYMBOL(kfree);
 EXPORT_SYMBOL(vfree);
 EXPORT_SYMBOL(__vmalloc);
--- linux-2.4.1-pre10/net/unix/af_unix.c	Tue Jan 23 19:28:16 2001
+++ linux-akpm/net/unix/af_unix.c	Wed Jan 24 12:57:35 2001
@@ -1319,6 +1319,10 @@
 		if (size > sk->sndbuf/2 - 16)
 			size = sk->sndbuf/2 - 16;
 
+		/* Avoid oversized kmallocs */
+		if (size > kmalloc_max / 2 - 16)
+			size = kmalloc_max / 2 - 16;
+
 		/*
 		 *	Keep to page sized kmalloc()'s as various people
 		 *	have suggested. Big mallocs stress the vm too
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: kernel BUG at slab.c:1542!(2.4.1-pre9)

[Shawn Starr]

True, It's just odd that we're having the same problem with the X server, so its
a double whammy ;)
Daniel Phillips wrote:

> Shawn Starr wrote:
> > This is not a kernel bug, This is a bug in the XFree86 TrueType rendering
> > extention. This has been discussed on the Xpert XFree86 mailing list. There
> > is a fix in the works (depends on the TrueType fonts your using).
>
> A BUG is a BUG:
>
> > > kernel BUG at slab.c:1542!
>
> The kernel should never oops, no matter what user space does to it.
>
> --
> Daniel

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

Re: kernel BUG at slab.c:1542!(2.4.1-pre9)

[Tim Fletcher]

> > > kernel BUG at slab.c:1542!
>
> The kernel should never oops, no matter what user space does to it.

What ever a none privilaged user space apps does witness:

root@localhost# dd if=/dev/random of=/dev/mem

-- 
   Tim Fletcher - Network manager   .~.
                                    /V\      L   I   N   U   X
     nightshade@solanum.net        // \\  >Don't fear the penguin<
tim@parrswood.manchester.sch.uk   /(   )\
 irc: Night-Shade on quakenet      ^^-^^

Justice is incidental to law and order.
                -- J. Edgar Hoover

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

Re: kernel BUG at slab.c:1542!(2.4.1-pre9)

[Tim Fletcher]

> The kernel appears to run fine with this bug() removed.
>
> BTW- gimp and a few other apps also manage to trigger it..

You can add sane with an advansys scsi card and various scsi scanners to
that list

-- 
   Tim Fletcher - Network manager   .~.
                                    /V\      L   I   N   U   X
     nightshade@solanum.net        // \\  >Don't fear the penguin<
tim@parrswood.manchester.sch.uk   /(   )\
 irc: Night-Shade on quakenet      ^^-^^

Justice is incidental to law and order.
                -- J. Edgar Hoover

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

Re: kernel BUG at slab.c:1542!(2.4.1-pre9)

[Alan Cox]

> I sent the below patch to Linus earlier today.  I didn't copy
> any mailing list because it's a bit security-related.  Oh well.

Its been in -ac for  while but using a define since its a constant
so it not a secret 8)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: kernel BUG at slab.c:1542!(2.4.1-pre9)

[Russell King]

Tim Fletcher writes:
> What ever a none privilaged user space apps does witness:
> 
> root@localhost# dd if=/dev/random of=/dev/mem

If you can do that as a non-priviledged user, then you've got bigger
security problems than that.

/dev/mem should NOT be read/writable by anyone other than root.  Its
permissions should be no more than 600.
--
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

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