linux, branch v2.6.32.33

Linux 2.6.32.33

2011-03-14T21:30:16Z

ip6ip6: autoload ip6 tunnel

2011-03-14T21:30:00Z

commit 6dfbd87a20a737641ef228230c77f4262434fa24 upstream ip6ip6: autoload ip6 tunnel Add necessary alias to autoload ip6ip6 tunnel module. Signed-off-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

net: don't allow CAP_NET_ADMIN to load non-netdev kernel modules

2011-03-14T21:30:00Z

commit 8909c9ad8ff03611c9c96c9a92656213e4bb495b upstream. Since a8f80e8ff94ecba629542d9b4b5f5a8ee3eb565c 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/203 Signed-off-by: Vasiliy Kulikov Signed-off-by: Michael Tokarev Acked-by: David S. Miller Acked-by: Kees Cook Signed-off-by: James Morris Signed-off-by: Greg Kroah-Hartman

Staging: comedi: jr3_pci: Don't ioremap too much space. Check result.

2011-03-14T21:29:59Z

commit fa5c5f4ce0c9ba03a670c640cad17e14cb35678b upstream. For the JR3/PCI cards, the size of the PCIBAR0 region depends on the number of channels. Don't try and ioremap space for 4 channels if the card has fewer channels. Also check for ioremap failure. Thanks to Anders Blomdell for input and Sami Hussein for testing. Signed-off-by: Ian Abbott Signed-off-by: Greg Kroah-Hartman

r8169: use RxFIFO overflow workaround for 8168c chipset.

2011-03-14T21:29:59Z

commit b5ba6d12bdac21bc0620a5089e0f24e362645efd upstream. I found that one of the 8168c chipsets (concretely XID 1c4000c0) starts generating RxFIFO overflow errors. The result is an infinite loop in interrupt handler as the RxFIFOOver is handled only for ...MAC_VER_11. With the workaround everything goes fine. Signed-off-by: Ivan Vecera Acked-by: Francois Romieu Cc: Hayes Signed-off-by: Greg Kroah-Hartman

nfsd: wrong index used in inner loop

2011-03-14T21:29:59Z

commit 3ec07aa9522e3d5e9d5ede7bef946756e623a0a0 upstream. Index i was already used in the outer loop Signed-off-by: Roel Kluin Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman

netfilter: nf_log: avoid oops in (un)bind with invalid nfproto values

2011-03-14T21:29:58Z

commit 9ef0298a8e5730d9a46d640014c727f3b4152870 upstream. Like many other places, we have to check that the array index is within allowed limits, or otherwise, a kernel oops and other nastiness can ensue when we access memory beyond the end of the array. [ 5954.115381] BUG: unable to handle kernel paging request at 0000004000000000 [ 5954.120014] IP: __find_logger+0x6f/0xa0 [ 5954.123979] nf_log_bind_pf+0x2b/0x70 [ 5954.123979] nfulnl_recv_config+0xc0/0x4a0 [nfnetlink_log] [ 5954.123979] nfnetlink_rcv_msg+0x12c/0x1b0 [nfnetlink] ... The problem goes back to v2.6.30-rc1~1372~1342~31 where nf_log_bind was decoupled from nf_log_register. Reported-by: Miguel Di Ciurcio Filho , via irc.freenode.net/#netfilter Signed-off-by: Jan Engelhardt Signed-off-by: Patrick McHardy Signed-off-by: Greg Kroah-Hartman

powerpc/kexec: Fix orphaned offline CPUs across kexec

2011-03-14T21:29:58Z

Commit: e8e5c2155b0035b6e04f29be67f6444bc914005b upstream When CPU hotplug is used, some CPUs may be offline at the time a kexec is performed. The subsequent kernel may expect these CPUs to be already running, and will declare them stuck. On pseries, there's also a soft-offline (cede) state that CPUs may be in; this can also cause problems as the kexeced kernel may ask RTAS if they're online -- and RTAS would say they are. The CPU will either appear stuck, or will cause a crash as we replace its cede loop beneath it. This patch kicks each present offline CPU awake before the kexec, so that none are forever lost to these assumptions in the subsequent kernel. Now, the behaviour is that all available CPUs that were offlined are now online & usable after the kexec. This mimics the behaviour of a full reboot (on which all CPUs will be restarted). Signed-off-by: Matt Evans Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Kamalesh babulal cc: Anton Blanchard Signed-off-by: Greg Kroah-Hartman

powerpc/crashdump: Do not fail on NULL pointer dereferencing

2011-03-14T21:29:57Z

commit 426b6cb478e60352a463a0d1ec75c1c9fab30b13 upstream. Signed-off-by: Maxim Uvarov Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Kamalesh babulal cc: Anton Blanchard Signed-off-by: Greg Kroah-Hartman

powerpc/kexec: Speedup kexec hash PTE tear down

2011-03-14T21:29:57Z

commit d504bed676caad29a3dba3d3727298c560628f5c upstream. Currently for kexec the PTE tear down on 1TB segment systems normally requires 3 hcalls for each PTE removal. On a machine with 32GB of memory it can take around a minute to remove all the PTEs. This optimises the path so that we only remove PTEs that are valid. It also uses the read 4 PTEs at once HCALL. For the common case where a PTEs is invalid in a 1TB segment, this turns the 3 HCALLs per PTE down to 1 HCALL per 4 PTEs. This gives an > 10x speedup in kexec times on PHYP, taking a 32GB machine from around 1 minute down to a few seconds. Signed-off-by: Michael Neuling Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Kamalesh babulal cc: Anton Blanchard Signed-off-by: Greg Kroah-Hartman