From: Andrew Morton <andrewm@uow.edu.au>
To: Daniel Phillips <phillips@innominate.de>
Cc: Gregory Maxwell <greg@linuxpower.cx>, linux-kernel@vger.kernel.org
Subject: Re: kernel BUG at slab.c:1542!(2.4.1-pre9)
Date: Thu, 25 Jan 2001 02:45:48 +1100 [thread overview]
Message-ID: <3A6EF8AC.DFC50D37@uow.edu.au> (raw)
In-Reply-To: <3A6C5058.C5AA7681@zaralinux.com> <3A6CB620.469A15A9@Home.net> <3A6ED16E.E8343678@innominate.de> <20010124082929.A1970@xi.linuxpower.cx> <3A6EE767.9BD35AC9@innominate.de>
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/
next prev parent reply other threads:[~2001-01-24 15:38 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-01-22 15:23 kernel BUG at slab.c:1542! (2.4.1-pre9) Jorge Nerin
2001-01-22 22:37 ` kernel BUG at slab.c:1542!(2.4.1-pre9) Shawn Starr
2001-01-23 3:02 ` David Ford
2001-01-24 12:58 ` Daniel Phillips
2001-01-24 13:29 ` Gregory Maxwell
2001-01-24 14:32 ` Daniel Phillips
2001-01-24 15:45 ` Andrew Morton [this message]
2001-01-25 1:18 ` Alan Cox
2001-01-24 18:05 ` Tim Fletcher
2001-01-24 17:50 ` Shawn Starr
2001-01-24 18:05 ` Tim Fletcher
2001-01-25 11:49 ` Russell King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3A6EF8AC.DFC50D37@uow.edu.au \
--to=andrewm@uow.edu.au \
--cc=greg@linuxpower.cx \
--cc=linux-kernel@vger.kernel.org \
--cc=phillips@innominate.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®