commit 89f5bcae3a7b0c6c42d77d275a343bcf4cf98c0b Author: Greg Kroah-Hartman Date: Thu Oct 28 21:04:39 2010 -0700 Linux 2.6.27.55 commit 358b1c7959f05070c270c00bf2b1bcba8eb4b6b5 Author: Roland McGrath Date: Tue Sep 7 19:37:06 2010 -0700 execve: make responsive to SIGKILL with large arguments commit 9aea5a65aa7a1af9a4236dfaeb0088f1624f9919 upstream. An execve with a very large total of argument/environment strings can take a really long time in the execve system call. It runs uninterruptibly to count and copy all the strings. This change makes it abort the exec quickly if sent a SIGKILL. Note that this is the conservative change, to interrupt only for SIGKILL, by using fatal_signal_pending(). It would be perfectly correct semantics to let any signal interrupt the string-copying in execve, i.e. use signal_pending() instead of fatal_signal_pending(). We'll save that change for later, since it could have user-visible consequences, such as having a timer set too quickly make it so that an execve can never complete, though it always happened to work before. Signed-off-by: Roland McGrath Reviewed-by: KOSAKI Motohiro Cc: Chuck Ebbert Signed-off-by: Linus Torvalds commit 7a6c02774aa7ff340d3b69c941ccd2ec2b3bbd73 Author: Roland McGrath Date: Tue Sep 7 19:36:28 2010 -0700 execve: improve interactivity with large arguments commit 7993bc1f4663c0db67bb8f0d98e6678145b387cd upstream. This adds a preemption point during the copying of the argument and environment strings for execve, in copy_strings(). There is already a preemption point in the count() loop, so this doesn't add any new points in the abstract sense. When the total argument+environment strings are very large, the time spent copying them can be much more than a normal user time slice. So this change improves the interactivity of the rest of the system when one process is doing an execve with very large arguments. Signed-off-by: Roland McGrath Reviewed-by: KOSAKI Motohiro Signed-off-by: Linus Torvalds Cc: Chuck Ebbert Signed-off-by: Greg Kroah-Hartman commit a32489590e52abc4bc98ede852b80970ff71c3c3 Author: Roland McGrath Date: Tue Sep 7 19:35:49 2010 -0700 setup_arg_pages: diagnose excessive argument size commit 1b528181b2ffa14721fb28ad1bd539fe1732c583 upstream. The CONFIG_STACK_GROWSDOWN variant of setup_arg_pages() does not check the size of the argument/environment area on the stack. When it is unworkably large, shift_arg_pages() hits its BUG_ON. This is exploitable with a very large RLIMIT_STACK limit, to create a crash pretty easily. Check that the initial stack is not too large to make it possible to map in any executable. We're not checking that the actual executable (or intepreter, for binfmt_elf) will fit. So those mappings might clobber part of the initial stack mapping. But that is just userland lossage that userland made happen, not a kernel problem. Signed-off-by: Roland McGrath Reviewed-by: KOSAKI Motohiro Signed-off-by: Linus Torvalds Cc: Chuck Ebbert Signed-off-by: Greg Kroah-Hartman commit 1ebafa01d2a80da61e43a77e7c245c1ca19eb381 Author: Paul Fertser Date: Mon Oct 11 15:45:35 2010 -0700 b44: fix carrier detection on bind commit bcf64aa379fcadd074449cbf0c049da70071b06f upstream. For carrier detection to work properly when binding the driver with a cable unplugged, netif_carrier_off() should be called after register_netdev(), not before. Signed-off-by: Paul Fertser Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e98637ef0ae4b186afa5d30ad268f4b2ef674462 Author: Michael Neuling Date: Wed Aug 25 21:04:25 2010 +0000 powerpc: Don't use kernel stack with translation off commit 54a834043314c257210db2a9d59f8cc605571639 upstream. In f761622e59433130bc33ad086ce219feee9eb961 we changed early_setup_secondary so it's called using the proper kernel stack rather than the emergency one. Unfortunately, this stack pointer can't be used when translation is off on PHYP as this stack pointer might be outside the RMO. This results in the following on all non zero cpus: cpu 0x1: Vector: 300 (Data Access) at [c00000001639fd10] pc: 000000000001c50c lr: 000000000000821c sp: c00000001639ff90 msr: 8000000000001000 dar: c00000001639ffa0 dsisr: 42000000 current = 0xc000000016393540 paca = 0xc000000006e00200 pid = 0, comm = swapper The original patch was only tested on bare metal system, so it never caught this problem. This changes __secondary_start so that we calculate the new stack pointer but only start using it after we've called early_setup_secondary. With this patch, the above problem goes away. Signed-off-by: Michael Neuling Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 9bf670e5d364c43c7d918645533912e03676c17e Author: Matt Evans Date: Thu Aug 12 20:58:28 2010 +0000 powerpc: Initialise paca->kstack before early_setup_secondary commit f761622e59433130bc33ad086ce219feee9eb961 upstream. As early setup calls down to slb_initialize(), we must have kstack initialised before checking "should we add a bolted SLB entry for our kstack?" Failing to do so means stack access requires an SLB miss exception to refill an entry dynamically, if the stack isn't accessible via SLB(0) (kernel text & static data). It's not always allowable to take such a miss, and intermittent crashes will result. Primary CPUs don't have this issue; an SLB entry is not bolted for their stack anyway (as that lives within SLB(0)). This patch therefore only affects the init of secondaries. Signed-off-by: Matt Evans Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit c52425062aebe084f6c7893bf7a153f403ce910b Author: Ben Hutchings Date: Fri Oct 15 04:36:53 2010 +0100 r6040: Fix multicast list iteration when hash filter is used This was fixed in mainline by the interface change made in commit f9dcbcc9e338d08c0f7de7eba4eaafbbb7f81249. After walking the multicast list to set up the hash filter, this function will walk off the end of the list when filling the exact-match entries. This was fixed in mainline by the interface change made in commit f9dcbcc9e338d08c0f7de7eba4eaafbbb7f81249. Reported-by: spamalot@hispeed.ch Reference: https://bugzilla.kernel.org/show_bug.cgi?id=15355 Reported-by: Jason Heeris Reference: http://bugs.debian.org/600155 Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit 1ad2b6fea2210ab7ddd3e9e48dfad01ce8e84a11 Author: Florian Fainelli Date: Wed Apr 7 16:50:58 2010 -0700 r6040: fix r6040_multicast_list commit 3bcf8229a8c49769e48d3e0bd1e20d8e003f8106 upstream. As reported in , r6040_ multicast_list currently crashes. This is due a wrong maximum of multicast entries. This patch fixes the following issues with multicast: - number of maximum entries if off-by-one (4 instead of 3) - the writing of the hash table index is not necessary and leads to invalid values being written into the MCR1 register, so the MAC is simply put in a non coherent state - when we exceed the maximum number of mutlticast address, writing the broadcast address should be done in registers MID_1{L,M,H} instead of MID_O{L,M,H}, otherwise we would loose the adapter's MAC address [bwh: Adjust for 2.6.32; should also apply to 2.6.27] Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit 41ace54c2c2f787f1c44f43403606cb60d63cb14 Author: FUJITA Tomonori Date: Fri Sep 17 00:46:42 2010 +0900 bsg: fix incorrect device_status value commit 478971600e47cb83ff2d3c63c5c24f2b04b0d6a1 upstream. bsg incorrectly returns sg's masked_status value for device_status. [jejb: fix up expression logic] Reported-by: Douglas Gilbert Signed-off-by: FUJITA Tomonori Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 8f371eacfd1eeb533db448ed1022e971fd176d10 Author: Luca Tettamanti Date: Wed Sep 22 10:41:58 2010 +0000 atl1: fix resume commit ec5a32f67c603b11d68eb283d94eb89a4f6cfce1 upstream. adapter->cmb.cmb is initialized when the device is opened and freed when it's closed. Accessing it unconditionally during resume results either in a crash (NULL pointer dereference, when the interface has not been opened yet) or data corruption (when the interface has been used and brought down adapter->cmb.cmb points to a deallocated memory area). Signed-off-by: Luca Tettamanti Acked-by: Chris Snook Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 45d787b8a946313b73e8a8fc5d501c9aea3d8847 Author: Johannes Berg Date: Fri Sep 17 00:38:25 2010 +0200 wext: fix potential private ioctl memory content leak commit df6d02300f7c2fbd0fbe626d819c8e5237d72c62 upstream. When a driver doesn't fill the entire buffer, old heap contents may remain, and if it also doesn't update the length properly, this old heap content will be copied back to userspace. It is very unlikely that this happens in any of the drivers using private ioctls since it would show up as junk being reported by iwpriv, but it seems better to be safe here, so use kzalloc. Reported-by: Jeff Mahoney Signed-off-by: Johannes Berg Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 1aa14af44cc76d3e38ed4a0b321cab7323a59452 Author: Simon Guinot Date: Fri Sep 17 23:33:51 2010 +0200 dmaengine: fix interrupt clearing for mv_xor commit cc60f8878eab892c03d06b10f389232b9b66bd83 upstream. When using simultaneously the two DMA channels on a same engine, some transfers are never completed. For example, an endless lock can occur while writing heavily on a RAID5 array (with async-tx offload support enabled). Note that this issue can also be reproduced by using the DMA test client. On a same engine, the interrupt cause register is shared between two DMA channels. This patch make sure that the cause bit is only cleared for the requested channel. Signed-off-by: Simon Guinot Tested-by: Luc Saillard Acked-by: saeed bishara Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit 0243e39b20b13072a9e16e615316859c4c6c7600 Author: Linus Torvalds Date: Fri Oct 15 11:12:38 2010 -0700 v4l1: fix 32-bit compat microcode loading translation commit 3e645d6b485446c54c6745c5e2cf5c528fe4deec upstream. The compat code for the VIDIOCSMICROCODE ioctl is totally buggered. It's only used by the VIDEO_STRADIS driver, and that one is scheduled to staging and eventually removed unless somebody steps up to maintain it (at which point it should use request_firmware() rather than some magic ioctl). So we'll get rid of it eventually. But in the meantime, the compatibility ioctl code is broken, and this tries to get it to at least limp along (even if Mauro suggested just deleting it entirely, which may be the right thing to do - I don't think the compatibility translation code has ever worked unless you were very lucky). Reported-by: Kees Cook Cc: Mauro Carvalho Chehab Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 56b40aa2ea3788e9b8f8411868f0f35a6f8a14cf Author: Dan Rosenberg Date: Tue Sep 28 14:18:20 2010 -0400 ALSA: prevent heap corruption in snd_ctl_new() commit 5591bf07225523600450edd9e6ad258bb877b779 upstream. The snd_ctl_new() function in sound/core/control.c allocates space for a snd_kcontrol struct by performing arithmetic operations on a user-provided size without checking for integer overflow. If a user provides a large enough size, an overflow will occur, the allocated chunk will be too small, and a second user-influenced value will be written repeatedly past the bounds of this chunk. This code is reachable by unprivileged users who have permission to open a /dev/snd/controlC* device (on many distros, this is group "audio") via the SNDRV_CTL_IOCTL_ELEM_ADD and SNDRV_CTL_IOCTL_ELEM_REPLACE ioctls. Signed-off-by: Dan Rosenberg Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 7b1178dc25f59d6f61dc87853d164e8ec87eba25 Author: Dan Rosenberg Date: Sat Sep 25 11:07:27 2010 -0400 ALSA: sound/pci/rme9652: prevent reading uninitialized stack memory commit e68d3b316ab7b02a074edc4f770e6a746390cb7d upstream. The SNDRV_HDSP_IOCTL_GET_CONFIG_INFO and SNDRV_HDSP_IOCTL_GET_CONFIG_INFO ioctls in hdspm.c and hdsp.c allow unprivileged users to read uninitialized kernel stack memory, because several fields of the hdsp{m}_config_info structs declared on the stack are not altered or zeroed before being copied back to the user. This patch takes care of it. Signed-off-by: Dan Rosenberg Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 207988da56b71bb6882f19c925b40e8349374e2e Author: Luck, Tony Date: Tue Aug 24 11:44:18 2010 -0700 guard page for stacks that grow upwards commit 8ca3eb08097f6839b2206e2242db4179aee3cfb3 upstream. pa-risc and ia64 have stacks that grow upwards. Check that they do not run into other mappings. By making VM_GROWSUP 0x0 on architectures that do not ever use it, we can avoid some unpleasant #ifdefs in check_stack_guard_page(). Signed-off-by: Tony Luck Signed-off-by: Linus Torvalds Cc: dann frazier Signed-off-by: Greg Kroah-Hartman commit 5f2a867eb3cb6558cf82c96b56d52260a276111d Author: Jeff Moyer Date: Fri Sep 10 14:16:00 2010 -0700 aio: check for multiplication overflow in do_io_submit commit 75e1c70fc31490ef8a373ea2a4bea2524099b478 upstream. Tavis Ormandy pointed out that do_io_submit does not do proper bounds checking on the passed-in iocb array:        if (unlikely(nr < 0))                return -EINVAL;        if (unlikely(!access_ok(VERIFY_READ, iocbpp, (nr*sizeof(iocbpp)))))                return -EFAULT;                      ^^^^^^^^^^^^^^^^^^ The attached patch checks for overflow, and if it is detected, the number of iocbs submitted is scaled down to a number that will fit in the long.  This is an ok thing to do, as sys_io_submit is documented as returning the number of iocbs submitted, so callers should handle a return value of less than the 'nr' argument passed in. Reported-by: Tavis Ormandy Signed-off-by: Jeff Moyer Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman