1. 14 Mar, 2011 11 commits
  2. 10 Mar, 2011 26 commits
  3. 09 Mar, 2011 3 commits
    • Vasiliy Kulikov's avatar
      net: don't allow CAP_NET_ADMIN to load non-netdev kernel modules · 8909c9ad
      Vasiliy Kulikov authored
      Since a8f80e8f any process with
      CAP_NET_ADMIN may load any module from /lib/modules/.  This doesn't mean
      that CAP_NET_ADMIN is a superset of CAP_SYS_MODULE as modules are
      limited to /lib/modules/**.  However, CAP_NET_ADMIN capability shouldn't
      allow anybody load any module not related to networking.
      
      This patch restricts an ability of autoloading modules to netdev modules
      with explicit aliases.  This fixes CVE-2011-1019.
      
      Arnd Bergmann suggested to leave untouched the old pre-v2.6.32 behavior
      of loading netdev modules by name (without any prefix) for processes
      with CAP_SYS_MODULE to maintain the compatibility with network scripts
      that use autoloading netdev modules by aliases like "eth0", "wlan0".
      
      Currently there are only three users of the feature in the upstream
      kernel: ipip, ip_gre and sit.
      
          root@albatros:~# capsh --drop=$(seq -s, 0 11),$(seq -s, 13 34) --
          root@albatros:~# grep Cap /proc/$$/status
          CapInh:	0000000000000000
          CapPrm:	fffffff800001000
          CapEff:	fffffff800001000
          CapBnd:	fffffff800001000
          root@albatros:~# modprobe xfs
          FATAL: Error inserting xfs
          (/lib/modules/2.6.38-rc6-00001-g2bf4ca3/kernel/fs/xfs/xfs.ko): Operation not permitted
          root@albatros:~# lsmod | grep xfs
          root@albatros:~# ifconfig xfs
          xfs: error fetching interface information: Device not found
          root@albatros:~# lsmod | grep xfs
          root@albatros:~# lsmod | grep sit
          root@albatros:~# ifconfig sit
          sit: error fetching interface information: Device not found
          root@albatros:~# lsmod | grep sit
          root@albatros:~# ifconfig sit0
          sit0      Link encap:IPv6-in-IPv4
      	      NOARP  MTU:1480  Metric:1
      
          root@albatros:~# lsmod | grep sit
          sit                    10457  0
          tunnel4                 2957  1 sit
      
      For CAP_SYS_MODULE module loading is still relaxed:
      
          root@albatros:~# grep Cap /proc/$$/status
          CapInh:	0000000000000000
          CapPrm:	ffffffffffffffff
          CapEff:	ffffffffffffffff
          CapBnd:	ffffffffffffffff
          root@albatros:~# ifconfig xfs
          xfs: error fetching interface information: Device not found
          root@albatros:~# lsmod | grep xfs
          xfs                   745319  0
      
      Reference: https://lkml.org/lkml/2011/2/24/203Signed-off-by: default avatarVasiliy Kulikov <segoon@openwall.com>
      Signed-off-by: default avatarMichael Tokarev <mjt@tls.msk.ru>
      Acked-by: default avatarDavid S. Miller <davem@davemloft.net>
      Acked-by: default avatarKees Cook <kees.cook@canonical.com>
      Signed-off-by: default avatarJames Morris <jmorris@namei.org>
      8909c9ad
    • Benjamin Herrenschmidt's avatar
      powerpc/pseries: Disable VPNH feature · 36e8695c
      Benjamin Herrenschmidt authored
      This feature triggers nasty races in the scheduler between the
      rebuilding of the topology and the load balancing code, causing
      the machine to hang.
      
      Disable it for now until the races are fixed.
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      36e8695c
    • Benjamin Herrenschmidt's avatar
      powerpc/iseries: Fix early init access to lppaca · f2f6dad6
      Benjamin Herrenschmidt authored
      The combination of commit
      
      8154c5d2 and
      93c22703
      
      Broke boot on iSeries.
      
      The problem is that iSeries very early boot code, which generates
      the device-tree and runs before our normal early initializations
      does need access the lppaca's very early, before the PACA array is
      initialized, and in fact even before the boot PACA has been
      initialized (it contains all 0's at this stage).
      
      However, the first patch above makes that code use the new
      llpaca_of(cpu) accessor, which itself is changed by the second patch to
      use the PACA array.
      
      We fix that by reverting iSeries to directly dereferencing the array. In
      addition, we fix all iterators in the iSeries code to always skip CPU
      whose number is above 63 which is the maximum size of that array and
      the maximum number of supported CPUs on these machines.
      
      Additionally, we make sure the boot_paca is properly initialized
      in our early startup code.
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      f2f6dad6