linux-stable.git/mm/slab.c, branch linux-3.3.y

Merge branch 'slab/for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/penberg/linux

2012-01-12T02:52:23+00:00

* 'slab/for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/penberg/linux:
  slub: disallow changing cpu_partial from userspace for debug caches
  slub: add missed accounting
  slub: Extract get_freelist from __slab_alloc
  slub: Switch per cpu partial page support off for debugging
  slub: fix a possible memleak in __slab_alloc()
  slub: fix slub_max_order Documentation
  slub: add missed accounting
  slab: add taint flag outputting to debug paths.
  slub: add taint flag outputting to debug paths
  slab: introduce slab_max_order kernel parameter
  slab: rename slab_break_gfp_order to slab_max_order

Merge branch 'slab/urgent' into slab/for-linus

2012-01-11T19:11:29+00:00

tracing/mm: Move include of trace/events/kmem.h out of header into slab.c

2012-01-09T22:19:33+00:00

Including trace/events/*.h TRACE_EVENT() macro headers in other headers
can cause strange side effects if another trace/event/*.h header
includes that header.  Having trace/events/kmem.h inside slab_def.h
caused a compile error in sparc64 when changes were done to some header
files.  Moving the kmem.h trace header out of slab.h and into slab.c
fixes the problem.

Note, both slub.c and slob.c already include the trace/events/kmem.h
file. Only slab.c had it missing.

Link: http://lkml.kernel.org/r/20120105190405.1e3191fb5a43b2a0f1655e1f@canb.auug.org.au

Reported-by: Stephen Rothwell 
Signed-off-by: Steven Rostedt 
Signed-off-by: Linus Torvalds

slab, lockdep: Fix silly bug

2011-12-05T08:44:00+00:00

Commit 30765b92 ("slab, lockdep: Annotate the locks before using
them") moves the init_lock_keys() call from after g_cpucache_up =
FULL, to before it. And overlooks the fact that init_node_lock_keys()
tests for it and ignores everything !FULL.

Introduce a LATE stage and change the lockdep test to be 
Cc: Pekka Enberg 
Cc: stable@kernel.org
Signed-off-by: Peter Zijlstra 
Signed-off-by: Ingo Molnar

slab: add taint flag outputting to debug paths.

2011-11-16T19:14:44+00:00

When we get corruption reports, it's useful to see if the kernel was
tainted, to rule out problems we can't do anything about.

Signed-off-by: Dave Jones 
Signed-off-by: Andrew Morton 
Signed-off-by: Pekka Enberg

slab: introduce slab_max_order kernel parameter

2011-11-10T19:25:30+00:00

Introduce new slab_max_order kernel parameter which is the equivalent of
slub_max_order.

For immediate purposes, allows users to override the heuristic that sets
the max order to 1 by default if they have more than 32MB of RAM.  This
may result in page allocation failures if there is substantial
fragmentation.

Another usecase would be to increase the max order for better
performance.

Acked-by: Christoph Lameter 
Signed-off-by: David Rientjes 
Signed-off-by: Pekka Enberg

slab: rename slab_break_gfp_order to slab_max_order

2011-11-10T19:25:30+00:00

slab_break_gfp_order is more appropriately named slab_max_order since it
enforces the maximum order size of slabs as long as a single object will
still fit.

Also rename BREAK_GFP_ORDER_{LO,HI} accordingly.

Acked-by: Christoph Lameter 
Signed-off-by: David Rientjes 
Signed-off-by: Pekka Enberg

mm: restrict access to slab files under procfs and sysfs

2011-09-27T19:59:27+00:00

Historically /proc/slabinfo and files under /sys/kernel/slab/* have
world read permissions and are accessible to the world.  slabinfo
contains rather private information related both to the kernel and
userspace tasks.  Depending on the situation, it might reveal either
private information per se or information useful to make another
targeted attack.  Some examples of what can be learned by
reading/watching for /proc/slabinfo entries:

1) dentry (and different *inode*) number might reveal other processes fs
activity.  The number of dentry "active objects" doesn't strictly show
file count opened/touched by a process, however, there is a good
correlation between them.  The patch "proc: force dcache drop on
unauthorized access" relies on the privacy of dentry count.

2) different inode entries might reveal the same information as (1), but
these are more fine granted counters.  If a filesystem is mounted in a
private mount point (or even a private namespace) and fs type differs from
other mounted fs types, fs activity in this mount point/namespace is
revealed.  If there is a single ecryptfs mount point, the whole fs
activity of a single user is revealed.  Number of files in ecryptfs
mount point is a private information per se.

3) fuse_* reveals number of files / fs activity of a user in a user
private mount point.  It is approx. the same severity as ecryptfs
infoleak in (2).

4) sysfs_dir_cache similar to (2) reveals devices' addition/removal,
which can be otherwise hidden by "chmod 0700 /sys/".  With 0444 slabinfo
the precise number of sysfs files is known to the world.

5) buffer_head might reveal some kernel activity.  With other
information leaks an attacker might identify what specific kernel
routines generate buffer_head activity.

6) *kmalloc* infoleaks are very situational.  Attacker should watch for
the specific kmalloc size entry and filter the noise related to the unrelated
kernel activity.  If an attacker has relatively silent victim system, he
might get rather precise counters.

Additional information sources might significantly increase the slabinfo
infoleak benefits.  E.g. if an attacker knows that the processes
activity on the system is very low (only core daemons like syslog and
cron), he may run setxid binaries / trigger local daemon activity /
trigger network services activity / await sporadic cron jobs activity
/ etc. and get rather precise counters for fs and network activity of
these privileged tasks, which is unknown otherwise.

Also hiding slabinfo and /sys/kernel/slab/* is a one step to complicate
exploitation of kernel heap overflows (and possibly, other bugs).  The
related discussion:

http://thread.gmane.org/gmane.linux.kernel/1108378

To keep compatibility with old permission model where non-root
monitoring daemon could watch for kernel memleaks though slabinfo one
should do:

    groupadd slabinfo
    usermod -a -G slabinfo $MONITOR_USER

And add the following commands to init scripts (to mountall.conf in
Ubuntu's upstart case):

    chmod g+r /proc/slabinfo /sys/kernel/slab/*/*
    chgrp slabinfo /proc/slabinfo /sys/kernel/slab/*/*

Signed-off-by: Vasiliy Kulikov 
Reviewed-by: Kees Cook 
Reviewed-by: Dave Hansen 
Acked-by: Christoph Lameter 
Acked-by: David Rientjes 
CC: Valdis.Kletnieks@vt.edu
CC: Linus Torvalds 
CC: Alan Cox 
Signed-off-by: Pekka Enberg

Merge branch 'slab/urgent' into slab/next

2011-09-19T14:46:07+00:00

slab, lockdep: Annotate the locks before using them

2011-08-04T08:18:00+00:00

Fernando found we hit the regular OFF_SLAB 'recursion' before we
annotate the locks, cure this.

The relevant portion of the stack-trace:

> [    0.000000]  [] rt_spin_lock+0x50/0x56
> [    0.000000]  [] __cache_free+0x43/0xc3
> [    0.000000]  [] kmem_cache_free+0x6c/0xdc
> [    0.000000]  [] slab_destroy+0x4f/0x53
> [    0.000000]  [] free_block+0x94/0xc1
> [    0.000000]  [] do_tune_cpucache+0x10b/0x2bb
> [    0.000000]  [] enable_cpucache+0x7b/0xa7
> [    0.000000]  [] kmem_cache_init_late+0x1f/0x61
> [    0.000000]  [] start_kernel+0x24c/0x363
> [    0.000000]  [] i386_start_kernel+0xa9/0xaf

Reported-by: Fernando Lopez-Lezcano 
Acked-by: Pekka Enberg 
Signed-off-by: Peter Zijlstra 
Link: http://lkml.kernel.org/r/1311888176.2617.379.camel@laptop
Signed-off-by: Ingo Molnar