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

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 

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
<[email protected]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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.

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

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

-d

--
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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

A BUG is a BUG:

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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
     [email protected]        // \\  >Don't fear the penguin<
[email protected]   /(   )\
 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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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 ([email protected]) 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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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
     [email protected]        // \\  >Don't fear the penguin<
[email protected]   /(   )\
 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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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.

@@ -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 */

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

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

@@ -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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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

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