linux.git/mm/slub.c, branch v3.2

slub: avoid potential NULL dereference or corruption

2011-11-24T06:44:19+00:00

show_slab_objects() can trigger NULL dereferences or memory corruption.

Another cpu can change its c->page to NULL or c->node to NUMA_NO_NODE
while we use them.

Use ACCESS_ONCE(c->page) and ACCESS_ONCE(c->node) to make sure this
cannot happen.

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

slub: use irqsafe_cpu_cmpxchg for put_cpu_partial

2011-11-24T06:44:14+00:00

The cmpxchg must be irq safe. The fallback for this_cpu_cmpxchg only
disables preemption which results in per cpu partial page operation
potentially failing on non x86 platforms.

This patch fixes the following problem reported by Christian Kujau:

  I seem to hit it with heavy disk & cpu IO is in progress on this
  PowerBook
  G4. Full dmesg & .config: http://nerdbynature.de/bits/3.2.0-rc1/oops/

  I've enabled some debug options and now it really points to slub.c:2166

    http://nerdbynature.de/bits/3.2.0-rc1/oops/oops4m.jpg

  With debug options enabled I'm currently in the xmon debugger, not sure
  what to make of it yet, I'll try to get something useful out of it :)

Reported-by: Christian Kujau 
Tested-by: Christian Kujau 
Acked-by: Eric Dumazet 
Acked-by: David Rientjes 
Signed-off-by: Christoph Lameter 
Signed-off-by: Pekka Enberg

slub: move discard_slab out of node lock

2011-11-15T18:41:00+00:00

Lockdep reports there is potential deadlock for slub node list_lock.
discard_slab() is called with the lock hold in unfreeze_partials(),
which could trigger a slab allocation, which could hold the lock again.

discard_slab() doesn't need hold the lock actually, if the slab is
already removed from partial list.

Acked-by: Christoph Lameter 
Reported-and-tested-by: Yong Zhang 
Reported-and-tested-by: Julie Sullivan 
Signed-off-by: Shaohua Li 
Signed-off-by: Pekka Enberg

slub: use correct parameter to add a page to partial list tail

2011-11-15T18:37:15+00:00

unfreeze_partials() needs add the page to partial list tail, since such page
hasn't too many free objects. We now explictly use DEACTIVATE_TO_TAIL for this,
while DEACTIVATE_TO_TAIL != 1. This will cause performance regression (eg, more
lock contention in node->list_lock) without below fix.

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

lib/string.c: introduce memchr_inv()

2011-11-01T00:30:47+00:00

memchr_inv() is mainly used to check whether the whole buffer is filled
with just a specified byte.

The function name and prototype are stolen from logfs and the
implementation is from SLUB.

Signed-off-by: Akinobu Mita 
Acked-by: Christoph Lameter 
Acked-by: Pekka Enberg 
Cc: Matt Mackall 
Acked-by: Joern Engel 
Cc: Marcin Slusarz 
Cc: Eric Dumazet 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Merge branches 'slab/next' and 'slub/partial' into slab/for-linus

2011-10-26T15:09:12+00:00

slub: Discard slab page when node partial > minimum partial number

2011-09-27T20:03:31+00:00

Discarding slab should be done when node partial > min_partial.  Otherwise,
node partial slab may eat up all memory.

Signed-off-by: Alex Shi 
Acked-by: Christoph Lameter 
Signed-off-by: Pekka Enberg

slub: correct comments error for per cpu partial

2011-09-27T20:03:30+00:00

Correct comment errors, that mistake cpu partial objects number as pages
number, may make reader misunderstand.

Signed-off-by: Alex Shi 
Reviewed-by: Christoph Lameter 
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