1. 27 Mar, 2011 10 commits
    • Kees Cook's avatar
      proc: protect mm start_code/end_code in /proc/pid/stat · 56df433e
      Kees Cook authored
      commit 5883f57c upstream.
      
      While mm->start_stack was protected from cross-uid viewing (commit
      f83ce3e6 ("proc: avoid information leaks to non-privileged
      processes")), the start_code and end_code values were not.  This would
      allow the text location of a PIE binary to leak, defeating ASLR.
      
      Note that the value "1" is used instead of "0" for a protected value since
      "ps", "killall", and likely other readers of /proc/pid/stat, take
      start_code of "0" to mean a kernel thread and will misbehave.  Thanks to
      Brad Spengler for pointing this out.
      
      Addresses CVE-2011-0726
      Signed-off-by: default avatarKees Cook <kees.cook@canonical.com>
      Cc: Alexey Dobriyan <adobriyan@gmail.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Eugene Teo <eugeneteo@kernel.sg>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Brad Spengler <spender@grsecurity.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      56df433e
    • Aaro Koskinen's avatar
      procfs: fix /proc/<pid>/maps heap check · 513d4681
      Aaro Koskinen authored
      commit 0db0c01b upstream.
      
      The current code fails to print the "[heap]" marking if the heap is split
      into multiple mappings.
      
      Fix the check so that the marking is displayed in all possible cases:
      	1. vma matches exactly the heap
      	2. the heap vma is merged e.g. with bss
      	3. the heap vma is splitted e.g. due to locked pages
      
      Test cases. In all cases, the process should have mapping(s) with
      [heap] marking:
      
      	(1) vma matches exactly the heap
      
      	#include <stdio.h>
      	#include <unistd.h>
      	#include <sys/types.h>
      
      	int main (void)
      	{
      		if (sbrk(4096) != (void *)-1) {
      			printf("check /proc/%d/maps\n", (int)getpid());
      			while (1)
      				sleep(1);
      		}
      		return 0;
      	}
      
      	# ./test1
      	check /proc/553/maps
      	[1] + Stopped                    ./test1
      	# cat /proc/553/maps | head -4
      	00008000-00009000 r-xp 00000000 01:00 3113640    /test1
      	00010000-00011000 rw-p 00000000 01:00 3113640    /test1
      	00011000-00012000 rw-p 00000000 00:00 0          [heap]
      	4006f000-40070000 rw-p 00000000 00:00 0
      
      	(2) the heap vma is merged
      
      	#include <stdio.h>
      	#include <unistd.h>
      	#include <sys/types.h>
      
      	char foo[4096] = "foo";
      	char bar[4096];
      
      	int main (void)
      	{
      		if (sbrk(4096) != (void *)-1) {
      			printf("check /proc/%d/maps\n", (int)getpid());
      			while (1)
      				sleep(1);
      		}
      		return 0;
      	}
      
      	# ./test2
      	check /proc/556/maps
      	[2] + Stopped                    ./test2
      	# cat /proc/556/maps | head -4
      	00008000-00009000 r-xp 00000000 01:00 3116312    /test2
      	00010000-00012000 rw-p 00000000 01:00 3116312    /test2
      	00012000-00014000 rw-p 00000000 00:00 0          [heap]
      	4004a000-4004b000 rw-p 00000000 00:00 0
      
      	(3) the heap vma is splitted (this fails without the patch)
      
      	#include <stdio.h>
      	#include <unistd.h>
      	#include <sys/mman.h>
      	#include <sys/types.h>
      
      	int main (void)
      	{
      		if ((sbrk(4096) != (void *)-1) && !mlockall(MCL_FUTURE) &&
      		    (sbrk(4096) != (void *)-1)) {
      			printf("check /proc/%d/maps\n", (int)getpid());
      			while (1)
      				sleep(1);
      		}
      		return 0;
      	}
      
      	# ./test3
      	check /proc/559/maps
      	[1] + Stopped                    ./test3
      	# cat /proc/559/maps|head -4
      	00008000-00009000 r-xp 00000000 01:00 3119108    /test3
      	00010000-00011000 rw-p 00000000 01:00 3119108    /test3
      	00011000-00012000 rw-p 00000000 00:00 0          [heap]
      	00012000-00013000 rw-p 00000000 00:00 0          [heap]
      
      It looks like the bug has been there forever, and since it only results in
      some information missing from a procfile, it does not fulfil the -stable
      "critical issue" criteria.
      Signed-off-by: default avatarAaro Koskinen <aaro.koskinen@nokia.com>
      Reviewed-by: default avatarKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      513d4681
    • Amir Goldstein's avatar
      ext3: skip orphan cleanup on rocompat fs · c279e36a
      Amir Goldstein authored
      commit ce654b37 upstream.
      
      Orphan cleanup is currently executed even if the file system has some
      number of unknown ROCOMPAT features, which deletes inodes and frees
      blocks, which could be very bad for some RO_COMPAT features.
      
      This patch skips the orphan cleanup if it contains readonly compatible
      features not known by this ext3 implementation, which would prevent
      the fs from being mounted (or remounted) readwrite.
      Signed-off-by: default avatarAmir Goldstein <amir73il@users.sf.net>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      c279e36a
    • Julien Tinnes's avatar
      Prevent rt_sigqueueinfo and rt_tgsigqueueinfo from spoofing the signal code · 62a9fca6
      Julien Tinnes authored
      commit da48524e upstream.
      
      Userland should be able to trust the pid and uid of the sender of a
      signal if the si_code is SI_TKILL.
      
      Unfortunately, the kernel has historically allowed sigqueueinfo() to
      send any si_code at all (as long as it was negative - to distinguish it
      from kernel-generated signals like SIGILL etc), so it could spoof a
      SI_TKILL with incorrect siginfo values.
      
      Happily, it looks like glibc has always set si_code to the appropriate
      SI_QUEUE, so there are probably no actual user code that ever uses
      anything but the appropriate SI_QUEUE flag.
      
      So just tighten the check for si_code (we used to allow any negative
      value), and add a (one-time) warning in case there are binaries out
      there that might depend on using other si_code values.
      Signed-off-by: default avatarJulien Tinnes <jln@google.com>
      Acked-by: default avatarOleg Nesterov <oleg@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      62a9fca6
    • Michal Schmidt's avatar
      PCI: return correct value when writing to the "reset" attribute · e2ecd6d8
      Michal Schmidt authored
      commit 447c5dd7 upstream.
      
      A successful write() to the "reset" sysfs attribute should return the
      number of bytes written, not 0. Otherwise userspace (bash) retries the
      write over and over again.
      Acked-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: default avatarMichal Schmidt <mschmidt@redhat.com>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      e2ecd6d8
    • Yinghai Lu's avatar
      x86: Cleanup highmap after brk is concluded · 75a98202
      Yinghai Lu authored
      commit e5f15b45 upstream.
      
      Now cleanup_highmap actually is in two steps: one is early in head64.c
      and only clears above _end; a second one is in init_memory_mapping() and
      tries to clean from _brk_end to _end.
      It should check if those boundaries are PMD_SIZE aligned but currently
      does not.
      Also init_memory_mapping() is called several times for numa or memory
      hotplug, so we really should not handle initial kernel mappings there.
      
      This patch moves cleanup_highmap() down after _brk_end is settled so
      we can do everything in one step.
      Also we honor max_pfn_mapped in the implementation of cleanup_highmap.
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      Signed-off-by: default avatarStefano Stabellini <stefano.stabellini@eu.citrix.com>
      LKML-Reference: <alpine.DEB.2.00.1103171739050.3382@kaball-desktop>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      75a98202
    • Stefano Stabellini's avatar
      xen: set max_pfn_mapped to the last pfn mapped · 856460aa
      Stefano Stabellini authored
      commit 14988a4d upstream.
      
      Do not set max_pfn_mapped to the end of the initial memory mappings,
      that also contain pages that don't belong in pfn space (like the mfn
      list).
      
      Set max_pfn_mapped to the last real pfn mapped in the initial memory
      mappings that is the pfn backing _end.
      Signed-off-by: default avatarStefano Stabellini <stefano.stabellini@eu.citrix.com>
      Acked-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      LKML-Reference: <alpine.DEB.2.00.1103171739050.3382@kaball-desktop>
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      856460aa
    • Stefano Stabellini's avatar
      PCI hotplug: acpiphp: set current_state to D0 in register_slot · 8f2056b1
      Stefano Stabellini authored
      commit 47e9037a upstream.
      
      If a device doesn't support power management (pm_cap == 0) but it is
      acpi_pci_power_manageable() because there is a _PS0 method declared for
      it and _EJ0 is also declared for the slot then nobody is going to set
      current_state = PCI_D0 for this device.  This is what I think it is
      happening:
      
      pci_enable_device
          |
      __pci_enable_device_flags
      /* here we do not set current_state because !pm_cap */
          |
      do_pci_enable_device
          |
      pci_set_power_state
          |
      __pci_start_power_transition
          |
      pci_platform_power_transition
      /* platform_pci_power_manageable() calls acpi_pci_power_manageable that
       * returns true */
          |
      platform_pci_set_power_state
      /* acpi_pci_set_power_state gets called and does nothing because the
       * acpi device has _EJ0, see the comment "If the ACPI device has _EJ0,
       * ignore the device" */
      
      at this point if we refer to the commit message that introduced the
      comment above (10b3dcae), it is up to
      the hotplug driver to set the state to D0.
      However AFAICT the pci hotplug driver never does, in fact
      drivers/pci/hotplug/acpiphp_glue.c:register_slot sets the slot flags to
      (SLOT_ENABLED | SLOT_POWEREDON) but it does not set the pci device
      current state to PCI_D0.
      
      So my proposed fix is also to set current_state = PCI_D0 in
      register_slot.
      Comments are very welcome.
      Signed-off-by: default avatarStefano Stabellini <stefano.stabellini@eu.citrix.com>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      8f2056b1
    • Hugh Dickins's avatar
      shmem: let shared anonymous be nonlinear again · c2234bf9
      Hugh Dickins authored
      commit bee4c36a upstream.
      
      Up to 2.6.22, you could use remap_file_pages(2) on a tmpfs file or a
      shared mapping of /dev/zero or a shared anonymous mapping.  In 2.6.23 we
      disabled it by default, but set VM_CAN_NONLINEAR to enable it on safe
      mappings.  We made sure to set it in shmem_mmap() for tmpfs files, but
      missed it in shmem_zero_setup() for the others.  Fix that at last.
      Reported-by: default avatarKenny Simpson <theonetruekenny@yahoo.com>
      Signed-off-by: default avatarHugh Dickins <hughd@google.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      c2234bf9
    • Roland Dreier's avatar
      aio: wake all waiters when destroying ctx · 5b390b74
      Roland Dreier authored
      commit e91f90bb upstream.
      
      The test program below will hang because io_getevents() uses
      add_wait_queue_exclusive(), which means the wake_up() in io_destroy() only
      wakes up one of the threads.  Fix this by using wake_up_all() in the aio
      code paths where we want to make sure no one gets stuck.
      
      	// t.c -- compile with gcc -lpthread -laio t.c
      
      	#include <libaio.h>
      	#include <pthread.h>
      	#include <stdio.h>
      	#include <unistd.h>
      
      	static const int nthr = 2;
      
      	void *getev(void *ctx)
      	{
      		struct io_event ev;
      		io_getevents(ctx, 1, 1, &ev, NULL);
      		printf("io_getevents returned\n");
      		return NULL;
      	}
      
      	int main(int argc, char *argv[])
      	{
      		io_context_t ctx = 0;
      		pthread_t thread[nthr];
      		int i;
      
      		io_setup(1024, &ctx);
      
      		for (i = 0; i < nthr; ++i)
      			pthread_create(&thread[i], NULL, getev, ctx);
      
      		sleep(1);
      
      		io_destroy(ctx);
      
      		for (i = 0; i < nthr; ++i)
      			pthread_join(thread[i], NULL);
      
      		return 0;
      	}
      Signed-off-by: default avatarRoland Dreier <roland@purestorage.com>
      Reviewed-by: default avatarJeff Moyer <jmoyer@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      5b390b74
  2. 24 Mar, 2011 2 commits
  3. 23 Mar, 2011 28 commits