commit a386bf75dea7208041b5d4b8d44726876e28ee4b Author: Greg Kroah-Hartman Date: Thu Dec 9 13:29:45 2010 -0800 Linux 2.6.32.27 commit 0b9c55355f283356e7d767098ebe074f15acd021 Author: Robin Holt Date: Tue Dec 15 16:47:57 2009 -0800 x86: uv: xpc NULL deref when mesq becomes empty commit 15b87d67ff3dc042bee42f991858d6b121b3b3ca upstream. Under heavy load conditions, our set of xpc messages may become exhausted. The code handles this correctly with the exception of the management code which hits a NULL pointer dereference. Signed-off-by: Robin Holt Cc: Jack Steiner Cc: Ingo Molnar Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 48286a6e86d003d469f1ac50bb27d29cf90a8567 Author: Robin Holt Date: Tue Dec 15 16:47:58 2009 -0800 X86: uv: xpc_make_first_contact hang due to not accepting ACTIVE state commit dbd2918ec65c35f36bb102c88eafe87be0552f6f upstream. Many times while the initial connection is being made, the contacted partition will send back both the ACTIVATING and the ACTIVE remote_act_state changes in very close succescion. The 1/4 second delay in the make first contact loop is large enough to nearly always miss the ACTIVATING state change. Since either state indicates the remote partition has acknowledged our state change, accept either. Signed-off-by: Robin Holt Cc: Jack Steiner Cc: Ingo Molnar Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 68d39a688abd1509d995bb3f25aedbbefa89332c Author: Robin Holt Date: Tue Dec 15 16:47:59 2009 -0800 x86: uv: XPC receive message reuse triggers invalid BUG_ON() commit 046d6c563b1c6226bbf0f84e5b2413ad8ab921a1 upstream. This was a difficult bug to trip. XPC was in the middle of sending an acknowledgement for a received message. In xpc_received_payload_uv(): . ret = xpc_send_gru_msg(ch->sn.uv.cached_notify_gru_mq_desc, msg, sizeof(struct xpc_notify_mq_msghdr_uv)); if (ret != xpSuccess) XPC_DEACTIVATE_PARTITION(&xpc_partitions[ch->partid], ret); msg->hdr.msg_slot_number += ch->remote_nentries; at the point in xpc_send_gru_msg() where the hardware has dispatched the acknowledgement, the remote side is able to reuse the message structure and send a message with a different slot number. This problem is made worse by interrupts. The adjustment of msg_slot_number and the BUG_ON in xpc_handle_notify_mq_msg_uv() which verifies the msg_slot_number is consistent are only used for debug purposes. Since a fix for this that preserves the debug functionality would either have to infringe upon the payload or allocate another structure just for debug, I decided to remove it entirely. Signed-off-by: Robin Holt Cc: Jack Steiner Cc: Ingo Molnar Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 0bbe1f679dbdca0994346580399afcbfe41350b5 Author: Robin Holt Date: Tue Dec 15 16:48:00 2009 -0800 UV - XPC: pass nasid instead of nid to gru_create_message_queue commit 57e6d258b1e41cd7ceb26fa43ce116939d8440b1 upstream. Currently, the UV xpc code is passing nid to the gru_create_message_queue instead of nasid as it expects. Signed-off-by: Robin Holt Signed-off-by: Jack Steiner Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 0bf178002ce72557fce63c7fda7f0906fa6a5541 Author: Eric Dumazet Date: Mon Aug 16 20:04:22 2010 +0000 net sched: fix some kernel memory leaks commit 1c40be12f7d8ca1d387510d39787b12e512a7ce8 upstream. We leak at least 32bits of kernel memory to user land in tc dump, because we dont init all fields (capab ?) of the dumped structure. Use C99 initializers so that holes and non explicit fields are zeroed. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Cc: dann frazier Signed-off-by: Greg Kroah-Hartman commit 4882e6cb833cb279dd52b004da5bcbe6a5560218 Author: Changli Gao Date: Tue Jun 29 23:07:09 2010 +0000 act_nat: use stack variable commit 504f85c9d05f7c605306e808f0d835fe11bfd18d upstream. act_nat: use stack variable structure tc_nat isn't too big for stack, so we can put it in stack. Signed-off-by: Changli Gao Cc: dann frazier Signed-off-by: Greg Kroah-Hartman commit 2418be1650bb2ffcf05085c796dcc37c087812d4 Author: Heiko Carstens Date: Thu Nov 25 09:52:45 2010 +0100 nmi: fix clock comparator revalidation commit e8129c642155616d9e2160a75f103e127c8c3708 upstream. On each machine check all registers are revalidated. The save area for the clock comparator however only contains the upper most seven bytes of the former contents, if valid. Therefore the machine check handler uses a store clock instruction to get the current time and writes that to the clock comparator register which in turn will generate an immediate timer interrupt. However within the lowcore the expected time of the next timer interrupt is stored. If the interrupt happens before that time the handler won't be called. In turn the clock comparator won't be reprogrammed and therefore the interrupt condition stays pending which causes an interrupt loop until the expected time is reached. On NOHZ machines this can result in unresponsive machines since the time of the next expected interrupted can be a couple of days in the future. To fix this just revalidate the clock comparator register with the expected value. In addition the special handling for udelay must be changed as well. Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit f342cb14f58813fe972a152b5034306a08c2de70 Author: David S. Miller Date: Thu Oct 28 11:41:55 2010 -0700 net: Limit socket I/O iovec total length to INT_MAX. commit 8acfe468b0384e834a303f08ebc4953d72fb690a upstream. This helps protect us from overflow issues down in the individual protocol sendmsg/recvmsg handlers. Once we hit INT_MAX we truncate out the rest of the iovec by setting the iov_len members to zero. This works because: 1) For SOCK_STREAM and SOCK_SEQPACKET sockets, partial writes are allowed and the application will just continue with another write to send the rest of the data. 2) For datagram oriented sockets, where there must be a one-to-one correspondance between write() calls and packets on the wire, INT_MAX is going to be far larger than the packet size limit the protocol is going to check for and signal with -EMSGSIZE. Based upon a patch by Linus Torvalds. Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 3543e68e10bc6cacd30326e837a53147a1d33660 Author: Linus Torvalds Date: Sat Oct 30 16:43:10 2010 -0700 net: Truncate recvfrom and sendto length to INT_MAX. commit 253eacc070b114c2ec1f81b067d2fed7305467b0 upstream. Signed-off-by: Linus Torvalds Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 0dd472b3a508ae8ec0b7ff3396e1a17434b78a75 Author: Dan Rosenberg Date: Wed Nov 17 06:37:16 2010 +0000 rds: Integer overflow in RDS cmsg handling commit 218854af84038d828a32f061858b1902ed2beec6 upstream. In rds_cmsg_rdma_args(), the user-provided args->nr_local value is restricted to less than UINT_MAX. This seems to need a tighter upper bound, since the calculation of total iov_size can overflow, resulting in a small sock_kmalloc() allocation. This would probably just result in walking off the heap and crashing when calling rds_rdma_pages() with a high count value. If it somehow doesn't crash here, then memory corruption could occur soon after. Signed-off-by: Dan Rosenberg Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 667b9703cf420799a25d816fdfd376a00e7ca0ae Author: Phil Blundell Date: Wed Nov 24 11:49:53 2010 -0800 econet: fix CVE-2010-3850 commit 16c41745c7b92a243d0874f534c1655196c64b74 upstream. Add missing check for capable(CAP_NET_ADMIN) in SIOCSIFADDR operation. Signed-off-by: Phil Blundell Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 72013721bd096ae0bb46cec1db71d4161db32eac Author: Phil Blundell Date: Wed Nov 24 11:49:19 2010 -0800 econet: disallow NULL remote addr for sendmsg(), fixes CVE-2010-3849 commit fa0e846494792e722d817b9d3d625a4ef4896c96 upstream. Later parts of econet_sendmsg() rely on saddr != NULL, so return early with EINVAL if NULL was passed otherwise an oops may occur. Signed-off-by: Phil Blundell Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 04c54f3ac587680e7c1bb721843af4c23548faa0 Author: H. Peter Anvin Date: Wed Aug 18 11:42:23 2010 -0700 x86-32: Fix dummy trampoline-related inline stubs commit 8848a91068c018bc91f597038a0f41462a0f88a4 upstream. Fix dummy inline stubs for trampoline-related functions when no trampolines exist (until we get rid of the no-trampoline case entirely.) Signed-off-by: H. Peter Anvin Cc: Joerg Roedel Cc: Borislav Petkov LKML-Reference: <4C6C294D.3030404@zytor.com> Signed-off-by: Greg Kroah-Hartman commit af2d6dceea1d65dceeccc87ba76d5bea9f7732bd Author: Hugh Dickins Date: Tue Aug 24 22:44:12 2010 -0700 x86, mm: Fix CONFIG_VMSPLIT_1G and 2G_OPT trampoline commit b7d460897739e02f186425b7276e3fdb1595cea7 upstream. rc2 kernel crashes when booting second cpu on this CONFIG_VMSPLIT_2G_OPT laptop: whereas cloning from kernel to low mappings pgd range does need to limit by both KERNEL_PGD_PTRS and KERNEL_PGD_BOUNDARY, cloning kernel pgd range itself must not be limited by the smaller KERNEL_PGD_BOUNDARY. Signed-off-by: Hugh Dickins LKML-Reference: Signed-off-by: H. Peter Anvin Cc: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 6faa675c82698713380298a82cae5995bee4a4b7 Author: Joerg Roedel Date: Mon Aug 16 14:38:33 2010 +0200 x86-32: Separate 1:1 pagetables from swapper_pg_dir commit fd89a137924e0710078c3ae855e7cec1c43cb845 upstream. This patch fixes machine crashes which occur when heavily exercising the CPU hotplug codepaths on a 32-bit kernel. These crashes are caused by AMD Erratum 383 and result in a fatal machine check exception. Here's the scenario: 1. On 32-bit, the swapper_pg_dir page table is used as the initial page table for booting a secondary CPU. 2. To make this work, swapper_pg_dir needs a direct mapping of physical memory in it (the low mappings). By adding those low, large page (2M) mappings (PAE kernel), we create the necessary conditions for Erratum 383 to occur. 3. Other CPUs which do not participate in the off- and onlining game may use swapper_pg_dir while the low mappings are present (when leave_mm is called). For all steps below, the CPU referred to is a CPU that is using swapper_pg_dir, and not the CPU which is being onlined. 4. The presence of the low mappings in swapper_pg_dir can result in TLB entries for addresses below __PAGE_OFFSET to be established speculatively. These TLB entries are marked global and large. 5. When the CPU with such TLB entry switches to another page table, this TLB entry remains because it is global. 6. The process then generates an access to an address covered by the above TLB entry but there is a permission mismatch - the TLB entry covers a large global page not accessible to userspace. 7. Due to this permission mismatch a new 4kb, user TLB entry gets established. Further, Erratum 383 provides for a small window of time where both TLB entries are present. This results in an uncorrectable machine check exception signalling a TLB multimatch which panics the machine. There are two ways to fix this issue: 1. Always do a global TLB flush when a new cr3 is loaded and the old page table was swapper_pg_dir. I consider this a hack hard to understand and with performance implications 2. Do not use swapper_pg_dir to boot secondary CPUs like 64-bit does. This patch implements solution 2. It introduces a trampoline_pg_dir which has the same layout as swapper_pg_dir with low_mappings. This page table is used as the initial page table of the booting CPU. Later in the bringup process, it switches to swapper_pg_dir and does a global TLB flush. This fixes the crashes in our test cases. -v2: switch to swapper_pg_dir right after entering start_secondary() so that we are able to access percpu data which might not be mapped in the trampoline page table. Signed-off-by: Joerg Roedel LKML-Reference: <20100816123833.GB28147@aftab> Signed-off-by: Borislav Petkov Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit 86a48e105f8558d15df47d3a71144406337e7790 Author: Herbert Xu Date: Thu Nov 4 14:38:39 2010 -0400 crypto: padlock - Fix AES-CBC handling on odd-block-sized input commit c054a076a1bd4731820a9c4d638b13d5c9bf5935 upstream. On certain VIA chipsets AES-CBC requires the input/output to be a multiple of 64 bytes. We had a workaround for this but it was buggy as it sent the whole input for processing when it is meant to only send the initial number of blocks which makes the rest a multiple of 64 bytes. As expected this causes memory corruption whenever the workaround kicks in. Reported-by: Phil Sutter Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 73c9362424d1273be28adedbdab7f52052450ab7 Author: Dan Rosenberg Date: Fri Nov 12 12:44:42 2010 -0800 x25: Prevent crashing when parsing bad X.25 facilities commit 5ef41308f94dcbb3b7afc56cdef1c2ba53fa5d2f upstream. Now with improved comma support. On parsing malformed X.25 facilities, decrementing the remaining length may cause it to underflow. Since the length is an unsigned integer, this will result in the loop continuing until the kernel crashes. This patch adds checks to ensure decrementing the remaining length does not cause it to wrap around. Signed-off-by: Dan Rosenberg Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 7c119c7e373988b0fd80244fdcbfc7846522d1c9 Author: Dan Rosenberg Date: Wed Sep 15 18:44:22 2010 -0300 V4L/DVB: ivtvfb: prevent reading uninitialized stack memory commit 405707985594169cfd0b1d97d29fcb4b4c6f2ac9 upstream. The FBIOGET_VBLANK device ioctl allows unprivileged users to read 16 bytes of uninitialized stack memory, because the "reserved" member of the fb_vblank struct declared on the stack is 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: Andy Walls Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit e2de51a1c73d762ee1b5246053b087e295f4a7e9 Author: Oliver Hartkopp Date: Wed Nov 10 12:10:30 2010 +0000 can-bcm: fix minor heap overflow commit 0597d1b99fcfc2c0eada09a698f85ed413d4ba84 upstream. On 64-bit platforms the ASCII representation of a pointer may be up to 17 bytes long. This patch increases the length of the buffer accordingly. http://marc.info/?l=linux-netdev&m=128872251418192&w=2 Reported-by: Dan Rosenberg Signed-off-by: Oliver Hartkopp CC: Linus Torvalds Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f0c12133cff646d3ad1cb65f23c512169c85e65f Author: andrew hendry Date: Wed Nov 3 12:54:53 2010 +0000 memory corruption in X.25 facilities parsing commit a6331d6f9a4298173b413cf99a40cc86a9d92c37 upstream. Signed-of-by: Andrew Hendry Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 7281524c6476cbb85cd5156bde7c12df793bfeb3 Author: John Hughes Date: Wed Apr 7 21:29:25 2010 -0700 x25: Patch to fix bug 15678 - x25 accesses fields beyond end of packet. commit f5eb917b861828da18dc28854308068c66d1449a upstream. Here is a patch to stop X.25 examining fields beyond the end of the packet. For example, when a simple CALL ACCEPTED was received: 10 10 0f x25_parse_facilities was attempting to decode the FACILITIES field, but this packet contains no facilities field. Signed-off-by: John Hughes Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a22280783f150f3e0bd03b4124faa73d45b8af06 Author: Dmitry Torokhov Date: Thu Nov 4 09:12:44 2010 -0700 Input: i8042 - add Sony VAIO VPCZ122GX to nomux list [Note that the mainline will not have this particular fix but rather will blacklist entire VAIO line based off DMI board name. For stable I am being a bit more cautious and blacklist one particular product.] Trying to query/activate active multiplexing mode on this VAIO makes both keyboard and touchpad inoperable. Futher kernels will blacklist entire VAIO line, however here we blacklist just one particular model. Reported-by: Jesse Barnes Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 37e3dd40d5881f833b251301a59413a43edbaf60 Author: Laurent Pinchart Date: Thu Oct 8 19:38:10 2009 -0300 V4L/DVB (13154): uvcvideo: Handle garbage at the end of streaming interface descriptors commit c4ed8c66d79d707d89fe732ff5b97739edf1ba62 upstream. At least one 5986:0241 webcam model includes vendor-specific descriptors at the end of its streaming interface descriptors. Print an information UVC_TRACE_DESCR message and try to continue parsing the descriptors rather than bailing out with an error. Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit e7b55a38fac2321d115fc71dca03d13de1a216b7 Author: Luke Macken Date: Wed Sep 22 13:05:04 2010 -0700 efifb: support the EFI framebuffer on more Apple hardware commit a5757c2a474a15f87e5baa9a4caacc31cde2bae6 upstream. Enable the EFI framebuffer on 14 more Macs, including the iMac11,1 iMac10,1 iMac8,1 Macmini3,1 Macmini4,1 MacBook5,1 MacBook6,1 MacBook7,1 MacBookPro2,2 MacBookPro5,2 MacBookPro5,3 MacBookPro6,1 MacBookPro6,2 and MacBookPro7,1 Information gathered from various user submissions. https://bugzilla.redhat.com/show_bug.cgi?id=528232 http://ubuntuforums.org/showthread.php?t=1557326 [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Luke Macken Signed-off-by: Peter Jones Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit 762ecc5db31788017bd5f398e171d7a90ce6d0db Author: Thomas Gerlach Date: Fri Apr 23 13:17:50 2010 -0400 drivers/video/efifb.c: support framebuffer for NVIDIA 9400M in MacBook Pro 5,1 commit 8a3bdfe6cd841880a5d849c40f90093b3817f6e0 upstream. Description of patch: --------------------- This is a patch for the EFI framebuffer driver to enable the framebuffer of the NVIDIA 9400M as found in MacBook Pro (MBP) 5,1 and up. The framebuffer of the NVIDIA graphic cards are located at the following addresses in memory: 9400M: 0xC0010000 9600M GT: 0xB0030000 The patch delivered right here only provides the memory location of the framebuffer of the 9400M device. The 9600M GT is not covered. It is assumed that the 9400M is used when powered up the MBP. The information which device is currently powered and in use is stored in the 64 bytes large EFI variable "gpu-power-prefs". More specifically, byte 0x3B indicates whether 9600M GT (0x00) or 9400M (0x01) is online. The PCI bus IDs are the following: 9400M: PCI 03:00:00 9600M GT: PCI 02:00:00 The EFI variables can be easily read-out and manipulated with "rEFIt", an MBP specific bootloader tool. For more information on how handle rEFIt and EFI variables please consult "http://refit.sourceforge.net" and "http://ubuntuforums.org/archive/index.php/t-1076879.html". IMPORTANT NOTE: The information on how to activate the 9400M device given at "ubuntuforums.org" is not correct, since it states gpu-power-prefs[0x3B] = 0x00 -> 9400M (PCI 02:00:00) gpu-power-prefs[0x3B] = 0x01 -> 9600M GT (PCI 03:00:00) Actually, the assignment of the values and the PCI bus IDs are swapped. Suggestions: ------------ To cover framebuffers of both 9400M and 9600M GT, I would suggest to implement a conditional on "gpu-power-prefs". Depending on the value of byte 0x3B, the according framebuffer is selected. However, this requires kernel access to the EFI variables. [akpm@linux-foundation.org: rename optname, per Peter Jones] Signed-off-by: Thomas Gerlach Acked-by: Peter Jones Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit db6e20425552dfa1dccddc691e1889c0ae1902ca Author: Jack Steiner Date: Fri Sep 10 10:08:08 2010 -0500 x86, UV: Fix initialization of max_pnode commit 36ac4b987bea9a95217e1af552252f275ca7fc44 upstream. Fix calculation of "max_pnode" for systems where the the highest blade has neither cpus or memory. (And, yes, although rare this does occur). Signed-off-by: Jack Steiner LKML-Reference: <20100910150808.GA19802@sgi.com> Signed-off-by: Ingo Molnar Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit 22aa48f2b54cbf08a622421247ebc2afb97c7dbf Author: Jack Steiner Date: Wed Mar 17 10:40:38 2010 -0500 x86, UV: Delete unneeded boot messages commit 2acebe9ecb2b77876e87a1480729cfb2db4570dd upstream. SGI:UV: Delete extra boot messages that describe the system topology. These messages are no longer useful. Signed-off-by: Jack Steiner LKML-Reference: <20100317154038.GA29346@sgi.com> Signed-off-by: Ingo Molnar Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit 46d47fb2558d6aca81d7720fc590acf7a47a2425 Author: David S. Miller Date: Tue Sep 21 22:30:13 2010 -0700 sparc: Prevent no-handler signal syscall restart recursion. [ Upstream commit c27852597829128a9c9d96d79ec454a83c6b0da5 ] Explicitly clear the "in-syscall" bit when we have no signal handler and back up the program counters to back up the system call. Reported-by: Al Viro Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 2884b5043735467eb4cc6672c8b41b72bb9f9e53 Author: David S. Miller Date: Tue Sep 21 21:41:12 2010 -0700 sparc: Don't mask signal when we can't setup signal frame. [ Upstream commit 392c21802ee3aa85cee0e703105f797a8a7b9416 ] Don't invoke the signal handler tracehook in that situation either. Reported-by: Al Viro Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 9d59c97ca886608e1e18d20bbd5eab09b96af683 Author: David S. Miller Date: Mon Sep 20 23:24:52 2010 -0700 sparc64: Fix race in signal instruction flushing. [ Upstream commit 05c5e7698bdc54b3079a3517d86077f49ebcc788 ] If another cpu does a very wide munmap() on the signal frame area, it can tear down the page table hierarchy from underneath us. Borrow an idea from the 64-bit fault path's get_user_insn(), and disable cross call interrupts during the page table traversal to lock them in place while we operate. Reported-by: Al Viro Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 61690148345a4a1ccced61ad9c44862f74d947cf Author: Robin Holt Date: Wed Oct 20 02:03:37 2010 +0000 Limit sysctl_tcp_mem and sysctl_udp_mem initializers to prevent integer overflows. [ Upstream fixed this in a different way as parts of the commits: 8d987e5c7510 (net: avoid limits overflow) a9febbb4bd13 (sysctl: min/max bounds are optional) 27b3d80a7b6a (sysctl: fix min/max handling in __do_proc_doulongvec_minmax()) -DaveM ] On a 16TB x86_64 machine, sysctl_tcp_mem[2], sysctl_udp_mem[2], and sysctl_sctp_mem[2] can integer overflow. Set limit such that they are maximized without overflowing. Signed-off-by: Robin Holt To: "David S. Miller" Cc: Willy Tarreau Cc: linux-kernel@vger.kernel.org Cc: netdev@vger.kernel.org Cc: linux-sctp@vger.kernel.org Cc: Alexey Kuznetsov Cc: "Pekka Savola (ipv6)" Cc: James Morris Cc: Hideaki YOSHIFUJI Cc: Patrick McHardy Cc: Vlad Yasevich Cc: Sridhar Samudrala Signed-off-by: Greg Kroah-Hartman commit 1b881c33e3d1afde2324ee9c324a0463b0e8df8b Author: Jarek Poplawski Date: Tue Oct 19 00:06:36 2010 +0000 gianfar: Fix crashes on RX path (Was Re: [Bugme-new] [Bug 19692] New: linux-2.6.36-rc5 crash with gianfar ethernet at full line rate traffic) [ Upstream commit 0d1fe1111c667e9c713d7efc7ae468a605f236a4 ] The rx_recycle queue is global per device but can be accesed by many napi handlers at the same time, so it needs full skb_queue primitives (with locking). Otherwise, various crashes caused by broken skbs are possible. This patch resolves, at least partly, bugzilla bug 19692. (Because of some doubts that there could be still something around which is hard to reproduce my proposal is to leave this bug opened for a month.) Fixes commit: 0fd56bb5be6455d0d42241e65aed057244665e5e ("gianfar: Add support for skb recycling") Reported-by: emin ak Tested-by: emin ak Signed-off-by: Jarek Poplawski CC: Andy Fleming Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 67f6b7bedf7981edcf002a1f15344e061cc95ade Author: Antonio Ospite Date: Tue Oct 5 17:20:17 2010 +0200 HID: hidraw, fix a NULL pointer dereference in hidraw_write commit e42dee9a99a3ecd32b5c027e8f7411fb5bc11eb6 upstream. BUG: unable to handle kernel NULL pointer dereference at 0000000000000028 IP: [] hidraw_write+0x3b/0x116 [hid] [...] This is reproducible by disconnecting the device while userspace writes to dev node in a loop and doesn't check return values in order to exit the loop. Signed-off-by: Antonio Ospite Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 7cbf7431e259aa462db37fbefc146fbf2a416805 Author: Antonio Ospite Date: Tue Oct 5 17:20:16 2010 +0200 HID: hidraw, fix a NULL pointer dereference in hidraw_ioctl commit d20d5ffab92f00188f360c44c791a5ffb988247c upstream. BUG: unable to handle kernel NULL pointer dereference at 0000000000000028 IP: [] hidraw_ioctl+0xfc/0x32c [hid] [...] This is reproducible by disconnecting the device while userspace does ioctl in a loop and doesn't check return values in order to exit the loop. Signed-off-by: Antonio Ospite Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 4db5de7adfe16721d77b7658c383f65372f1560f Author: Jeff Mahoney Date: Tue Aug 31 13:21:42 2010 +0000 net sched: fix kernel leak in act_police commit 0f04cfd098fb81fded74e78ea1a1b86cc6c6c31e upstream. While reviewing commit 1c40be12f7d8ca1d387510d39787b12e512a7ce8, I audited other users of tc_action_ops->dump for information leaks. That commit covered almost all of them but act_police still had a leak. opt.limit and opt.capab aren't zeroed out before the structure is passed out. This patch uses the C99 initializers to zero everything unused out. Signed-off-by: Jeff Mahoney Acked-by: Jeff Mahoney Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 94e805453c862135b9d8b8ad31eeddc62ffb1683 Author: Larry Finger Date: Sat Nov 13 13:01:56 2010 -0600 staging: rtl8187se: Change panic to warn when RF switch turned off commit f36d83a8cb7224f45fdfa1129a616dff56479a09 upstream. This driver issues a kernel panic over conditions that do not justify such drastic action. Change these to log entries with a stack dump. This patch fixes the system crash reported in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/674285. Signed-off-by: Larry Finger Reported-and-Tested-by: Robie Basik Signed-off-by: Greg Kroah-Hartman commit 2b9e50d0460818638a84ee1ba267b765098e1808 Author: Greg Kroah-Hartman Date: Tue Nov 16 11:18:33 2010 -0800 Staging: frontier: fix up some sysfs attribute permissions commit 3bad28ec006ad6ab2bca4e5103860b75391e3c9d and 2a767fda5d0d8dcff465724dfad6ee131489b3f2 upstream merged together. They should not be writable by any user Reported-by: Linus Torvalds Cc: David Taht Signed-off-by: Greg Kroah-Hartman commit 822d9b61eb5d4a48fa4fc4b6be64b9a496c852af Author: James Jones Date: Wed Nov 24 00:21:37 2010 +0100 ARM: 6482/2: Fix find_next_zero_bit and related assembly commit 0e91ec0c06d2cd15071a6021c94840a50e6671aa upstream. The find_next_bit, find_first_bit, find_next_zero_bit and find_first_zero_bit functions were not properly clamping to the maxbit argument at the bit level. They were instead only checking maxbit at the byte level. To fix this, add a compare and a conditional move instruction to the end of the common bit-within-the- byte code used by all the functions and be sure not to clobber the maxbit argument before it is used. Reviewed-by: Nicolas Pitre Tested-by: Stephen Warren Signed-off-by: James Jones Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 72b31b6685fcb51348a1ddb4066b3757d20e18f6 Author: Will Deacon Date: Fri Nov 19 13:18:31 2010 +0100 ARM: 6489/1: thumb2: fix incorrect optimisation in usracc commit 1142b71d85894dcff1466dd6c871ea3c89e0352c upstream. Commit 8b592783 added a Thumb-2 variant of usracc which, when it is called with \rept=2, calls usraccoff once with an offset of 0 and secondly with a hard-coded offset of 4 in order to avoid incrementing the pointer again. If \inc != 4 then we will store the data to the wrong offset from \ptr. Luckily, the only caller that passes \rept=2 to this function is __clear_user so we haven't been actively corrupting user data. This patch fixes usracc to pass \inc instead of #4 to usraccoff when it is called a second time. Reported-by: Tony Thompson Acked-by: Catalin Marinas Signed-off-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit 8d5be245dde97e848d0a52340e1fecbec829eb0f Author: Pekka Enberg Date: Mon Nov 8 21:29:07 2010 +0200 perf_events: Fix perf_counter_mmap() hook in mprotect() commit 63bfd7384b119409685a17d5c58f0b56e5dc03da upstream. As pointed out by Linus, commit dab5855 ("perf_counter: Add mmap event hooks to mprotect()") is fundamentally wrong as mprotect_fixup() can free 'vma' due to merging. Fix the problem by moving perf_event_mmap() hook to mprotect_fixup(). Note: there's another successful return path from mprotect_fixup() if old flags equal to new flags. We don't, however, need to call perf_event_mmap() there because 'perf' already knows the VMA is executable. Reported-by: Dave Jones Analyzed-by: Linus Torvalds Cc: Ingo Molnar Reviewed-by: Peter Zijlstra Signed-off-by: Pekka Enberg Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 38e6b47228e9a04b90f79b91a9569d2d21288444 Author: Dan Rosenberg Date: Tue Nov 23 11:02:13 2010 +0000 DECnet: don't leak uninitialized stack byte commit 3c6f27bf33052ea6ba9d82369fb460726fb779c0 upstream. A single uninitialized padding byte is leaked to userspace. Signed-off-by: Dan Rosenberg Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a9a275749034d3e23a7ed1ea8d784f1fe5a8d064 Author: Steven J. Magnani Date: Wed Nov 24 12:56:54 2010 -0800 nommu: yield CPU while disposing VM commit 04c3496152394d17e3bc2316f9731ee3e8a026bc upstream. Depending on processor speed, page size, and the amount of memory a process is allowed to amass, cleanup of a large VM may freeze the system for many seconds. This can result in a watchdog timeout. Make sure other tasks receive some service when cleaning up large VMs. Signed-off-by: Steven J. Magnani Cc: Greg Ungerer Reviewed-by: KOSAKI Motohiro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit a9386a4f6cf9c1b72862ac0aa4ffe02a22c1bd5b Author: Uwe Kleine-König Date: Wed Nov 24 12:57:14 2010 -0800 backlight: grab ops_lock before testing bd->ops commit d1d73578e053b981c3611e5a211534290d24a5eb upstream. According to the comment describing ops_lock in the definition of struct backlight_device and when comparing with other functions in backlight.c the mutex must be hold when checking ops to be non-NULL. Fixes a problem added by c835ee7f4154992e6 ("backlight: Add suspend/resume support to the backlight core") in Jan 2009. Signed-off-by: Uwe Kleine-König Acked-by: Richard Purdie Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 20fa2a2005e86e5628941c5e23fbc4682824473e Author: Will Newton Date: Wed Nov 24 12:56:55 2010 -0800 uml: disable winch irq before freeing handler data commit 69e83dad5207f8f03c9699e57e1febb114383cb8 upstream. Disable the winch irq early to make sure we don't take an interrupt part way through the freeing of the handler data, resulting in a crash on shutdown: winch_interrupt : read failed, errno = 9 fd 13 is losing SIGWINCH support ------------[ cut here ]------------ WARNING: at lib/list_debug.c:48 list_del+0xc6/0x100() list_del corruption, next is LIST_POISON1 (00100100) 082578c8: [<081fd77f>] dump_stack+0x22/0x24 082578e0: [<0807a18a>] warn_slowpath_common+0x5a/0x80 08257908: [<0807a23e>] warn_slowpath_fmt+0x2e/0x30 08257920: [<08172196>] list_del+0xc6/0x100 08257940: [<08060244>] free_winch+0x14/0x80 08257958: [<080606fb>] winch_interrupt+0xdb/0xe0 08257978: [<080a65b5>] handle_IRQ_event+0x35/0xe0 08257998: [<080a8717>] handle_edge_irq+0xb7/0x170 082579bc: [<08059bc4>] do_IRQ+0x34/0x50 082579d4: [<08059e1b>] sigio_handler+0x5b/0x80 082579ec: [<0806a374>] sig_handler_common+0x44/0xb0 08257a68: [<0806a538>] sig_handler+0x38/0x50 08257a78: [<0806a77c>] handle_signal+0x5c/0xa0 08257a9c: [<0806be28>] hard_handler+0x18/0x20 08257aac: [<00c14400>] 0xc14400 Signed-off-by: Will Newton Acked-by: WANG Cong Cc: Jeff Dike Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit b5846f22eb37334d9f0e90d146285adca4830dba Author: Nelson Elhage Date: Thu Dec 2 14:31:21 2010 -0800 do_exit(): make sure that we run with get_fs() == USER_DS commit 33dd94ae1ccbfb7bf0fb6c692bc3d1c4269e6177 upstream. If a user manages to trigger an oops with fs set to KERNEL_DS, fs is not otherwise reset before do_exit(). do_exit may later (via mm_release in fork.c) do a put_user to a user-controlled address, potentially allowing a user to leverage an oops into a controlled write into kernel memory. This is only triggerable in the presence of another bug, but this potentially turns a lot of DoS bugs into privilege escalations, so it's worth fixing. I have proof-of-concept code which uses this bug along with CVE-2010-3849 to write a zero to an arbitrary kernel address, so I've tested that this is not theoretical. A more logical place to put this fix might be when we know an oops has occurred, before we call do_exit(), but that would involve changing every architecture, in multiple places. Let's just stick it in do_exit instead. [akpm@linux-foundation.org: update code comment] Signed-off-by: Nelson Elhage Cc: KOSAKI Motohiro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit ca20422682e1da682252203cd65c714a97358363 Author: Ken Sumrall Date: Wed Nov 24 12:57:00 2010 -0800 fuse: fix attributes after open(O_TRUNC) commit a0822c55779d9319939eac69f00bb729ea9d23da upstream. The attribute cache for a file was not being cleared when a file is opened with O_TRUNC. If the filesystem's open operation truncates the file ("atomic_o_trunc" feature flag is set) then the kernel should invalidate the cached st_mtime and st_ctime attributes. Also i_size should be explicitly be set to zero as it is used sometimes without refreshing the cache. Signed-off-by: Ken Sumrall Cc: Anfei Cc: "Anand V. Avati" Signed-off-by: Miklos Szeredi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 93e70a099cdbed447e70bb9cef157ba85fb8b337 Author: Len Brown Date: Tue Sep 28 17:51:51 2010 -0400 ACPI: EC: add Vista incompatibility DMI entry for Toshiba Satellite L355 commit 7a1d602f5fc35d14907b7da98d5627acb69589d1 upstream. https://bugzilla.kernel.org/show_bug.cgi?id=12641 Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit c46e0edd8b6d4eb9789f9aa8a1315da8b0293059 Author: Zhang Rui Date: Tue Oct 12 09:09:37 2010 +0800 acpi-cpufreq: fix a memleak when unloading driver commit dab5fff14df2cd16eb1ad4c02e83915e1063fece upstream. We didn't free per_cpu(acfreq_data, cpu)->freq_table when acpi_freq driver is unloaded. Resulting in the following messages in /sys/kernel/debug/kmemleak: unreferenced object 0xf6450e80 (size 64): comm "modprobe", pid 1066, jiffies 4294677317 (age 19290.453s) hex dump (first 32 bytes): 00 00 00 00 e8 a2 24 00 01 00 00 00 00 9f 24 00 ......$.......$. 02 00 00 00 00 6a 18 00 03 00 00 00 00 35 0c 00 .....j.......5.. backtrace: [] kmemleak_alloc+0x27/0x50 [] __kmalloc+0xcf/0x110 [] acpi_cpufreq_cpu_init+0x1ee/0x4e4 [acpi_cpufreq] [] cpufreq_add_dev+0x142/0x3a0 [] sysdev_driver_register+0x97/0x110 [] cpufreq_register_driver+0x86/0x140 [] 0xf9dad080 [] do_one_initcall+0x30/0x160 [] sys_init_module+0x99/0x1e0 [] sysenter_do_call+0x12/0x26 [] 0xffffffff https://bugzilla.kernel.org/show_bug.cgi?id=15807#c21 Tested-by: Toralf Forster Signed-off-by: Zhang Rui Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman commit 419f085cdefde20984291f989d7886fd3b0b32c8 Author: Jacques Viviers Date: Wed Nov 24 11:56:38 2010 +0200 USB: serial: ftdi_sio: Vardaan USB RS422/485 converter PID added commit 6fdbad8021151a9e93af8159a6232c8f26415c09 upstream. Add the PID for the Vardaan Enterprises VEUSB422R3 USB to RS422/485 converter. It uses the same chip as the FTDI_8U232AM_PID 0x6001. This should also work with the stable branches for: 2.6.31, 2.6.32, 2.6.33, 2.6.34, 2.6.35, 2.6.36 Signed-off-by: Jacques Viviers Signed-off-by: Greg Kroah-Hartman commit dd98509631f151321307f55806cbecd2fa1774da Author: Michael Stuermer Date: Thu Nov 18 00:45:43 2010 +0100 USB: ftdi_sio: Add ID for RT Systems USB-29B radio cable commit 28942bb6a9dd4e2ed793675e515cfb8297ed355b upstream. Another variant of the RT Systems programming cable for ham radios. Signed-off-by: Michael Stuermer Signed-off-by: Greg Kroah-Hartman commit e4aa2cab57c2a2cd76d82f72b3eea8c1418d2183 Author: Greg Kroah-Hartman Date: Mon Nov 15 11:36:44 2010 -0800 USB: misc: usbsevseg: fix up some sysfs attribute permissions commit e24d7ace4e822debcb78386bf279c9aba4d7fbd1 upstream. They should not be writable by any user. Reported-by: Linus Torvalds Cc: Harrison Metzger Signed-off-by: Greg Kroah-Hartman commit 872d84628480ee1e26503e45e9650c09c649380c Author: Greg Kroah-Hartman Date: Mon Nov 15 11:34:26 2010 -0800 USB: misc: trancevibrator: fix up a sysfs attribute permission commit d489a4b3926bad571d404ca6508f6744b9602776 upstream. It should not be writable by any user. Reported-by: Linus Torvalds Cc: Sam Hocevar Signed-off-by: Greg Kroah-Hartman commit 89879f8368809fdcef876ce271b9c03aae57a399 Author: Johan Hovold Date: Sun Sep 12 16:31:45 2010 +0200 USB: ftdi_sio: revert "USB: ftdi_sio: fix DTR/RTS line modes" commit 677aeafe19e88c282af74564048243ccabb1c590 upstream. This reverts commit 6a1a82df91fa0eb1cc76069a9efe5714d087eccd. RTS and DTR should not be modified based on CRTSCTS when calling set_termios. Modem control lines are raised at port open by the tty layer and should stay raised regardless of whether hardware flow control is enabled or not. This is in conformance with the way serial ports work today and many applications depend on this behaviour to be able to talk to hardware implementing hardware flow control (without the applications actually using it). Hardware which expects different behaviour on these lines can always use TIOCMSET/TIOCMBI[SC] after port open to change them. Reported-by: Daniel Mack Reported-by: Dave Mielke Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 0658f4b5ff80df551c5411f2a9a448f62664d2dc Author: Greg Kroah-Hartman Date: Mon Nov 15 11:35:49 2010 -0800 USB: misc: usbled: fix up some sysfs attribute permissions commit 48f115470e68d443436b76b22dad63ffbffd6b97 upstream. They should not be writable by any user. Reported-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit d9d7d5f7290a7882b4b388b739af284bdb986b17 Author: Greg Kroah-Hartman Date: Mon Nov 15 11:32:38 2010 -0800 USB: misc: cypress_cy7c63: fix up some sysfs attribute permissions commit c990600d340641150f7270470a64bd99a5c0b225 upstream. They should not be writable by any user. Reported-by: Linus Torvalds Cc: Oliver Bock Signed-off-by: Greg Kroah-Hartman commit 4e3da372aa19e62120e28ac9e9ff9b2c49e7a958 Author: Greg Kroah-Hartman Date: Mon Nov 15 11:11:45 2010 -0800 USB: atm: ueagle-atm: fix up some permissions on the sysfs files commit e502ac5e1eca99d7dc3f12b2a6780ccbca674858 upstream. Some of the sysfs files had the incorrect permissions. Some didn't make sense at all (writable for a file that you could not write to?) Reported-by: Linus Torvalds Cc: Matthieu Castet Cc: Stanislaw Gruszka Cc: Damien Bergamini Signed-off-by: Greg Kroah-Hartman commit 3e4233a4069bed17484bbe17c7a3ee8ce9763f23 Author: Greg Kroah-Hartman Date: Mon Nov 15 11:17:52 2010 -0800 USB: storage: sierra_ms: fix sysfs file attribute commit d9624e75f6ad94d8a0718c1fafa89186d271a78c upstream. A non-writable sysfs file shouldn't have writable attributes. Reported-by: Linus Torvalds Cc: Kevin Lloyd Cc: Matthew Dharm Signed-off-by: Greg Kroah-Hartman commit c2edb52c5b1d18c80b55d3be663c99b7f5dc5877 Author: Alan Stern Date: Tue Nov 16 10:57:37 2010 -0500 USB: EHCI: fix obscure race in ehci_endpoint_disable commit 02e2c51ba3e80acde600721ea784c3ef84da5ea1 upstream. This patch (as1435) fixes an obscure and unlikely race in ehci-hcd. When an async URB is unlinked, the corresponding QH is removed from the async list. If the QH's endpoint is then disabled while the URB is being given back, ehci_endpoint_disable() won't find the QH on the async list, causing it to believe that the QH has been lost. This will lead to a memory leak at best and quite possibly to an oops. The solution is to trust usbcore not to lose track of endpoints. If the QH isn't on the async list then it doesn't need to be taken off the list, but the driver should still wait for the QH to become IDLE before disabling it. In theory this fixes Bugzilla #20182. In fact the race is so rare that it's not possible to tell whether the bug is still present. However, adding delays and making other changes to force the race seems to show that the patch works. Signed-off-by: Alan Stern Reported-by: Stefan Richter CC: David Brownell Signed-off-by: Greg Kroah-Hartman commit 2ca6e919e77473fb15a7437b3772a25e2a7ab1fb Author: Vasiliy Kulikov Date: Sat Nov 6 17:41:28 2010 +0300 usb: core: fix information leak to userland commit 886ccd4520064408ce5876cfe00554ce52ecf4a7 upstream. Structure usbdevfs_connectinfo is copied to userland with padding byted after "slow" field uninitialized. It leads to leaking of contents of kernel stack memory. Signed-off-by: Vasiliy Kulikov Signed-off-by: Greg Kroah-Hartman commit 25281c78b18e69379f6e2a00c693417208e8b8a7 Author: Vasiliy Kulikov Date: Sat Nov 6 17:41:31 2010 +0300 usb: misc: iowarrior: fix information leak to userland commit eca67aaeebd6e5d22b0d991af1dd0424dc703bfb upstream. Structure iowarrior_info is copied to userland with padding byted between "serial" and "revision" fields uninitialized. It leads to leaking of contents of kernel stack memory. Signed-off-by: Vasiliy Kulikov Acked-by: Kees Cook Signed-off-by: Greg Kroah-Hartman commit 6909d43e26b098f79ea2300ddec56a7c39f5675e Author: Vasiliy Kulikov Date: Sat Nov 6 17:41:35 2010 +0300 usb: misc: sisusbvga: fix information leak to userland commit 5dc92cf1d0b4b0debbd2e333b83f9746c103533d upstream. Structure sisusb_info is copied to userland with "sisusb_reserved" field uninitialized. It leads to leaking of contents of kernel stack memory. Signed-off-by: Vasiliy Kulikov Signed-off-by: Greg Kroah-Hartman commit f12e1249c6d145bd116b2c2199b1df7a901e245d Author: ma rui Date: Mon Nov 1 11:32:18 2010 +0800 USB: option: fix when the driver is loaded incorrectly for some Huawei devices. commit 58c0d9d70109bd7e82bdb9517007311a48499960 upstream. When huawei datacard with PID 0x14AC is insterted into Linux system, the present kernel will load the "option" driver to all the interfaces. But actually, some interfaces run as other function and do not need "option" driver. In this path, we modify the id_tables, when the PID is 0x14ac ,VID is 0x12d1, Only when the interface's Class is 0xff,Subclass is 0xff, Pro is 0xff, it does need "option" driver. Signed-off-by: ma rui Signed-off-by: Greg Kroah-Hartman commit b8fbc33247e9d9aab009838a082a700ff35d3ebb Author: Sebastien Bourdeauducq Date: Wed Nov 3 11:54:12 2010 +0100 USB: ftdi_sio: add device IDs for Milkymist One JTAG/serial commit 7fea0f714ffb3f303d4b66933af2df2f5584c9bf upstream. Add the USB IDs for the Milkymist One FTDI-based JTAG/serial adapter (http://projects.qi-hardware.com/index.php/p/mmone-jtag-serial-cable/) to the ftdi_sio driver and disable the first serial channel (used as JTAG from userspace). Signed-off-by: Sebastien Bourdeauducq Signed-off-by: Greg Kroah-Hartman commit 903fdaaa174b81246c0a74a1c46502cce9d3a66f Author: Josh Wu Date: Tue Nov 16 11:51:32 2010 +0100 USB: gadget: AT91: fix typo in atmel_usba_udc driver commit b48809518631880207796b4aab0fc39c2f036754 upstream. compile fix for bug introduced by 969affff547027) Signed-off-by: Josh Wu Cc: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 2d325d38fbced76120c9df96d535961ef2c65170 Author: Peter Jones Date: Wed Sep 22 13:05:04 2010 -0700 efifb: check that the base address is plausible on pci systems commit 85a00d9bbfb4704fbf368944b1cb9fed8f1598c5 upstream. Some Apple machines have identical DMI data but different memory configurations for the video. Given that, check that the address in our table is actually within the range of a PCI BAR on a VGA device in the machine. This also fixes up the return value from set_system(), which has always been wrong, but never resulted in bad behavior since there's only ever been one matching entry in the dmi table. The patch 1) stops people's machines from crashing when we get their display wrong, which seems to be unfortunately inevitable, 2) allows us to support identical dmi data with differing video memory configurations This also adds me as the efifb maintainer, since I've effectively been acting as such for quite some time. Signed-off-by: Peter Jones Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit dc06f166e1ac4d82f8eb10645fcbfb9cc609583d Author: Darrick J. Wong Date: Tue Nov 16 09:13:41 2010 -0800 PCI: fix offset check for sysfs mmapped files commit 8c05cd08a7504b855c265263e84af61aabafa329 upstream. I just loaded 2.6.37-rc2 on my machines, and I noticed that X no longer starts. Running an strace of the X server shows that it's doing this: open("/sys/bus/pci/devices/0000:07:00.0/resource0", O_RDWR) = 10 mmap(NULL, 16777216, PROT_READ|PROT_WRITE, MAP_SHARED, 10, 0) = -1 EINVAL (Invalid argument) This code seems to be asking for a shared read/write mapping of 16MB worth of BAR0 starting at file offset 0, and letting the kernel assign a starting address. Unfortunately, this -EINVAL causes X not to start. Looking into dmesg, there's a complaint like so: process "Xorg" tried to map 0x01000000 bytes at page 0x00000000 on 0000:07:00.0 BAR 0 (start 0x 96000000, size 0x 1000000) ...with the following code in pci_mmap_fits: pci_start = (mmap_api == PCI_MMAP_SYSFS) ? pci_resource_start(pdev, resno) >> PAGE_SHIFT : 0; if (start >= pci_start && start < pci_start + size && start + nr <= pci_start + size) It looks like the logic here is set up such that when the mmap call comes via sysfs, the check in pci_mmap_fits wants vma->vm_pgoff to be between the resource's start and end address, and the end of the vma to be no farther than the end. However, the sysfs PCI resource files always start at offset zero, which means that this test always fails for programs that mmap the sysfs files. Given the comment in the original commit 3b519e4ea618b6943a82931630872907f9ac2c2b, I _think_ the old procfs files require that the file offset be equal to the resource's base address when mmapping. I think what we want here is for pci_start to be 0 when mmap_api == PCI_MMAP_PROCFS. The following patch makes that change, after which the Matrox and Mach64 X drivers work again. Acked-by: Martin Wilck Signed-off-by: Darrick J. Wong Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman commit 470dd9c158cfb7cc45d7748fdb10c1ef854d3a9c Author: Martin Wilck Date: Wed Nov 10 11:03:21 2010 +0100 PCI: fix size checks for mmap() on /proc/bus/pci files commit 3b519e4ea618b6943a82931630872907f9ac2c2b upstream. The checks for valid mmaps of PCI resources made through /proc/bus/pci files that were introduced in 9eff02e2042f96fb2aedd02e032eca1c5333d767 have several problems: 1. mmap() calls on /proc/bus/pci files are made with real file offsets > 0, whereas under /sys/bus/pci/devices, the start of the resource corresponds to offset 0. This may lead to false negatives in pci_mmap_fits(), which implicitly assumes the /sys/bus/pci/devices layout. 2. The loop in proc_bus_pci_mmap doesn't skip empty resouces. This leads to false positives, because pci_mmap_fits() doesn't treat empty resources correctly (the calculated size is 1 << (8*sizeof(resource_size_t)-PAGE_SHIFT) in this case!). 3. If a user maps resources with BAR > 0, pci_mmap_fits will emit bogus WARNINGS for the first resources that don't fit until the correct one is found. On many controllers the first 2-4 BARs are used, and the others are empty. In this case, an mmap attempt will first fail on the non-empty BARs (including the "right" BAR because of 1.) and emit bogus WARNINGS because of 3., and finally succeed on the first empty BAR because of 2. This is certainly not the intended behaviour. This patch addresses all 3 issues. Updated with an enum type for the additional parameter for pci_mmap_fits(). Signed-off-by: Martin Wilck Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman commit bdfddf11e44234d16e2f0a46c672da72044d034a Author: Tejun Heo Date: Mon Nov 1 11:39:19 2010 +0100 libata: fix NULL sdev dereference race in atapi_qc_complete() commit 2a5f07b5ec098edc69e05fdd2f35d3fbb1235723 upstream. SCSI commands may be issued between __scsi_add_device() and dev->sdev assignment, so it's unsafe for ata_qc_complete() to dereference dev->sdev->locked without checking whether it's NULL or not. Fix it. Signed-off-by: Tejun Heo Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman commit c4fb9d1fb7b82a6894f7c63194e68f4c7b819ad4 Author: Douglas Gilbert Date: Mon Feb 1 13:11:38 2010 -0500 libata-scsi passthru: fix bug which truncated LBA48 return values commit bc496ed00ab1411d3efaf295b72e0c9eb343e1a3 upstream. Fix assignment which overwrote SAT ATA PASS-THROUGH command EXTEND bit setting (ATA_TFLAG_LBA48) Signed-off-by: Douglas Gilbert Signed-off-by: Jeff Garzik Cc: Kerin Millar Signed-off-by: Greg Kroah-Hartman commit 5e353d5fd91c564849790c39ef790b66400c24bc Author: Francisco Jerez Date: Tue Sep 21 02:15:15 2010 +0200 drm/ttm: Clear the ghost cpu_writers flag on ttm_buffer_object_transfer. commit 0fbecd400dd0a82d465b3086f209681e8c54cb0f upstream. It makes sense for a BO to move after a process has requested exclusive RW access on it (e.g. because the BO used to be located in unmappable VRAM and we intercepted the CPU access from the fault handler). If we let the ghost object inherit cpu_writers from the original object, ttm_bo_release_list() will raise a kernel BUG when the ghost object is destroyed. This can be reproduced with the nouveau driver on nv5x. Reported-by: Marcin Slusarz Reviewed-by: Jerome Glisse Tested-by: Marcin Slusarz Signed-off-by: Francisco Jerez Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit cbe7684480e2b379eeae1317b6aa7fab413501a8 Author: Jens Axboe Date: Wed Nov 10 14:36:25 2010 +0100 bio: take care not overflow page count when mapping/copying user data commit cb4644cac4a2797afc847e6c92736664d4b0ea34 upstream. If the iovec is being set up in a way that causes uaddr + PAGE_SIZE to overflow, we could end up attempting to map a huge number of pages. Check for this invalid input type. Reported-by: Dan Rosenberg Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit a7c486e4d247d5a076b6f94937ac402f4ac9c70b Author: Dave Hansen Date: Thu Nov 11 14:05:15 2010 -0800 mm/vfs: revalidate page->mapping in do_generic_file_read() commit 8d056cb965b8fb7c53c564abf28b1962d1061cd3 upstream. 70 hours into some stress tests of a 2.6.32-based enterprise kernel, we ran into a NULL dereference in here: int block_is_partially_uptodate(struct page *page, read_descriptor_t *desc, unsigned long from) { ----> struct inode *inode = page->mapping->host; It looks like page->mapping was the culprit. (xmon trace is below). After closer examination, I realized that do_generic_file_read() does a find_get_page(), and eventually locks the page before calling block_is_partially_uptodate(). However, it doesn't revalidate the page->mapping after the page is locked. So, there's a small window between the find_get_page() and ->is_partially_uptodate() where the page could get truncated and page->mapping cleared. We _have_ a reference, so it can't get reclaimed, but it certainly can be truncated. I think the correct thing is to check page->mapping after the trylock_page(), and jump out if it got truncated. This patch has been running in the test environment for a month or so now, and we have not seen this bug pop up again. xmon info: 1f:mon> e cpu 0x1f: Vector: 300 (Data Access) at [c0000002ae36f770] pc: c0000000001e7a6c: .block_is_partially_uptodate+0xc/0x100 lr: c000000000142944: .generic_file_aio_read+0x1e4/0x770 sp: c0000002ae36f9f0 msr: 8000000000009032 dar: 0 dsisr: 40000000 current = 0xc000000378f99e30 paca = 0xc000000000f66300 pid = 21946, comm = bash 1f:mon> r R00 = 0025c0500000006d R16 = 0000000000000000 R01 = c0000002ae36f9f0 R17 = c000000362cd3af0 R02 = c000000000e8cd80 R18 = ffffffffffffffff R03 = c0000000031d0f88 R19 = 0000000000000001 R04 = c0000002ae36fa68 R20 = c0000003bb97b8a0 R05 = 0000000000000000 R21 = c0000002ae36fa68 R06 = 0000000000000000 R22 = 0000000000000000 R07 = 0000000000000001 R23 = c0000002ae36fbb0 R08 = 0000000000000002 R24 = 0000000000000000 R09 = 0000000000000000 R25 = c000000362cd3a80 R10 = 0000000000000000 R26 = 0000000000000002 R11 = c0000000001e7b60 R27 = 0000000000000000 R12 = 0000000042000484 R28 = 0000000000000001 R13 = c000000000f66300 R29 = c0000003bb97b9b8 R14 = 0000000000000001 R30 = c000000000e28a08 R15 = 000000000000ffff R31 = c0000000031d0f88 pc = c0000000001e7a6c .block_is_partially_uptodate+0xc/0x100 lr = c000000000142944 .generic_file_aio_read+0x1e4/0x770 msr = 8000000000009032 cr = 22000488 ctr = c0000000001e7a60 xer = 0000000020000000 trap = 300 dar = 0000000000000000 dsisr = 40000000 1f:mon> t [link register ] c000000000142944 .generic_file_aio_read+0x1e4/0x770 [c0000002ae36f9f0] c000000000142a14 .generic_file_aio_read+0x2b4/0x770 (unreliable) [c0000002ae36fb40] c0000000001b03e4 .do_sync_read+0xd4/0x160 [c0000002ae36fce0] c0000000001b153c .vfs_read+0xec/0x1f0 [c0000002ae36fd80] c0000000001b1768 .SyS_read+0x58/0xb0 [c0000002ae36fe30] c00000000000852c syscall_exit+0x0/0x40 --- Exception: c00 (System Call) at 00000080a840bc54 SP (fffca15df30) is in userspace 1f:mon> di c0000000001e7a6c c0000000001e7a6c e9290000 ld r9,0(r9) c0000000001e7a70 418200c0 beq c0000000001e7b30 # .block_is_partially_uptodate+0xd0/0x100 c0000000001e7a74 e9440008 ld r10,8(r4) c0000000001e7a78 78a80020 clrldi r8,r5,32 c0000000001e7a7c 3c000001 lis r0,1 c0000000001e7a80 812900a8 lwz r9,168(r9) c0000000001e7a84 39600001 li r11,1 c0000000001e7a88 7c080050 subf r0,r8,r0 c0000000001e7a8c 7f805040 cmplw cr7,r0,r10 c0000000001e7a90 7d6b4830 slw r11,r11,r9 c0000000001e7a94 796b0020 clrldi r11,r11,32 c0000000001e7a98 419d00a8 bgt cr7,c0000000001e7b40 # .block_is_partially_uptodate+0xe0/0x100 c0000000001e7a9c 7fa55840 cmpld cr7,r5,r11 c0000000001e7aa0 7d004214 add r8,r0,r8 c0000000001e7aa4 79080020 clrldi r8,r8,32 c0000000001e7aa8 419c0078 blt cr7,c0000000001e7b20 # .block_is_partially_uptodate+0xc0/0x100 Signed-off-by: Dave Hansen Reviewed-by: Minchan Kim Reviewed-by: Johannes Weiner Acked-by: Rik van Riel Cc: Cc: Cc: Christoph Hellwig Cc: Al Viro Cc: Minchan Kim Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit b5b514d543f20fa4111eb69abaf6c06b185b454e Author: Ken Chen Date: Thu Nov 11 14:05:16 2010 -0800 latencytop: fix per task accumulator commit 38715258aa2e8cd94bd4aafadc544e5104efd551 upstream. Per task latencytop accumulator prematurely terminates due to erroneous placement of latency_record_count. It should be incremented whenever a new record is allocated instead of increment on every latencytop event. Also fix search iterator to only search known record events instead of blindly searching all pre-allocated space. Signed-off-by: Ken Chen Reviewed-by: Arjan van de Ven Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 611a418f2d8508757f9ca9499fe5348e3df21e8e Author: Eric Dumazet Date: Thu Oct 28 12:34:21 2010 +0200 netfilter: nf_conntrack: allow nf_ct_alloc_hashtable() to get highmem pages commit 6b1686a71e3158d3c5f125260effce171cc7852b upstream. commit ea781f197d6a8 (use SLAB_DESTROY_BY_RCU and get rid of call_rcu()) did a mistake in __vmalloc() call in nf_ct_alloc_hashtable(). I forgot to add __GFP_HIGHMEM, so pages were taken from LOWMEM only. Signed-off-by: Eric Dumazet Signed-off-by: Patrick McHardy Signed-off-by: Greg Kroah-Hartman commit 7e43ba7721a74ccc0f05ae83547215338aca95a8 Author: Daniel T Chen Date: Wed Dec 1 19:16:07 2010 -0500 ALSA: hda: Use "alienware" model quirk for another SSID commit 0defe09ca70daccdc83abd9c3c24cd89ae6a1141 upstream. BugLink: https://launchpad.net/bugs/683695 The original reporter states that headphone jacks do not appear to work. Upon inspecting his codec dump, and upon further testing, it is confirmed that the "alienware" model quirk is correct. Reported-and-tested-by: Cody Thierauf Signed-off-by: Daniel T Chen Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit ff14c4bf34a8dc027505912ae25c0b20cf09dd80 Author: David Henningsson Date: Wed Nov 24 14:17:47 2010 +0100 ALSA: HDA: Add an extra DAC for Realtek ALC887-VD commit cc1c452e509aefc28f7ad2deed75bc69d4f915f7 upstream. The patch enables ALC887-VD to use the DAC at nid 0x26, which makes it possible to use this DAC for e g Headphone volume. Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 4e6fabab7945d7ff0498ec20bdf4d10889463ed5 Author: Daniel T Chen Date: Mon Nov 1 01:14:51 2010 -0400 ALSA: ac97: Apply quirk for Dell Latitude D610 binding Master and Headphone controls commit 0613a59456980161d0cd468bae6c63d772743102 upstream. BugLink: https://launchpad.net/bugs/669279 The original reporter states: "The Master mixer does not change the volume from the headphone output (which is affected by the headphone mixer). Instead it only seems to control the on-board speaker volume. This confuses PulseAudio greatly as the Master channel is merged into the volume mix." Fix this symptom by applying the hp_only quirk for the reporter's SSID. The fix is applicable to all stable kernels. Reported-and-tested-by: Ben Gamari Signed-off-by: Daniel T Chen Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 263256d70931663c62b1699c007a853e3a6db2ea Author: Clemens Ladisch Date: Mon Oct 25 11:42:20 2010 +0200 firewire: ohci: fix race in AR split packet handling commit a1f805e5e73a8fe166b71c6592d3837df0cd5e2e upstream. When handling an AR buffer that has been completely filled, we assumed that its descriptor will not be read by the controller and can be overwritten. However, when the last received packet happens to end at the end of the buffer, the controller might not yet have moved on to the next buffer and might read the branch address later. If we overwrite and free the page before that, the DMA context will either go dead because of an invalid Z value, or go off into some random memory. To fix this, ensure that the descriptor does not get overwritten by using only the actual buffer instead of the entire page for reassembling the split packet. Furthermore, to avoid freeing the page too early, move on to the next buffer only when some data in it guarantees that the controller has moved on. This should eliminate the remaining firewire-net problems. Signed-off-by: Clemens Ladisch Tested-by: Maxim Levitsky Signed-off-by: Stefan Richter Signed-off-by: Greg Kroah-Hartman commit 9cfed69ea337d0b811044aa3222baa7306dc78a9 Author: Clemens Ladisch Date: Mon Oct 25 11:41:53 2010 +0200 firewire: ohci: fix buffer overflow in AR split packet handling commit 85f7ffd5d2b320f73912b15fe8cef34bae297daf upstream. When the controller had to split a received asynchronous packet into two buffers, the driver tries to reassemble it by copying both parts into the first page. However, if size + rest > PAGE_SIZE, i.e., if the yet unhandled packets before the split packet, the split packet itself, and any received packets after the split packet are together larger than one page, then the memory after the first page would get overwritten. To fix this, do not try to copy the data of all unhandled packets at once, but copy the possibly needed data every time when handling a packet. This gets rid of most of the infamous crashes and data corruptions when using firewire-net. Signed-off-by: Clemens Ladisch Tested-by: Maxim Levitsky Signed-off-by: Stefan Richter Signed-off-by: Greg Kroah-Hartman commit 7098a32a0303c42e8b2db72fd8cf58c624a96a7e Author: Stefan Richter Date: Fri Feb 19 21:00:02 2010 +0100 firewire: core: fix an information leak commit 137d9ebfdbaa45c01f9f0f6d5121ae6f1eb942bd upstream. If a device exposes a sparsely populated configuration ROM, firewire-core's sysfs interface and character device file interface showed random data in the gaps between config ROM blocks. Fix this by zero-initialization of the config ROM reader's scratch buffer. Signed-off-by: Stefan Richter Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit 6f3fc70b17939b2b3786198d6d5f30c2066516c9 Author: Stefan Richter Date: Wed Apr 7 08:30:50 2010 +0200 firewire: cdev: fix information leak commit 9cac00b8f0079d5d3d54ec4dae453d58dec30e7c upstream. A userspace client got to see uninitialized stack-allocated memory if it specified an _IOC_READ type of ioctl and an argument size larger than expected by firewire-core's ioctl handlers (but not larger than the core's union ioctl_arg). Fix this by clearing the requested buffer size to zero, but only at _IOR ioctls. This way, there is almost no runtime penalty to legitimate ioctls. The only legitimate _IOR is FW_CDEV_IOC_GET_CYCLE_TIMER with 12 or 16 bytes to memset. [Another way to fix this would be strict checking of argument size (and possibly direction) vs. command number. However, we then need a lookup table, and we need to allow for slight size deviations in case of 32bit userland on 64bit kernel.] Reported-by: Clemens Ladisch Signed-off-by: Stefan Richter [ Backported to 2.6.32 firewire core -maks ] Signed-off-by: maximilian attems Signed-off-by: Greg Kroah-Hartman commit fda45f0be5c9d1671b6bc5b35b6143360f2b10bd Author: Ben Hutchings Date: Mon Nov 29 13:00:15 2010 -0200 KVM: VMX: Fix host userspace gsbase corruption commit c8770e7ba63bb5dd8fe5f9d251275a8fa717fb78 upstream. We now use load_gs_index() to load gs safely; unfortunately this also changes MSR_KERNEL_GS_BASE, which we managed separately. This resulted in confusion and breakage running 32-bit host userspace on a 64-bit kernel. Fix by - saving guest MSR_KERNEL_GS_BASE before we we reload the host's gs - doing the host save/load unconditionally, instead of only when in guest long mode Things can be cleaned up further, but this is the minmal fix for now. Signed-off-by: Avi Kivity Signed-off-by: Marcelo Tosatti [bwh: Backport to 2.6.32] Signed-off-by: Greg Kroah-Hartman commit 91445a8f6fee2f78680bae847cabe237a6e57eb9 Author: Vasiliy Kulikov Date: Mon Nov 29 13:00:14 2010 -0200 KVM: x86: fix information leak to userland commit 97e69aa62f8b5d338d6cff49be09e37cc1262838 upstream. Structures kvm_vcpu_events, kvm_debugregs, kvm_pit_state2 and kvm_clock_data are copied to userland with some padding and reserved fields unitialized. It leads to leaking of contents of kernel stack memory. We have to initialize them to zero. In patch v1 Jan Kiszka suggested to fill reserved fields with zeros instead of memset'ting the whole struct. It makes sense as these fields are explicitly marked as padding. No more fields need zeroing. Signed-off-by: Vasiliy Kulikov Signed-off-by: Marcelo Tosatti Signed-off-by: Greg Kroah-Hartman commit 370c6b5200b04645ab1b00bad931ae899cd55471 Author: Gleb Natapov Date: Wed Nov 10 12:08:12 2010 +0200 KVM: VMX: fix vmx null pointer dereference on debug register access There is a bug in KVM that can be used to crash a host on Intel machines. If emulator is tricked into emulating mov to/from DR instruction it causes NULL pointer dereference on VMX since kvm_x86_ops->(set|get)_dr are not initialized. Recently this is not exploitable from guest userspace, but malicious guest kernel can trigger it easily. CVE-2010-0435 On upstream bug was fixed differently around 2.6.34. Signed-off-by: Gleb Natapov Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman commit 004e147bd32cda45140354ace87f55abed3b82cb Author: Jiri Slaby Date: Thu Nov 25 00:27:54 2010 +0100 TTY: ldisc, fix open flag handling commit 7f90cfc505d613f4faf096e0d84ffe99208057d9 upstream. When a concrete ldisc open fails in tty_ldisc_open, we forget to clear TTY_LDISC_OPEN. This causes a false warning on the next ldisc open: WARNING: at drivers/char/tty_ldisc.c:445 tty_ldisc_open+0x26/0x38() Hardware name: System Product Name Modules linked in: ... Pid: 5251, comm: a.out Tainted: G W 2.6.32-5-686 #1 Call Trace: [] ? warn_slowpath_common+0x5e/0x8a [] ? warn_slowpath_null+0xa/0xc [] ? tty_ldisc_open+0x26/0x38 [] ? tty_set_ldisc+0x218/0x304 ... So clear the bit when failing... Introduced in c65c9bc3efa (tty: rewrite the ldisc locking) back in 2.6.31-rc1. Signed-off-by: Jiri Slaby Cc: Alan Cox Reported-by: Sergey Lapin Tested-by: Sergey Lapin Signed-off-by: Greg Kroah-Hartman commit d22ed6613136322b8cd6a126b75f5c8175f5f00c Author: Philippe Rétornaz Date: Wed Oct 27 17:13:21 2010 +0200 tty_ldisc: Fix BUG() on hangup commit 1c95ba1e1de7edffc0c4e275e147f1a9eb1f81ae upstream. A kernel BUG when bluetooth rfcomm connection drop while the associated serial port is open is sometime triggered. It seems that the line discipline can disappear between the tty_ldisc_put and tty_ldisc_get. This patch fall back to the N_TTY line discipline if the previous discipline is not available anymore. Signed-off-by: Philippe Retornaz Acked-by: Alan Cox Signed-off-by: Greg Kroah-Hartman commit 3fe5daa1d79cbd71c4b8eb7792ea339762399092 Author: Jiri Slaby Date: Sun Oct 31 23:17:51 2010 +0100 TTY: restore tty_ldisc_wait_idle commit 100eeae2c5ce23b4db93ff320ee330ef1d740151 upstream. It was removed in 65b770468e98 (tty-ldisc: turn ldisc user count into a proper refcount), but we need to wait for last user to quit the ldisc before we close it in tty_set_ldisc. Otherwise weird things start to happen. There might be processes waiting in tty_read->n_tty_read on tty->read_wait for input to appear and at that moment, a change of ldisc is fatal. n_tty_close is called, it frees read_buf and the waiting process is still in the middle of reading and goes nuts after it is woken. Previously we prevented close to happen when others are in ldisc ops by tty_ldisc_wait_idle in tty_set_ldisc. But the commit above removed that. So revoke the change and test whether there is 1 user (=we), and allow the close then. We can do that without ldisc/tty locks, because nobody else can open the device due to TTY_LDISC_CHANGING bit set, so we in fact wait for everybody to leave. I don't understand why tty_ldisc_lock would be needed either when the counter is an atomic variable, so this is a lockless tty_ldisc_wait_idle. On the other hand, if we fail to wait (timeout or signal), we have to reenable the halted ldiscs, so we take ldisc lock and reuse the setup path at the end of tty_set_ldisc. Signed-off-by: Jiri Slaby Acked-by: Linus Torvalds Tested-by: Sebastian Andrzej Siewior LKML-Reference: <20101031104136.GA511@Chamillionaire.breakpoint.cc> LKML-Reference: <1287669539-22644-1-git-send-email-jslaby@suse.cz> Cc: Alan Cox Signed-off-by: Greg Kroah-Hartman commit 8dded7dc4c71fd206ffa2b7725a1c74544104009 Author: Jiri Olsa Date: Mon Nov 8 19:01:47 2010 +0100 tty: prevent DOS in the flush_to_ldisc commit e045fec48970df84647a47930fcf7a22ff7229c0 upstream. There's a small window inside the flush_to_ldisc function, where the tty is unlocked and calling ldisc's receive_buf function. If in this window new buffer is added to the tty, the processing might never leave the flush_to_ldisc function. This scenario will hog the cpu, causing other tty processing starving, and making it impossible to interface the computer via tty. I was able to exploit this via pty interface by sending only control characters to the master input, causing the flush_to_ldisc to be scheduled, but never actually generate any output. To reproduce, please run multiple instances of following code. - SNIP #define _XOPEN_SOURCE #include #include #include #include #include int main(int argc, char **argv) { int i, slave, master = getpt(); char buf[8192]; sprintf(buf, "%s", ptsname(master)); grantpt(master); unlockpt(master); slave = open(buf, O_RDWR); if (slave < 0) { perror("open slave failed"); return 1; } for(i = 0; i < sizeof(buf); i++) buf[i] = rand() % 32; while(1) { write(master, buf, sizeof(buf)); } return 0; } - SNIP The attached patch (based on -next tree) fixes this by checking on the tty buffer tail. Once it's reached, the current work is rescheduled and another could run. Signed-off-by: Jiri Olsa Acked-by: Alan Cox Signed-off-by: Greg Kroah-Hartman commit 814a341523e6715b36074cf2a0afc7833384fe9e Author: Prarit Bhargava Date: Thu Nov 12 13:09:31 2009 -0500 x86: AMD Northbridge: Verify NB's node is online commit 303fc0870f8fbfabe260c5c32b18e53458d597ea upstream. Fix panic seen on some IBM and HP systems on 2.6.32-rc6: BUG: unable to handle kernel NULL pointer dereference at (null) IP: [] find_next_bit+0x77/0x9c [...] [] cpumask_next_and+0x2e/0x3b [] pci_device_probe+0x8e/0xf5 [] ? driver_sysfs_add+0x47/0x6c [] driver_probe_device+0xd9/0x1f9 [] __driver_attach+0x58/0x7c [] ? __driver_attach+0x0/0x7c [] bus_for_each_dev+0x54/0x89 [] driver_attach+0x19/0x1b [] bus_add_driver+0xd3/0x23d [] driver_register+0x98/0x109 [] __pci_register_driver+0x63/0xd3 [] ? up_read+0x26/0x2a [] ? k8temp_init+0x0/0x20 [k8temp] [] k8temp_init+0x1e/0x20 [k8temp] [] do_one_initcall+0x6d/0x185 [] sys_init_module+0xd3/0x236 [] system_call_fastpath+0x16/0x1b I put in a printk and commented out the set_dev_node() call when and got this output: quirk_amd_nb_node: current numa_node = 0x0, would set to val & 7 = 0x0 quirk_amd_nb_node: current numa_node = 0x0, would set to val & 7 = 0x1 quirk_amd_nb_node: current numa_node = 0x0, would set to val & 7 = 0x2 quirk_amd_nb_node: current numa_node = 0x0, would set to val & 7 = 0x3 I.e. the issue appears to be that the HW has set val to a valid value, however, the system is only configured for a single node -- 0, the others are offline. Check to see if the node is actually online before setting the numa node for an AMD northbridge in quirk_amd_nb_node(). Signed-off-by: Prarit Bhargava Cc: bhavna.sarathy@amd.com Cc: jbarnes@virtuousgeek.org Cc: andreas.herrmann3@amd.com LKML-Reference: <20091112180933.12532.98685.sendpatchset@prarit.bos.redhat.com> [ v2: clean up the code and add comments ] Signed-off-by: Ingo Molnar Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman commit 7b17b8b11b62228a043deb8fe4672dd5e72a8701 Author: Justin Maggard Date: Wed Nov 24 16:36:17 2010 +1100 md: fix return value of rdev_size_change() commit c26a44ed1e552aaa1d4ceb71842002d235fe98d7 upstream. When trying to grow an array by enlarging component devices, rdev_size_store() expects the return value of rdev_size_change() to be in sectors, but the actual value is returned in KBs. This functionality was broken by commit dd8ac336c13fd8afdb082ebacb1cddd5cf727889 so this patch is suitable for any kernel since 2.6.30. Signed-off-by: Justin Maggard Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit 6ca3509bf488faa1925a9a4f8451298bbb0ba722 Author: NeilBrown Date: Wed Nov 24 16:39:46 2010 +1100 md/raid1: really fix recovery looping when single good device fails. commit 8f9e0ee38f75d4740daa9e42c8af628d33d19a02 upstream. Commit 4044ba58dd15cb01797c4fd034f39ef4a75f7cc3 supposedly fixed a problem where if a raid1 with just one good device gets a read-error during recovery, the recovery would abort and immediately restart in an infinite loop. However it depended on raid1_remove_disk removing the spare device from the array. But that does not happen in this case. So add a test so that in the 'recovery_disabled' case, the device will be removed. This suitable for any kernel since 2.6.29 which is when recovery_disabled was introduced. Reported-by: Sebastian Färber Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit 5cc0261b6abb36ceeaf5da4ea28dcc8b360899c7 Author: Tyler Hicks Date: Thu Sep 23 02:35:04 2010 -0500 eCryptfs: Clear LOOKUP_OPEN flag when creating lower file commit 2e21b3f124eceb6ab5a07c8a061adce14ac94e14 upstream. eCryptfs was passing the LOOKUP_OPEN flag through to the lower file system, even though ecryptfs_create() doesn't support the flag. A valid filp for the lower filesystem could be returned in the nameidata if the lower file system's create() function supported LOOKUP_OPEN, possibly resulting in unencrypted writes to the lower file. However, this is only a potential problem in filesystems (FUSE, NFS, CIFS, CEPH, 9p) that eCryptfs isn't known to support today. https://bugs.launchpad.net/ecryptfs/+bug/641703 Reported-by: Kevin Buhr Signed-off-by: Tyler Hicks Signed-off-by: Greg Kroah-Hartman commit e1e63040c20b863d165e06d99927af2e276134c8 Author: Florian Tobias Schandinat Date: Wed Sep 22 02:33:52 2010 +0000 viafb: use proper register for colour when doing fill ops commit efd4f6398dc92b5bf392670df862f42a19f34cf2 upstream. The colour was written to a wrong register for fillrect operations. This sometimes caused empty console space (for example after 'clear') to have a different colour than desired. Fix this by writing to the correct register. Many thanks to Daniel Drake and Jon Nettleton for pointing out this issue and pointing me in the right direction for the fix. Fixes http://dev.laptop.org/ticket/9323 Signed-off-by: Florian Tobias Schandinat Cc: Joseph Chan Cc: Daniel Drake Cc: Jon Nettleton Signed-off-by: Greg Kroah-Hartman commit ecd33c38afd3d6838a84f75d0905ab3d26c99ac5 Author: Graham Gower Date: Wed Oct 27 15:33:00 2010 -0700 drivers/char/vt_ioctl.c: fix VT_OPENQRY error value commit 1e0ad2881d50becaeea70ec696a80afeadf944d2 upstream. When all VT's are in use, VT_OPENQRY casts -1 to unsigned char before returning it to userspace as an int. VT255 is not the next available console. Signed-off-by: Graham Gower Cc: Greg KH Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 0785ba875cf1728a62c91856d312f5d89f8d2679 Author: Ben Hutchings Date: Fri Oct 22 04:38:26 2010 +0000 net: NETIF_F_HW_CSUM does not imply FCoE CRC offload commit 66c68bcc489fadd4f5e8839e966e3a366e50d1d5 upstream. NETIF_F_HW_CSUM indicates the ability to update an TCP/IP-style 16-bit checksum with the checksum of an arbitrary part of the packet data, whereas the FCoE CRC is something entirely different. Signed-off-by: Ben Hutchings Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit bf8dfc64f69b0160a915b5dbd2c39054ce295643 Author: Dan Rosenberg Date: Thu Sep 30 15:15:31 2010 -0700 sys_semctl: fix kernel stack leakage commit 982f7c2b2e6a28f8f266e075d92e19c0dd4c6e56 upstream. The semctl syscall has several code paths that lead to the leakage of uninitialized kernel stack memory (namely the IPC_INFO, SEM_INFO, IPC_STAT, and SEM_STAT commands) during the use of the older, obsolete version of the semid_ds struct. The copy_semid_to_user() function declares a semid_ds struct on the stack and copies it back to the user without initializing or zeroing the "sem_base", "sem_pending", "sem_pending_last", and "undo" pointers, allowing the leakage of 16 bytes of kernel stack memory. The code is still reachable on 32-bit systems - when calling semctl() newer glibc's automatically OR the IPC command with the IPC_64 flag, but invoking the syscall directly allows users to use the older versions of the struct. Signed-off-by: Dan Rosenberg Cc: Manfred Spraul Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit b84f1092385101cc432d2afce0bd52ce4d643018 Author: Vasiliy Kulikov Date: Sat Oct 30 18:22:49 2010 +0400 ipc: shm: fix information leak to userland commit 3af54c9bd9e6f14f896aac1bb0e8405ae0bc7a44 upstream. The shmid_ds structure is copied to userland with shm_unused{,2,3} fields unitialized. It leads to leaking of contents of kernel stack memory. Signed-off-by: Vasiliy Kulikov Acked-by: Al Viro Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 6606de00cc2053b821d7db0ab22aaa8af2ea6143 Author: Dan Rosenberg Date: Wed Oct 27 15:34:17 2010 -0700 ipc: initialize structure memory to zero for compat functions commit 03145beb455cf5c20a761e8451e30b8a74ba58d9 upstream. This takes care of leaking uninitialized kernel stack memory to userspace from non-zeroed fields in structs in compat ipc functions. Signed-off-by: Dan Rosenberg Cc: Manfred Spraul Cc: Arnd Bergmann Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 1c10b597710cbd35696f3145321dfb8cd92069ad Author: Jeremy Fitzhardinge Date: Mon Nov 29 14:16:53 2010 -0800 xen: don't bother to stop other cpus on shutdown/reboot commit 31e323cca9d5c8afd372976c35a5d46192f540d1 upstream. Xen will shoot all the VCPUs when we do a shutdown hypercall, so there's no need to do it manually. In any case it will fail because all the IPI irqs have been pulled down by this point, so the cross-CPU calls will simply hang forever. Until change 76fac077db6b34e2c6383a7b4f3f4f7b7d06d8ce the function calls were not synchronously waited for, so this wasn't apparent. However after that change the calls became synchronous leading to a hang on shutdown on multi-VCPU guests. Signed-off-by: Jeremy Fitzhardinge Cc: Alok Kataria Signed-off-by: Greg Kroah-Hartman commit f78785f8745489972717b7f9ee994c96a8d8978c Author: Ian Campbell Date: Fri Oct 8 16:59:12 2010 +0100 xen: ensure that all event channels start off bound to VCPU 0 commit b0097adeec27e30223c989561ab0f7aa60d1fe93 upstream. All event channels startbound to VCPU 0 so ensure that cpu_evtchn_mask is initialised to reflect this. Otherwise there is a race after registering an event channel but before the affinity is explicitly set where the event channel can be delivered. If this happens then the event channel remains pending in the L1 (evtchn_pending) array but is cleared in L2 (evtchn_pending_sel), this means the event channel cannot be reraised until another event channel happens to trigger the same L2 entry on that VCPU. sizeof(cpu_evtchn_mask(0))==sizeof(unsigned long*) which is not correct, and causes only the first 32 or 64 event channels (depending on architecture) to be initially bound to VCPU0. Use sizeof(struct cpu_evtchn_s) instead. Signed-off-by: Ian Campbell Cc: Jeremy Fitzhardinge Signed-off-by: Greg Kroah-Hartman commit 1e251f22b6ef6e018286e9a9745e66409131e353 Author: Robin@sgi.com Date: Wed Nov 24 12:56:59 2010 -0800 sgi-xpc: XPC fails to discover partitions with all nasids above 128 commit c22c7aeff69796f46ae0fcec141538e28f50b24e upstream. UV hardware defines 256 memory protection regions versus the baseline 64 with increasing size for the SN2 ia64. This was overlooked when XPC was modified to accomodate both UV and SN2. Without this patch, a user could reconfigure their existing system and suddenly disable cross-partition communications with no indication of what has gone wrong. It also prevents larger configurations from using cross-partition communication. Signed-off-by: Robin Holt Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 0b5059be74532f799ba09bfa6dfb6f11e98fdb17 Author: Daniel Klaffenbach Date: Fri Nov 19 21:25:21 2010 -0600 ssb: b43-pci-bridge: Add new vendor for BCM4318 commit 1d8638d4038eb8709edc80e37a0bbb77253d86e9 upstream. Add new vendor for Broadcom 4318. Signed-off-by: Daniel Klaffenbach Signed-off-by: Larry Finger Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit ab12abe612a82e395b47a2a9e2c6a42bae05b66a Author: Tejun Heo Date: Tue Jun 22 12:27:26 2010 +0200 ata_generic: implement ATA_GEN_* flags and force enable DMA on MBP 7,1 commit 1529c69adce1e95f7ae72f0441590c226bbac7fc upstream. IDE mode of MCP89 on MBP 7,1 doesn't set DMA enable bits in the BMDMA status register. Make the following changes to work around the problem. * Instead of using hard coded 1 in id->driver_data as class code match, use ATA_GEN_CLASS_MATCH and carry the matched id in host->private_data. * Instead of matching PCI_VENDOR_ID_CENATEK, use ATA_GEN_FORCE_DMA flag in id instead. * Add ATA_GEN_FORCE_DMA to the id entry of MBP 7,1. Signed-off-by: Tejun Heo Cc: Peer Chen Reported-by: Anders Østhus Reported-by: Andreas Graf Reported-by: Benoit Gschwind Reported-by: Damien Cassou Reported-by: tixetsal@juno.com Signed-off-by: Jeff Garzik Cc: Nobuhiro Iwamatsu Signed-off-by: Greg Kroah-Hartman commit 12683d690b40c7f76dd921a624c3879b49ab8bbd Author: Tejun Heo Date: Thu Jun 17 11:42:22 2010 +0200 ahci,ata_generic: let ata_generic handle new MBP w/ MCP89 commit c6353b4520788e34098bbf61c73fb9618ca7fdd6 upstream. For yet unknown reason, MCP89 on MBP 7,1 doesn't work w/ ahci under linux but the controller doesn't require explicit mode setting and works fine with ata_generic. Make ahci ignore the controller on MBP 7,1 and let ata_generic take it for now. Reported in bko#15923. https://bugzilla.kernel.org/show_bug.cgi?id=15923 NVIDIA is investigating why ahci mode doesn't work. Signed-off-by: Tejun Heo Cc: Peer Chen Reported-by: Anders Østhus Reported-by: Andreas Graf Reported-by: Benoit Gschwind Reported-by: Damien Cassou Reported-by: tixetsal@juno.com Signed-off-by: Jeff Garzik Cc: Nobuhiro Iwamatsu Signed-off-by: Greg Kroah-Hartman commit e36e20486efcf65b6f70ecf6a9043d714deb169f Author: KAMEZAWA Hiroyuki Date: Tue Oct 26 14:22:08 2010 -0700 mm: fix is_mem_section_removable() page_order BUG_ON check commit 572438f9b52236bd8938b1647cc15e027d27ef55 upstream. page_order() is called by memory hotplug's user interface to check the section is removable or not. (is_mem_section_removable()) It calls page_order() withoug holding zone->lock. So, even if the caller does if (PageBuddy(page)) ret = page_order(page) ... The caller may hit BUG_ON(). For fixing this, there are 2 choices. 1. add zone->lock. 2. remove BUG_ON(). is_mem_section_removable() is used for some "advice" and doesn't need to be 100% accurate. This is_removable() can be called via user program.. We don't want to take this important lock for long by user's request. So, this patch removes BUG_ON(). Signed-off-by: KAMEZAWA Hiroyuki Acked-by: Wu Fengguang Acked-by: Michal Hocko Acked-by: Mel Gorman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 76faf361cd7b76435137a99461df60a7d0b7c550 Author: KAMEZAWA Hiroyuki Date: Tue Oct 26 14:21:10 2010 -0700 mm: fix return value of scan_lru_pages in memory unplug commit f8f72ad5396987e05a42cf7eff826fb2a15ff148 upstream. scan_lru_pages returns pfn. So, it's type should be "unsigned long" not "int". Note: I guess this has been work until now because memory hotplug tester's machine has not very big memory.... physical address < 32bit << PAGE_SHIFT. Reported-by: KOSAKI Motohiro Signed-off-by: KAMEZAWA Hiroyuki Reviewed-by: KOSAKI Motohiro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit d8d8854fd00e3a3a5ad7ea9872d17c129e369564 Author: Jean Delvare Date: Thu Oct 28 20:31:50 2010 +0200 hwmon: (lm85) Fix ADT7468 frequency table commit fa7a5797e57d2ed71f9a6fb44f0ae42c2d7b74b7 upstream. The ADT7468 uses the same frequency table as the ADT7463. Signed-off-by: Jean Delvare Cc: Darrick J. Wong Acked-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 9a22026c32345ff03b8a5a7edc02dbf8c98aa51f Author: Eric Dumazet Date: Wed Oct 27 19:33:43 2010 +0200 numa: fix slab_node(MPOL_BIND) commit 800416f799e0723635ac2d720ad4449917a1481c upstream. When a node contains only HighMem memory, slab_node(MPOL_BIND) dereferences a NULL pointer. [ This code seems to go back all the way to commit 19770b32609b: "mm: filter based on a nodemask as well as a gfp_mask". Which was back in April 2008, and it got merged into 2.6.26. - Linus ] Signed-off-by: Eric Dumazet Cc: Mel Gorman Cc: Christoph Lameter Cc: Lee Schermerhorn Cc: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 87e8f969fc693c8ccb8ecb440634f84c87428fd7 Author: Richard Weinberger Date: Tue Oct 26 14:21:13 2010 -0700 um: fix global timer issue when using CONFIG_NO_HZ commit 482db6df1746c4fa7d64a2441d4cb2610249c679 upstream. This fixes a issue which was introduced by fe2cc53e ("uml: track and make up lost ticks"). timeval_to_ns() returns long long and not int. Due to that UML's timer did not work properlt and caused timer freezes. Signed-off-by: Richard Weinberger Acked-by: Pekka Enberg Cc: Jeff Dike Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit f412651038adcf93ed76a138a934a88481fecef5 Author: Richard Weinberger Date: Tue Oct 26 14:21:16 2010 -0700 um: remove PAGE_SIZE alignment in linker script causing kernel segfault. commit 6915e04f8847bea16d0890f559694ad8eedd026c upstream. The linker script cleanup that I did in commit 5d150a97f93 ("um: Clean up linker script using standard macros.") (2.6.32) accidentally introduced an ALIGN(PAGE_SIZE) when converting to use INIT_TEXT_SECTION; Richard Weinberger reported that this causes the kernel to segfault with CONFIG_STATIC_LINK=y. I'm not certain why this extra alignment is a problem, but it seems likely it is because previously __init_begin = _stext = _text = _sinittext and with the extra ALIGN(PAGE_SIZE), _sinittext becomes different from the rest. So there is likely a bug here where something is assuming that _sinittext is the same as one of those other symbols. But reverting the accidental change fixes the regression, so it seems worth committing that now. Signed-off-by: Tim Abbott Reported-by: Richard Weinberger Cc: Jeff Dike Tested by: Antoine Martin Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 9cb6e108516a0ec5373066923249c70786a26562 Author: Masanori ITOH Date: Tue Oct 26 14:21:20 2010 -0700 percpu: fix list_head init bug in __percpu_counter_init() commit 8474b591faf3bb0a1e08a60d21d6baac498f15e4 upstream. WARNING: at lib/list_debug.c:26 __list_add+0x3f/0x81() Hardware name: Express5800/B120a [N8400-085] list_add corruption. next->prev should be prev (ffffffff81a7ea00), but was dead000000200200. (next=ffff88080b872d58). Modules linked in: aoe ipt_MASQUERADE iptable_nat nf_nat autofs4 sunrpc bridge 8021q garp stp llc ipv6 cpufreq_ondemand acpi_cpufreq freq_table dm_round_robin dm_multipath kvm_intel kvm uinput lpfc scsi_transport_fc igb ioatdma scsi_tgt i2c_i801 i2c_core dca iTCO_wdt iTCO_vendor_support pcspkr shpchp megaraid_sas [last unloaded: aoe] Pid: 54, comm: events/3 Tainted: G W 2.6.34-vanilla1 #1 Call Trace: [] warn_slowpath_common+0x7c/0x94 [] warn_slowpath_fmt+0x41/0x43 [] __list_add+0x3f/0x81 [] __percpu_counter_init+0x59/0x6b [] bdi_init+0x118/0x17e [] blk_alloc_queue_node+0x79/0x143 [] blk_alloc_queue+0x11/0x13 [] aoeblk_gdalloc+0x8e/0x1c9 [aoe] [] aoecmd_sleepwork+0x25/0xa8 [aoe] [] worker_thread+0x1a9/0x237 [] ? aoecmd_sleepwork+0x0/0xa8 [aoe] [] ? autoremove_wake_function+0x0/0x39 [] ? worker_thread+0x0/0x237 [] kthread+0x7f/0x87 [] kernel_thread_helper+0x4/0x10 [] ? kthread+0x0/0x87 [] ? kernel_thread_helper+0x0/0x10 It's because there is no initialization code for a list_head contained in the struct backing_dev_info under CONFIG_HOTPLUG_CPU, and the bug comes up when block device drivers calling blk_alloc_queue() are used. In case of me, I got them by using aoe. Signed-off-by: Masanori Itoh Cc: Tejun Heo Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit f67e4460bc1d537fc560260a37497e11dac8bbe6 Author: Richard A. Smith Date: Sat Sep 25 19:19:26 2010 +0100 olpc_battery: Fix endian neutral breakage for s16 values commit 7cfbb29466633e6ecdc14f76a693c8478c2b22af upstream. When the driver was updated to be endian neutral (8e9c7716c) the signed part of the s16 values was lost. This is because be16_to_cpu() returns an unsigned value. This patch casts the values back to a s16 number prior to the the implicit cast up to an int. Signed-off-by: Richard A. Smith Signed-off-by: Daniel Drake Signed-off-by: Anton Vorontsov Signed-off-by: Greg Kroah-Hartman commit ede95dde4625bd00afdaaa479a2d5cfee1a49555 Author: Jiri Slaby Date: Tue Oct 26 14:22:11 2010 -0700 hpet: unmap unused I/O space commit a56d5318716d120e040294bb258901ba89fb9c90 upstream. When the initialization code in hpet finds a memory resource and does not find an IRQ, it does not unmap the memory resource previously mapped. There are buggy BIOSes which report resources exactly like this and what is worse the memory region bases point to normal RAM. This normally would not matter since the space is not touched. But when PAT is turned on, ioremap causes the page to be uncached and sets this bit in page->flags. Then when the page is about to be used by the allocator, it is reported as: BUG: Bad page state in process md5sum pfn:3ed00 page:ffffea0000dbd800 count:0 mapcount:0 mapping:(null) index:0x0 page flags: 0x20000001000000(uncached) Pid: 7956, comm: md5sum Not tainted 2.6.34-12-desktop #1 Call Trace: [] bad_page+0xb1/0x100 [] prep_new_page+0x1a5/0x1c0 [] get_page_from_freelist+0x3a1/0x640 [] __alloc_pages_nodemask+0x10f/0x6b0 ... In this particular case: 1) HPET returns 3ed00000 as memory region base, but it is not in reserved ranges reported by the BIOS (excerpt): BIOS-e820: 0000000000100000 - 00000000af6cf000 (usable) BIOS-e820: 00000000af6cf000 - 00000000afdcf000 (reserved) 2) there is no IRQ resource reported by HPET method. On the other hand, the Intel HPET specs (1.0a) says (3.2.5.1): _CRS ( // Report 1K of memory consumed by this Timer Block memory range consumed // Optional: only used if BIOS allocates Interrupts [1] IRQs consumed ) [1] For case where Timer Block is configured to consume IRQ0/IRQ8 AND Legacy 8254/Legacy RTC hardware still exists, the device objects associated with 8254 & RTC devices should not report IRQ0/IRQ8 as "consumed resources". So in theory we should check whether if it is the case and use those interrupts instead. Anyway the address reported by the BIOS here is bogus, so non-presence of IRQ doesn't mean the "optional" part in point 2). Since I got no reply previously, fix this by simply unmapping the space when IRQ is not found and memory region was mapped previously. It would be probably more safe to walk the resources again and unmap appropriately depending on type. But as we now use only ioremap for both 2 memory resource types, it is not necessarily needed right now. Addresses https://bugzilla.novell.com/show_bug.cgi?id=629908 Reported-by: Olaf Hering Signed-off-by: Jiri Slaby Acked-by: Clemens Ladisch Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 0256a79e5c86c57bbeffcb78bec780ebed635dfb Author: Clemens Ladisch Date: Tue Oct 26 14:22:13 2010 -0700 hpet: fix unwanted interrupt due to stale irq status bit commit 96e9694df446d1154ec2f4fdba8908588b9cba38 upstream. Jaswinder Singh Rajput wrote: > By executing Documentation/timers/hpet_example.c > > for polling, I requested for 3 iterations but it seems iteration work > for only 2 as first expired time is always very small. > > # ./hpet_example poll /dev/hpet 10 3 > -hpet: executing poll > hpet_poll: info.hi_flags 0x0 > hpet_poll: expired time = 0x13 > hpet_poll: revents = 0x1 > hpet_poll: data 0x1 > hpet_poll: expired time = 0x1868c > hpet_poll: revents = 0x1 > hpet_poll: data 0x1 > hpet_poll: expired time = 0x18645 > hpet_poll: revents = 0x1 > hpet_poll: data 0x1 Clearing the HPET interrupt enable bit disables interrupt generation but does not disable the timer, so the interrupt status bit will still be set when the timer elapses. If another interrupt arrives before the timer has been correctly programmed (due to some other device on the same interrupt line, or CONFIG_DEBUG_SHIRQ), this results in an extra unwanted interrupt event because the status bit is likely to be set from comparator matches that happened before the device was opened. Therefore, we have to ensure that the interrupt status bit is and stays cleared until we actually program the timer. Signed-off-by: Clemens Ladisch Reported-by: Jaswinder Singh Rajput Cc: Ingo Molnar Cc: Thomas Gleixner Cc: john stultz Cc: Bob Picco Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 27ea78356e23cc5ea5526053a5e77ef75b201d35 Author: Greg Kroah-Hartman Date: Tue Nov 16 11:23:33 2010 -0800 Staging: line6: fix up some sysfs attribute permissions commit 2018845b6a169f75341f8e68ad1089cb6697cf24 and 2018845b6a169f75341f8e68ad1089cb6697cf24 upstream merged together as it had to be backported by hand. They should not be writable by any user Reported-by: Linus Torvalds Cc: Markus Grabner Cc: Mariusz Kozlowski Signed-off-by: Greg Kroah-Hartman commit 6499b1cf0f2edb16de1c912ce9bd3817bb086220 Author: Greg Kroah-Hartman Date: Thu Nov 18 11:21:04 2010 -0800 Staging: asus_oled: fix up my fixup for some sysfs attribute permissions commit 515b4987ccd097cdf5416530b05fdf9e01afe95a upstream. They should be writable by root, not readable. Doh, stupid me with the wrong flags. Reported-by: Jonathan Cameron Cc: Jakub Schmidtke Signed-off-by: Greg Kroah-Hartman commit a0b8967c004ec42a7d8756aaff5ef48d69a34520 Author: Greg Kroah-Hartman Date: Tue Nov 16 11:17:01 2010 -0800 Staging: asus_oled: fix up some sysfs attribute permissions commit 590b0b9754bd8928926bae7194b6da7ead9bda3b upstream. They should not be writable by any user Reported-by: Linus Torvalds Cc: Jakub Schmidtke Signed-off-by: Greg Kroah-Hartman commit 5c98bcd65f0b27bc36dddbc1c9fe8222ceefc701 Author: Kees Cook Date: Thu Oct 7 10:03:48 2010 +0000 net: clear heap allocation for ETHTOOL_GRXCLSRLALL commit ae6df5f96a51818d6376da5307d773baeece4014 upstream. Calling ETHTOOL_GRXCLSRLALL with a large rule_cnt will allocate kernel heap without clearing it. For the one driver (niu) that implements it, it will leave the unused portion of heap unchanged and copy the full contents back to userspace. Signed-off-by: Kees Cook Acked-by: Ben Hutchings Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 8993c9cb58ba247dd3c1563689010a660ce86d41 Author: Thomas Backlund Date: Thu Oct 21 13:19:10 2010 +0300 microblaze: Fix build with make 3.82 commit b843e4ec01991a386a9e0e9030703524446e03da upstream. When running make headers_install_all on x86_64 and make 3.82 I hit this: arch/microblaze/Makefile:80: *** mixed implicit and normal rules. Stop. make: *** [headers_install_all] Error 2 So split the rules to satisfy make 3.82. Signed-off-by: Thomas Backlund Signed-off-by: Michal Simek Signed-off-by: Greg Kroah-Hartman commit 363feffb2efa74bde2015b97bdf53deda6871d2d Author: Nobuhiro Iwamatsu Date: Sun Oct 24 18:16:57 2010 +0200 i2c-pca-platform: Change device name of request_irq commit 323584436db0cb05286425d4dfd9516fce88487f upstream. i2c->adap.name shouldn't be used in request_irq. Instead the driver name "i2c-pca-platform" should be used. Signed-off-by: Nobuhiro Iwamatsu Acked-by: Wolfram Sang Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit 7a263a4d8dacd7cc9f1e90e1b6e9a2e16ea22031 Author: Samuel Ortiz Date: Wed Oct 6 01:03:12 2010 +0200 irda: Fix heap memory corruption in iriap.c commit 37f9fc452d138dfc4da2ee1ce5ae85094efc3606 upstream. While parsing the GetValuebyClass command frame, we could potentially write passed the skb->data pointer. Reported-by: Ilja Van Sprundel Signed-off-by: Samuel Ortiz Signed-off-by: Greg Kroah-Hartman commit 3d72a94653ce5dbb54db04c3f60c840d1718265a Author: Samuel Ortiz Date: Mon Oct 11 01:17:56 2010 +0200 irda: Fix parameter extraction stack overflow commit efc463eb508798da4243625b08c7396462cabf9f upstream. Reported-by: Ilja Van Sprundel Signed-off-by: Samuel Ortiz Signed-off-by: Greg Kroah-Hartman commit 27f033bade67d58301da8bce21b9c839a24987d5 Author: Guo-Fu Tseng Date: Mon Oct 18 14:10:40 2010 +0000 jme: Fix PHY power-off error commit c8a8684d5cfb0f110a962c93586630c0bf91ebc1 upstream. Adding phy_on in opposition to phy_off. Signed-off-by: Guo-Fu Tseng Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6e1fc7a18ebfa14bac5a1566651ee6474cbb9af4 Author: Jens Axboe Date: Fri Oct 29 08:10:18 2010 -0600 block: check for proper length of iov entries in blk_rq_map_user_iov() commit 9284bcf4e335e5f18a8bc7b26461c33ab60d0689 upstream. Ensure that we pass down properly validated iov segments before calling into the mapping or copy functions. Reported-by: Dan Rosenberg Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 239023a9d11fa1be4fec0adc4d9b840c4b815775 Author: Jens Axboe Date: Fri Oct 29 11:31:42 2010 -0600 block: take care not to overflow when calculating total iov length commit 9f864c80913467312c7b8690e41fb5ebd1b50e92 upstream. Reported-by: Dan Rosenberg Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 870cd3681836a2e822090522c8cb6fce19cf9e5c Author: Jens Axboe Date: Fri Oct 29 11:46:56 2010 -0600 block: limit vec count in bio_kmalloc() and bio_alloc_map_data() commit f3f63c1c28bc861a931fac283b5bc3585efb8967 upstream. Reported-by: Dan Rosenberg Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit a4340113f9a3a4ebcbf988f1c1a27c07d70185b9 Author: Martin K. Petersen Date: Wed Oct 13 21:18:03 2010 +0200 block: Ensure physical block size is unsigned int commit 892b6f90db81cccb723d5d92f4fddc2d68b206e1 upstream. Physical block size was declared unsigned int to accomodate the maximum size reported by READ CAPACITY(16). Make sure we use the right type in the related functions. Signed-off-by: Martin K. Petersen Acked-by: Mike Snitzer Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman