commit 02905906ddc049720ded93ded03bbc2652f4646a Author: Greg Kroah-Hartman Date: Fri Mar 23 13:54:45 2012 -0700 Linux 3.2.13 commit 8d7548704a1a6b6dacd6b458897007de80a820b3 Author: Benjamin Herrenschmidt Date: Fri Dec 9 15:06:18 2011 +1100 powerpc/pmac: Fix SMP kernels on pre-core99 UP machines commit 78c5c68a4cf4329d17abfa469345ddf323d4fd62 upstream. The code for "powersurge" SMP would kick in and cause a crash at boot due to the lack of a NULL test. Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Jeremy Kerr Reported-by: Adam Conrad Tested-by: Adam Conrad Signed-off-by: Greg Kroah-Hartman commit a4599a9b8c0189e7db0ca426f107e2c0d1f472bd Author: Stanislaw Gruszka Date: Thu Mar 8 13:16:01 2012 +0100 iwl3945: fix possible il->txq NULL pointer dereference in delayed works commit 210787e82a0ac1ffb5d7be1c796f0c51050849ad upstream. On il3945_down procedure we free tx queue data and nullify il->txq pointer. After that we drop mutex and then cancel delayed works. There is possibility, that after drooping mutex and before the cancel, some delayed work will start and crash while trying to send commands to the device. For example, here is reported crash in il3945_bg_reg_txpower_periodic(): https://bugzilla.kernel.org/show_bug.cgi?id=42766#c10 Patch fix problem by adding il->txq check on works that send commands, hence utilize tx queue. Reported-by: Clemens Eisserer Signed-off-by: Stanislaw Gruszka Signed-off-by: John W. Linville commit 3634665532be2d0b3281e9a6a9159dfa7f1d699d Author: RongQing.Li Date: Thu Mar 15 22:54:14 2012 +0000 ipv6: Don't dev_hold(dev) in ip6_mc_find_dev_rcu. [ Upstream commit c577923756b7fe9071f28a76b66b83b306d1d001 ] ip6_mc_find_dev_rcu() is called with rcu_read_lock(), so don't need to dev_hold(). With dev_hold(), not corresponding dev_put(), will lead to leak. [ bug introduced in 96b52e61be1 (ipv6: mcast: RCU conversions) ] Signed-off-by: RongQing.Li Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit cc28ae50b8dad51b597d56b74004c3be46c34406 Author: Eric Dumazet Date: Sat Mar 10 09:20:21 2012 +0000 tcp: fix syncookie regression [ Upstream commit dfd25ffffc132c00070eed64200e8950da5d7e9d ] commit ea4fc0d619 (ipv4: Don't use rt->rt_{src,dst} in ip_queue_xmit()) added a serious regression on synflood handling. Simon Kirby discovered a successful connection was delayed by 20 seconds before being responsive. In my tests, I discovered that xmit frames were lost, and needed ~4 retransmits and a socket dst rebuild before being really sent. In case of syncookie initiated connection, we use a different path to initialize the socket dst, and inet->cork.fl.u.ip4 is left cleared. As ip_queue_xmit() now depends on inet flow being setup, fix this by copying the temp flowi4 we use in cookie_v4_check(). Reported-by: Simon Kirby Bisected-by: Simon Kirby Signed-off-by: Eric Dumazet Tested-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 74ace0235c443b01852a226558a262925fe5348d Author: Arnaldo Carvalho de Melo Date: Wed Mar 14 12:29:29 2012 -0300 perf tools: Use scnprintf where applicable commit e7f01d1e3d8d501deb8abeaa269d5d48a703b8b0 upstream. Several places were expecting that the value returned was the number of characters printed, not what would be printed if there was space. Fix it by using the scnprintf and vscnprintf variants we inherited from the kernel sources. Some corner cases where the number of printed characters were not accounted were fixed too. Reported-by: Anton Blanchard Cc: Anton Blanchard Cc: Eric B Munson Cc: David Ahern Cc: Frederic Weisbecker Cc: Mike Galbraith Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Yanmin Zhang Link: http://lkml.kernel.org/n/tip-kwxo2eh29cxmd8ilixi2005x@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 460e2faa3a051fa4cb3aacb6ef47c71845bcf6bb Author: Anton Blanchard Date: Wed Mar 7 11:42:49 2012 +1100 perf tools: Incorrect use of snprintf results in SEGV commit b832796caa1fda8516464a003c8c7cc547bc20c2 upstream. I have a workload where perf top scribbles over the stack and we SEGV. What makes it interesting is that an snprintf is causing this. The workload is a c++ gem that has method names over 3000 characters long, but snprintf is designed to avoid overrunning buffers. So what went wrong? The problem is we assume snprintf returns the number of characters written: ret += repsep_snprintf(bf + ret, size - ret, "[%c] ", self->level); ... ret += repsep_snprintf(bf + ret, size - ret, "%s", self->ms.sym->name); Unfortunately this is not how snprintf works. snprintf returns the number of characters that would have been written if there was enough space. In the above case, if the first snprintf returns a value larger than size, we pass a negative size into the second snprintf and happily scribble over the stack. If you have 3000 character c++ methods thats a lot of stack to trample. This patch fixes repsep_snprintf by clamping the value at size - 1 which is the maximum snprintf can write before adding the NULL terminator. I get the sinking feeling that there are a lot of other uses of snprintf that have this same bug, we should audit them all. Cc: David Ahern Cc: Eric B Munson Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Yanmin Zhang Link: http://lkml.kernel.org/r/20120307114249.44275ca3@kryten Signed-off-by: Anton Blanchard Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit a3e7dddf9d7dd2e98f015b96afa343da370e8468 Author: Anton Blanchard Date: Fri Mar 16 10:28:19 2012 +0000 afs: Remote abort can cause BUG in rxrpc code commit c0173863528a8c9212c53e080d63a1aaae5ef4f4 upstream. When writing files to afs I sometimes hit a BUG: kernel BUG at fs/afs/rxrpc.c:179! With a backtrace of: afs_free_call afs_make_call afs_fs_store_data afs_vnode_store_data afs_write_back_from_locked_page afs_writepages_region afs_writepages The cause is: ASSERT(skb_queue_empty(&call->rx_queue)); Looking at a tcpdump of the session the abort happens because we are exceeding our disk quota: rx abort fs reply store-data error diskquota exceeded (32) So the abort error is valid. We hit the BUG because we haven't freed all the resources for the call. By freeing any skbs in call->rx_queue before calling afs_free_call we avoid hitting leaking memory and avoid hitting the BUG. Signed-off-by: Anton Blanchard Signed-off-by: David Howells Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 3b17e8051322d7ea54e6548606b9eb3a2d694919 Author: Anton Blanchard Date: Fri Mar 16 10:28:07 2012 +0000 afs: Read of file returns EBADMSG commit 2c724fb92732c0b2a5629eb8af74e82eb62ac947 upstream. A read of a large file on an afs mount failed: # cat junk.file > /dev/null cat: junk.file: Bad message Looking at the trace, call->offset wrapped since it is only an unsigned short. In afs_extract_data: _enter("{%u},{%zu},%d,,%zu", call->offset, len, last, count); ... if (call->offset < count) { if (last) { _leave(" = -EBADMSG [%d < %zu]", call->offset, count); return -EBADMSG; } Which matches the trace: [cat ] ==> afs_extract_data({65132},{524},1,,65536) [cat ] <== afs_extract_data() = -EBADMSG [0 < 65536] call->offset went from 65132 to 0. Fix this by making call->offset an unsigned int. Signed-off-by: Anton Blanchard Signed-off-by: David Howells Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 6637749c3700e68ce8d5f28a096327e8b1d5b9ab Author: Ryusuke Konishi Date: Fri Mar 16 17:08:39 2012 -0700 nilfs2: fix NULL pointer dereference in nilfs_load_super_block() commit d7178c79d9b7c5518f9943188091a75fc6ce0675 upstream. According to the report from Slicky Devil, nilfs caused kernel oops at nilfs_load_super_block function during mount after he shrank the partition without resizing the filesystem: BUG: unable to handle kernel NULL pointer dereference at 00000048 IP: [] nilfs_load_super_block+0x17e/0x280 [nilfs2] *pde = 00000000 Oops: 0000 [#1] PREEMPT SMP ... Call Trace: [] init_nilfs+0x4b/0x2e0 [nilfs2] [] nilfs_mount+0x447/0x5b0 [nilfs2] [] mount_fs+0x36/0x180 [] vfs_kern_mount+0x51/0xa0 [] do_kern_mount+0x3e/0xe0 [] do_mount+0x169/0x700 [] sys_mount+0x6b/0xa0 [] sysenter_do_call+0x12/0x28 Code: 53 18 8b 43 20 89 4b 18 8b 4b 24 89 53 1c 89 43 24 89 4b 20 8b 43 20 c7 43 2c 00 00 00 00 23 75 e8 8b 50 68 89 53 28 8b 54 b3 20 <8b> 72 48 8b 7a 4c 8b 55 08 89 b3 84 00 00 00 89 bb 88 00 00 00 EIP: [] nilfs_load_super_block+0x17e/0x280 [nilfs2] SS:ESP 0068:ca9bbdcc CR2: 0000000000000048 This turned out due to a defect in an error path which runs if the calculated location of the secondary super block was invalid. This patch fixes it and eliminates the reported oops. Reported-by: Slicky Devil Signed-off-by: Ryusuke Konishi Tested-by: Slicky Devil Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman