commit 6f493a57eac5fa655560c7a69f2aefa211927081 Author: Willy Tarreau Date: Fri Sep 18 13:51:49 2015 +0200 Linux 2.6.32.68 Signed-off-by: Willy Tarreau commit 9e0d75484e14aa5256cb364db0fb49a05f6b83e9 Author: David S. Miller Date: Tue May 24 01:11:51 2011 -0400 ipv6: Fix return of xfrm6_tunnel_rcv() commit 6ac3f6649223d916bbdf1e823926f8f3b34b5d99 upstream. Like ipv4, just return xfrm6_rcv_spi()'s return value directly. Signed-off-by: David S. Miller Signed-off-by: Willy Tarreau commit 17fce98016a7d200c691440da403cc65369657d4 Author: Dr. David Alan Gilbert Date: Thu Aug 25 16:13:55 2011 -0700 dmaengine: fix missing 'cnt' in ?: in dmatest commit d07a74a546981a09ba490936645fbf0d1340b96c upstream. Hi, On the latest tree my compiler has started giving the warning: drivers/dma/dmatest.c:575:28: warning: the omitted middle operand in ?: will always be ?true?, suggest explicit middle operand [-Wparentheses] The following patch fixes the missing middle clause with the same fix that Nicolas Ferre used in the similar clauses. (There seems to have been a race between him fixing that and the extra clause going in a little later). I don't actually know the dmatest code/structures, nor do I own any hardware to test it on (assuming it needs a DMA engine); but this patch builds, the existing code is almost certainly wrong and the fix is the same as the corresponding lines above it. (WTH is x=y?:z legal C anyway?) Signed-off-by: Dr. David Alan Gilbert Reported-by: Dan Carpenter Reported-by: Paul Gortmaker Acked-by: Nicolas Ferre Signed-off-by: Dan Williams Signed-off-by: Willy Tarreau commit 66edde86393c49d5a1897d209739ebf2066b48df Author: Wang Weidong Date: Tue Dec 17 19:24:33 2013 -0700 dccp: catch failed request_module call in dccp_probe init commit 965cdea825693c821d200e38fac9402cde6dce6a upstream. Check the return value of request_module during dccp_probe initialisation, bail out if that call fails. Signed-off-by: Gerrit Renker Signed-off-by: Wang Weidong Signed-off-by: David S. Miller Signed-off-by: Willy Tarreau commit 7ec212036c1e1400dace9b1aa64543c91f854705 Author: David S. Miller Date: Thu Dec 1 14:45:49 2011 -0500 dccp: Fix compile warning in probe code. commit d984e6197ecd2babc1537f42dc1e676133005cda upstream. Commit 1386be55e32a3c5d8ef4a2b243c530a7b664c02c ("dccp: fix auto-loading of dccp(_probe)") fixed a bug but created a new compiler warning: net/dccp/probe.c: In function ‘dccpprobe_init’: net/dccp/probe.c:166:2: warning: the omitted middle operand in ?: will always be ‘true’, suggest explicit middle operand [-Wparentheses] try_then_request_module() is built for situations where the "existence" test is some lookup function that returns a non-NULL object on success, and with a reference count of some kind held. Here we're looking for a success return of zero from the jprobe registry. Instead of fighting the way try_then_request_module() works, simply open code what we want to happen in a local helper function. Signed-off-by: David S. Miller Signed-off-by: Willy Tarreau commit c5e8459bd607a2b7c9a86ae4414f32ce3a7b3b62 Author: Gerrit Renker Date: Tue Feb 2 20:16:56 2010 +0000 dccp: fix auto-loading of dccp(_probe) commit 1386be55e32a3c5d8ef4a2b243c530a7b664c02c upstream. This fixes commit (38ff3e6bb987ec583268da8eb22628293095d43b) ("dccp_probe: Fix module load dependencies between dccp and dccp_probe", from 15 Jan). It fixes the construction of the first argument of try_then_request_module(), where only valid return codes from the first argument should be returned. What we do now is assign the result of register_jprobe() to ret, without the side effect of the comparison. Acked-by: Gerrit Renker Signed-off-by: Neil Horman Signed-off-by: David S. Miller Signed-off-by: Willy Tarreau commit 9b2aa6e28493bfa3a94ecaa8486937b568df0e31 Author: Andy Lutomirski Date: Thu Jul 30 14:31:31 2015 -0700 x86/xen: Probe target addresses in set_aliased_prot() before the hypercall commit aa1acff356bbedfd03b544051f5b371746735d89 upstream. The update_va_mapping hypercall can fail if the VA isn't present in the guest's page tables. Under certain loads, this can result in an OOPS when the target address is in unpopulated vmap space. While we're at it, add comments to help explain what's going on. This isn't a great long-term fix. This code should probably be changed to use something like set_memory_ro. Signed-off-by: Andy Lutomirski Cc: Andrew Cooper Cc: Andy Lutomirski Cc: Boris Ostrovsky Cc: Borislav Petkov Cc: Brian Gerst Cc: David Vrabel Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Jan Beulich Cc: Konrad Rzeszutek Wilk Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Sasha Levin Cc: Steven Rostedt Cc: Thomas Gleixner Cc: security@kernel.org Cc: xen-devel Link: http://lkml.kernel.org/r/0b0e55b995cda11e7829f140b833ef932fcabe3a.1438291540.git.luto@kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Ben Hutchings (cherry picked from commit b48d6a721ba2cb475aea937c707f577aafa660a2) Signed-off-by: Willy Tarreau commit 6f3539b43391809847326d157378609310c2a180 Author: Mikulas Patocka Date: Wed Jul 8 13:06:12 2015 -0400 libata: increase the timeout when setting transfer mode commit d531be2ca2f27cca5f041b6a140504999144a617 upstream. I have a ST4000DM000 disk. If Linux is booted while the disk is spun down, the command that sets transfer mode causes the disk to spin up. The spin-up takes longer than the default 5s timeout, so the command fails and timeout is reported. Fix this by increasing the timeout to 15s, which is enough for the disk to spin up. Signed-off-by: Mikulas Patocka Signed-off-by: Tejun Heo Signed-off-by: Ben Hutchings (cherry picked from commit d6ded32444c070ce41ad0d64fce8957d18009d72) Signed-off-by: Willy Tarreau commit 13ae66d58fb92603de95f6cc8ac2e62cec3c59c4 Author: Heiko Carstens Date: Mon Jul 6 15:02:37 2015 +0200 s390/process: fix sfpc inline assembly commit e47994dd44bcb4a77b4152bd0eada585934703c0 upstream. The sfpc inline assembly within execve_tail() may incorrectly set bits 28-31 of the sfpc instruction to a value which is not zero. These bits however are currently unused and therefore should be zero so we won't get surprised if these bits will be used in the future. Therefore remove the second operand from the inline assembly. Signed-off-by: Heiko Carstens Signed-off-by: Martin Schwidefsky [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings (cherry picked from commit b411a8a3b44d76e782ba4bc6893068f3f590fe8a) Signed-off-by: Willy Tarreau commit f85457f8be43e6fb2796d4728cc01806415acc51 Author: Kirill A. Shutemov Date: Mon Jul 6 23:18:37 2015 +0300 mm: avoid setting up anonymous pages into file mapping commit 6b7339f4c31ad69c8e9c0b2859276e22cf72176d upstream. Reading page fault handler code I've noticed that under right circumstances kernel would map anonymous pages into file mappings: if the VMA doesn't have vm_ops->fault() and the VMA wasn't fully populated on ->mmap(), kernel would handle page fault to not populated pte with do_anonymous_page(). Let's change page fault handler to use do_anonymous_page() only on anonymous VMA (->vm_ops == NULL) and make sure that the VMA is not shared. For file mappings without vm_ops->fault() or shred VMA without vm_ops, page fault on pte_none() entry would lead to SIGBUS. Signed-off-by: Kirill A. Shutemov Acked-by: Oleg Nesterov Cc: Andrew Morton Cc: Willy Tarreau Signed-off-by: Linus Torvalds [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings (cherry picked from commit e2506476534cff7bb3697fbe0654fdefd101bc80) Signed-off-by: Willy Tarreau commit 9e5594d2355aa943785206cb7634826f77547253 Author: Miklos Szeredi Date: Wed Jul 1 16:25:55 2015 +0200 fuse: initialize fc->release before calling it commit 0ad0b3255a08020eaf50e34ef0d6df5bdf5e09ed upstream. fc->release is called from fuse_conn_put() which was used in the error cleanup before fc->release was initialized. [Jeremiah Mahler : assign fc->release after calling fuse_conn_init(fc) instead of before.] Signed-off-by: Miklos Szeredi Fixes: a325f9b92273 ("fuse: update fuse_conn_init() and separate out fuse_conn_kill()") Signed-off-by: Ben Hutchings (cherry picked from commit 1a713f9828a6abd288ecc9eef0bbe5c56d0ffc0b) Signed-off-by: Willy Tarreau commit 0c301ef6ace4b60c4d4016492a192e72496fefb1 Author: Steven Rostedt (Red Hat) Date: Thu Jun 25 18:10:09 2015 -0400 tracing/filter: Do not allow infix to exceed end of string commit 6b88f44e161b9ee2a803e5b2b1fbcf4e20e8b980 upstream. While debugging a WARN_ON() for filtering, I found that it is possible for the filter string to be referenced after its end. With the filter: # echo '>' > /sys/kernel/debug/events/ext4/ext4_truncate_exit/filter The filter_parse() function can call infix_get_op() which calls infix_advance() that updates the infix filter pointers for the cnt and tail without checking if the filter is already at the end, which will put the cnt to zero and the tail beyond the end. The loop then calls infix_next() that has ps->infix.cnt--; return ps->infix.string[ps->infix.tail++]; The cnt will now be below zero, and the tail that is returned is already passed the end of the filter string. So far the allocation of the filter string usually has some buffer that is zeroed out, but if the filter string is of the exact size of the allocated buffer there's no guarantee that the charater after the nul terminating character will be zero. Luckily, only root can write to the filter. Signed-off-by: Steven Rostedt Signed-off-by: Ben Hutchings (cherry picked from commit 7cc2315e7b9c148ee549d4cfbf68735a578b64db) Signed-off-by: Willy Tarreau commit 8f2f643048d52d0d2eef33fd97f863840e8f0fb9 Author: Steven Rostedt (Red Hat) Date: Thu Jun 25 18:02:29 2015 -0400 tracing/filter: Do not WARN on operand count going below zero commit b4875bbe7e68f139bd3383828ae8e994a0df6d28 upstream. When testing the fix for the trace filter, I could not come up with a scenario where the operand count goes below zero, so I added a WARN_ON_ONCE(cnt < 0) to the logic. But there is legitimate case that it can happen (although the filter would be wrong). # echo '>' > /sys/kernel/debug/events/ext4/ext4_truncate_exit/filter That is, a single operation without any operands will hit the path where the WARN_ON_ONCE() can trigger. Although this is harmless, and the filter is reported as a error. But instead of spitting out a warning to the kernel dmesg, just fail nicely and report it via the proper channels. Link: http://lkml.kernel.org/r/558C6082.90608@oracle.com Reported-by: Vince Weaver Reported-by: Sasha Levin Signed-off-by: Steven Rostedt Signed-off-by: Ben Hutchings (cherry picked from commit b43dd35952747f563d0dec7aefb7570260f10353) Signed-off-by: Willy Tarreau commit e18af8563578c0d292bef9a3f3c0206242f742e5 Author: Catalin Marinas Date: Wed Jun 24 16:58:26 2015 -0700 mm: kmemleak: allow safe memory scanning during kmemleak disabling commit c5f3b1a51a591c18c8b33983908e7fdda6ae417e upstream. The kmemleak scanning thread can run for minutes. Callbacks like kmemleak_free() are allowed during this time, the race being taken care of by the object->lock spinlock. Such lock also prevents a memory block from being freed or unmapped while it is being scanned by blocking the kmemleak_free() -> ... -> __delete_object() function until the lock is released in scan_object(). When a kmemleak error occurs (e.g. it fails to allocate its metadata), kmemleak_enabled is set and __delete_object() is no longer called on freed objects. If kmemleak_scan is running at the same time, kmemleak_free() no longer waits for the object scanning to complete, allowing the corresponding memory block to be freed or unmapped (in the case of vfree()). This leads to kmemleak_scan potentially triggering a page fault. This patch separates the kmemleak_free() enabling/disabling from the overall kmemleak_enabled nob so that we can defer the disabling of the object freeing tracking until the scanning thread completed. The kmemleak_free_part() is deliberately ignored by this patch since this is only called during boot before the scanning thread started. Signed-off-by: Catalin Marinas Reported-by: Vignesh Radhakrishnan Tested-by: Vignesh Radhakrishnan Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds [bwh: Backported to 3.2: - Adjust context - Drop changes to kmemleak_free_percpu()] Signed-off-by: Ben Hutchings (cherry picked from commit 3bc68ffc5b43468537a2f0aa415f3b57f3b19d16) Signed-off-by: Willy Tarreau commit 7b61d03d0469e6771280da41a638bfe9c7169129 Author: Ralf Baechle Date: Fri Jun 19 00:46:53 2015 +0200 NET: ROSE: Don't dereference NULL neighbour pointer. commit d496f7842aada20c61e6044b3395383fa972872c upstream. A ROSE socket doesn't necessarily always have a neighbour pointer so check if the neighbour pointer is valid before dereferencing it. Signed-off-by: Ralf Baechle Tested-by: Bernard Pidoux Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings (cherry picked from commit 8bbe4f448c01949084ef404eded3622086f052a6) Signed-off-by: Willy Tarreau commit c726e1d46177df427482b0b3e0f758083f83c50f Author: Theodore Ts'o Date: Sat Jun 20 22:50:33 2015 -0400 ext4: call sync_blockdev() before invalidate_bdev() in put_super() commit 89d96a6f8e6491f24fc8f99fd6ae66820e85c6c1 upstream. Normally all of the buffers will have been forced out to disk before we call invalidate_bdev(), but there will be some cases, where a file system operation was aborted due to an ext4_error(), where there may still be some dirty buffers in the buffer cache for the device. So try to force them out to memory before calling invalidate_bdev(). This fixes a warning triggered by generic/081: WARNING: CPU: 1 PID: 3473 at /usr/projects/linux/ext4/fs/block_dev.c:56 __blkdev_put+0xb5/0x16f() Signed-off-by: Theodore Ts'o Signed-off-by: Ben Hutchings (cherry picked from commit 5dedaea4936981382ec0d9833ad372ebd3d8af57) Signed-off-by: Willy Tarreau commit d2d8cee6fdfec9355f41e35ab6a06d085f23ec58 Author: Jeff Layton Date: Tue Jun 9 19:43:56 2015 -0400 nfs: increase size of EXCHANGE_ID name string buffer commit 764ad8ba8cd4c6f836fca9378f8c5121aece0842 upstream. The current buffer is much too small if you have a relatively long hostname. Bring it up to the size of the one that SETCLIENTID has. Reported-by: Michael Skralivetsky Signed-off-by: Jeff Layton Signed-off-by: Trond Myklebust Signed-off-by: Ben Hutchings (cherry picked from commit ef24842ca0c24ef7223a0853f7603b1afe7deb11) Signed-off-by: Willy Tarreau commit a641f76f100c7a316c09af05044d3b8d66d7e5c0 Author: Ryan Underwood Date: Sun Jan 25 16:07:09 2015 -0800 Disable write buffering on Toshiba ToPIC95 commit 2fb22a8042fe96b4220843f79241c116d90922c4 upstream. Disable write buffering on the Toshiba ToPIC95 if it is enabled by somebody (it is not supposed to be a power-on default according to the datasheet). On the ToPIC95, practically no 32-bit Cardbus card will work under heavy load without locking up the whole system if this is left enabled. I tried about a dozen. It does not affect 16-bit cards. This is similar to the O2 bugs in early controller revisions it seems. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=55961 Signed-off-by: Ryan C. Underwood Signed-off-by: Dominik Brodowski Signed-off-by: Ben Hutchings (cherry picked from commit 1e287196507c4272f7096ad4b4f10b1cf4b9d280) Signed-off-by: Willy Tarreau commit ce3510c32f173f263b89e390041636cbe95846de Author: Theodore Ts'o Date: Fri Jun 12 23:45:33 2015 -0400 ext4: fix race between truncate and __ext4_journalled_writepage() commit bdf96838aea6a265f2ae6cbcfb12a778c84a0b8e upstream. The commit cf108bca465d: "ext4: Invert the locking order of page_lock and transaction start" caused __ext4_journalled_writepage() to drop the page lock before the page was written back, as part of changing the locking order to jbd2_journal_start -> page_lock. However, this introduced a potential race if there was a truncate racing with the data=journalled writeback mode. Fix this by grabbing the page lock after starting the journal handle, and then checking to see if page had gotten truncated out from under us. This fixes a number of different warnings or BUG_ON's when running xfstests generic/086 in data=journalled mode, including: jbd2_journal_dirty_metadata: vdc-8: bad jh for block 115643: transaction (ee3fe7 c0, 164), jh->b_transaction ( (null), 0), jh->b_next_transaction ( (null), 0), jlist 0 - and - kernel BUG at /usr/projects/linux/ext4/fs/jbd2/transaction.c:2200! ... Call Trace: [] ? __ext4_journalled_invalidatepage+0x117/0x117 [] __ext4_journalled_invalidatepage+0x10f/0x117 [] ? __ext4_journalled_invalidatepage+0x117/0x117 [] ? lock_buffer+0x36/0x36 [] ext4_journalled_invalidatepage+0xd/0x22 [] do_invalidatepage+0x22/0x26 [] truncate_inode_page+0x5b/0x85 [] truncate_inode_pages_range+0x156/0x38c [] truncate_inode_pages+0x11/0x15 [] truncate_pagecache+0x55/0x71 [] ext4_setattr+0x4a9/0x560 [] ? current_kernel_time+0x10/0x44 [] notify_change+0x1c7/0x2be [] do_truncate+0x65/0x85 [] ? file_ra_state_init+0x12/0x29 - and - WARNING: CPU: 1 PID: 1331 at /usr/projects/linux/ext4/fs/jbd2/transaction.c:1396 irty_metadata+0x14a/0x1ae() ... Call Trace: [] ? console_unlock+0x3a1/0x3ce [] dump_stack+0x48/0x60 [] warn_slowpath_common+0x89/0xa0 [] ? jbd2_journal_dirty_metadata+0x14a/0x1ae [] warn_slowpath_null+0x14/0x18 [] jbd2_journal_dirty_metadata+0x14a/0x1ae [] __ext4_handle_dirty_metadata+0xd4/0x19d [] write_end_fn+0x40/0x53 [] ext4_walk_page_buffers+0x4e/0x6a [] ext4_writepage+0x354/0x3b8 [] ? mpage_release_unused_pages+0xd4/0xd4 [] ? wait_on_buffer+0x2c/0x2c [] ? ext4_writepage+0x3b8/0x3b8 [] __writepage+0x10/0x2e [] write_cache_pages+0x22d/0x32c [] ? ext4_writepage+0x3b8/0x3b8 [] ext4_writepages+0x102/0x607 [] ? sched_clock_local+0x10/0x10e [] ? __lock_is_held+0x2e/0x44 [] ? lock_is_held+0x43/0x51 [] do_writepages+0x1c/0x29 [] __writeback_single_inode+0xc3/0x545 [] writeback_sb_inodes+0x21f/0x36d ... Signed-off-by: Theodore Ts'o [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings (cherry picked from commit b77ea3c2439c54f864487fb7a69007027c833bfb) [wt: adjusted context since we're missing 441c850] Signed-off-by: Willy Tarreau commit b437e292d9ccc55f49377753f57ceac8e90cad40 Author: Lior Amsalem Date: Tue May 26 15:07:32 2015 +0200 dmaengine: mv_xor: bug fix for racing condition in descriptors cleanup commit 9136291f1dbc1d4d1cacd2840fb35f4f3ce16c46 upstream. This patch fixes a bug in the XOR driver where the cleanup function can be called and free descriptors that never been processed by the engine (which result in data errors). The cleanup function will free descriptors based on the ownership bit in the descriptors. Fixes: ff7b04796d98 ("dmaengine: DMA engine driver for Marvell XOR engine") Signed-off-by: Lior Amsalem Signed-off-by: Maxime Ripard Reviewed-by: Ofer Heifetz Signed-off-by: Vinod Koul [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings (cherry picked from commit 26aa1c6949dfef77d3aa77e4cb504ccfd8394ce9) Signed-off-by: Willy Tarreau commit 8a156fbcb0f05278c765666ef06bb79c5a853500 Author: Trond Myklebust Date: Mon Jun 1 15:10:25 2015 -0400 SUNRPC: Fix a memory leak in the backchannel code commit 88de6af24f2b48b06c514d3c3d0a8f22fafe30bd upstream. req->rq_private_buf isn't initialised when xprt_setup_backchannel calls xprt_free_allocation. Fixes: fb7a0b9addbdb ("nfs41: New backchannel helper routines") Signed-off-by: Trond Myklebust [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings (cherry picked from commit bd031759bcc0865938ecc52846a3f22f2a26ad8e) Signed-off-by: Willy Tarreau commit ea4a2f8c1ea6df6617c21171bea27a89cd3b272c Author: Olga Kornievskaia Date: Fri May 15 11:45:31 2015 -0400 fixing infinite OPEN loop in 4.0 stateid recovery commit e8d975e73e5fa05f983fbf2723120edcf68e0b38 upstream. Problem: When an operation like WRITE receives a BAD_STATEID, even though recovery code clears the RECLAIM_NOGRACE recovery flag before recovering the open state, because of clearing delegation state for the associated inode, nfs_inode_find_state_and_recover() gets called and it makes the same state with RECLAIM_NOGRACE flag again. As a results, when we restart looking over the open states, we end up in the infinite loop instead of breaking out in the next test of state flags. Solution: unset the RECLAIM_NOGRACE set because of calling of nfs_inode_find_state_and_recover() after returning from calling recover_open() function. Signed-off-by: Olga Kornievskaia Signed-off-by: Trond Myklebust [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings (cherry picked from commit ef8500b18fc4bb03286a93b6032d56ec7bcbfd15) Signed-off-by: Willy Tarreau commit 1edd4c2623a0b84b603ea6c8d345a90100c53e43 Author: Malcolm Priestley Date: Sun May 31 10:35:28 2015 +0100 staging: vt6655: device_rx_srv check sk_buff is NULL commit b5eeed8cb6097c8ea660b6598d36fdbb94065a22 upstream. There is a small chance that pRD->pRDInfo->skb could go NULL while the interrupt is processing. Put NULL check on loop to break out. Signed-off-by: Malcolm Priestley Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.2: adjust context, indentation] Signed-off-by: Ben Hutchings (cherry picked from commit 35ee488df7402c0549f8329dc20690cf7fe22492) Signed-off-by: Willy Tarreau commit f338a2ebdeb2b7165b50595f935f64e0444454be Author: Jesper Dangaard Brouer Date: Thu May 21 12:16:11 2015 +0200 pktgen: adjust spacing in proc file interface output commit d079abd181950a44cdf31daafd1662388a6c4d2e upstream. Too many spaces were introduced in commit 63adc6fb8ac0 ("pktgen: cleanup checkpatch warnings"), thus misaligning "src_min:" to other columns. Fixes: 63adc6fb8ac0 ("pktgen: cleanup checkpatch warnings") Signed-off-by: Jesper Dangaard Brouer Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings (cherry picked from commit 7acdcce017318585ddb3eacd1d04610b62f181a5) Signed-off-by: Willy Tarreau commit 505ac5d678780e043c97b163e1fee7661d480410 Author: Mauro Carvalho Chehab Date: Tue Apr 28 18:51:17 2015 -0300 cx24116: fix a buffer overflow when checking userspace params commit 1fa2337a315a2448c5434f41e00d56b01a22283c upstream. The maximum size for a DiSEqC command is 6, according to the userspace API. However, the code allows to write up much more values: drivers/media/dvb-frontends/cx24116.c:983 cx24116_send_diseqc_msg() error: buffer overflow 'd->msg' 6 <= 23 Signed-off-by: Mauro Carvalho Chehab [bwh: Backported to 3.2: adjust filename] Signed-off-by: Ben Hutchings (cherry picked from commit 729c8c5e3700410e3436573abfa5b68e8d3c89d6) Signed-off-by: Willy Tarreau commit 55e780c13d7c2a1ba5c31af81334b0fb40a77fca Author: Mauro Carvalho Chehab Date: Tue Apr 28 18:34:40 2015 -0300 s5h1420: fix a buffer overflow when checking userspace params commit 12f4543f5d6811f864e6c4952eb27253c7466c02 upstream. The maximum size for a DiSEqC command is 6, according to the userspace API. However, the code allows to write up to 7 values: drivers/media/dvb-frontends/s5h1420.c:193 s5h1420_send_master_cmd() error: buffer overflow 'cmd->msg' 6 <= 7 Signed-off-by: Mauro Carvalho Chehab [bwh: Backported to 3.2: adjust filename] Signed-off-by: Ben Hutchings (cherry picked from commit 4bf124b5f179a9c169c57ef7cd3a74f239063ed1) Signed-off-by: Willy Tarreau commit 9747205d2dbe6bbf72325dc11fdebf83a5ac7a50 Author: Peter Zijlstra Date: Tue May 20 15:49:48 2014 +0200 hrtimer: Allow concurrent hrtimer_start() for self restarting timers commit 5de2755c8c8b3a6b8414870e2c284914a2b42e4d upstream. Because we drop cpu_base->lock around calling hrtimer::function, it is possible for hrtimer_start() to come in between and enqueue the timer. If hrtimer::function then returns HRTIMER_RESTART we'll hit the BUG_ON because HRTIMER_STATE_ENQUEUED will be set. Since the above is a perfectly valid scenario, remove the BUG_ON and make the enqueue_hrtimer() call conditional on the timer not being enqueued already. NOTE: in that concurrent scenario its entirely common for both sites to want to modify the hrtimer, since hrtimers don't provide serialization themselves be sure to provide some such that the hrtimer::function and the hrtimer_start() caller don't both try and fudge the expiration state at the same time. To that effect, add a WARN when someone tries to forward an already enqueued timer, the most common way to change the expiry of self restarting timers. Ideally we'd put the WARN in everything modifying the expiry but most of that is inlines and we don't need the bloat. Fixes: 2d44ae4d7135 ("hrtimer: clean up cpu->base locking tricks") Signed-off-by: Peter Zijlstra (Intel) Cc: Ben Segall Cc: Roman Gushchin Cc: Paul Turner Link: http://lkml.kernel.org/r/20150415113105.GT5029@twins.programming.kicks-ass.net Signed-off-by: Thomas Gleixner [bwh: Backported to 3.2: adjust filename, context] Signed-off-by: Ben Hutchings (cherry picked from commit ba4a679df78ffd52405af90aae3f4481c6945d6d) Signed-off-by: Willy Tarreau commit 353bd7db1b1f48c32ca1cfde03f80e666839cec2 Author: Lars Persson Date: Thu Feb 26 14:16:03 2015 +0100 MIPS: Fix race condition in lazy cache flushing. commit 4d46a67a3eb827ccf1125959936fd51ba318dabc upstream. The lazy cache flushing implemented in the MIPS kernel suffers from a race condition that is exposed by do_set_pte() in mm/memory.c. A pre-condition is a file-system that writes to the page from the CPU in its readpage method and then calls flush_dcache_page(). One example is ubifs. Another pre-condition is that the dcache flush is postponed in __flush_dcache_page(). Upon a page fault for an executable mapping not existing in the page-cache, the following will happen: 1. Write to the page 2. flush_dcache_page 3. flush_icache_page 4. set_pte_at 5. update_mmu_cache (commits the flush of a dcache-dirty page) Between steps 4 and 5 another thread can hit the same page and it will encounter a valid pte. Because the data still is in the L1 dcache the CPU will fetch stale data from L2 into the icache and execute garbage. This fix moves the commit of the cache flush to step 3 to close the race window. It also reduces the amount of flushes on non-executable mappings because we never enter __flush_dcache_page() for non-aliasing CPUs. Regressions can occur in drivers that mistakenly relies on the flush_dcache_page() in get_user_pages() for DMA operations. [ralf@linux-mips.org: Folded in patch 9346 to fix highmem issue.] Signed-off-by: Lars Persson Cc: linux-mips@linux-mips.org Cc: paul.burton@imgtec.com Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/9346/ Patchwork: https://patchwork.linux-mips.org/patch/9738/ Signed-off-by: Ralf Baechle Signed-off-by: Ben Hutchings (cherry picked from commit 6bde6a3df0b4c8680d51c987d446b0ff2d6df0a6) Signed-off-by: Willy Tarreau commit 93f44614486be7d8eb4864b51f4808fc945b69f6 Author: Alexander Sverdlin Date: Wed Mar 18 14:05:21 2015 +0100 MIPS: Octeon: Remove udelay() causing huge IRQ latency commit 73bf3c2a500b2db8ac966469591196bf55afb409 upstream. udelay() in PCI/PCIe read/write callbacks cause 30ms IRQ latency on Octeon platforms because these operations are called from PCI_OP_READ() and PCI_OP_WRITE() under raw_spin_lock_irqsave(). Signed-off-by: Alexander Sverdlin Cc: linux-mips@linux-mips.org Cc: David Daney Cc: Rob Herring Cc: Jiri Kosina Cc: Randy Dunlap Cc: Masanari Iida Cc: Bjorn Helgaas Cc: Mathias Patchwork: https://patchwork.linux-mips.org/patch/9576/ Signed-off-by: Ralf Baechle [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings (cherry picked from commit 53493d44a771a3155ee12b6ac668fb2543d21a7a) Signed-off-by: Willy Tarreau commit 8a1a5b2f86dcd4bf42f9bd26e778fb504767b051 Author: Mark Grondona Date: Wed Sep 11 14:24:31 2013 -0700 __ptrace_may_access() should not deny sub-threads commit 73af963f9f3036dffed55c3a2898598186db1045 upstream. __ptrace_may_access() checks get_dumpable/ptrace_has_cap/etc if task != current, this can can lead to surprising results. For example, a sub-thread can't readlink("/proc/self/exe") if the executable is not readable. setup_new_exec()->would_dump() notices that inode_permission(MAY_READ) fails and then it does set_dumpable(suid_dumpable). After that get_dumpable() fails. (It is not clear why proc_pid_readlink() checks get_dumpable(), perhaps we could add PTRACE_MODE_NODUMPABLE) Change __ptrace_may_access() to use same_thread_group() instead of "task == current". Any security check is pointless when the tasks share the same ->mm. Signed-off-by: Mark Grondona Signed-off-by: Ben Woodard Signed-off-by: Oleg Nesterov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings Cc: Sheng Yong (cherry picked from commit f062bd6e420a064a19563b80c26d746b0262e404) Signed-off-by: Willy Tarreau commit 4a6f3fd6d64c09e7056822efd3d89de10dcd2ad1 Author: Oleg Nesterov Date: Wed Sep 11 14:20:06 2013 -0700 include/linux/sched.h: don't use task->pid/tgid in same_thread_group/has_group_leader_pid commit e1403b8edf669ff49bbdf602cc97fefa2760cb15 upstream. task_struct->pid/tgid should go away. 1. Change same_thread_group() to use task->signal for comparison. 2. Change has_group_leader_pid(task) to compare task_pid(task) with signal->leader_pid. Signed-off-by: Oleg Nesterov Cc: Michal Hocko Cc: Sergey Dyasly Reviewed-by: "Eric W. Biederman" Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Peter Zijlstra Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings Cc: Sheng Yong (cherry picked from commit a7b4d51399316329b6a3d9eaeab224d83eeebe67) Signed-off-by: Willy Tarreau commit 702482afb84a19162e38d4829fe4d8a57806a7d2 Author: Feng Tang Date: Wed May 30 23:15:41 2012 +0800 x86/reboot: Fix a warning message triggered by stop_other_cpus() commit 55c844a4dd16a4d1fdc0cf2a283ec631a02ec448 upstream. When rebooting our 24 CPU Westmere servers with 3.4-rc6, we always see this warning msg: Restarting system. machine restart ------------[ cut here ]------------ WARNING: at arch/x86/kernel/smp.c:125 native_smp_send_reschedule+0x74/0xa7() Hardware name: X8DTN Modules linked in: igb [last unloaded: scsi_wait_scan] Pid: 1, comm: systemd-shutdow Not tainted 3.4.0-rc6+ #22 Call Trace: [] warn_slowpath_common+0x7e/0x96 [] warn_slowpath_null+0x15/0x17 [] native_smp_send_reschedule+0x74/0xa7 [] trigger_load_balance+0x279/0x2a6 [] scheduler_tick+0xe0/0xe9 [] update_process_times+0x60/0x70 [] tick_sched_timer+0x68/0x92 [] __run_hrtimer+0xb3/0x13c [] ? tick_nohz_handler+0xd0/0xd0 [] hrtimer_interrupt+0xdb/0x198 [] smp_apic_timer_interrupt+0x81/0x94 [] apic_timer_interrupt+0x67/0x70 [] ? default_send_IPI_mask_allbutself_phys+0xb4/0xc4 [] physflat_send_IPI_allbutself+0x12/0x14 [] native_nmi_stop_other_cpus+0x8a/0xd6 [] native_machine_shutdown+0x50/0x67 [] machine_shutdown+0xa/0xc [] native_machine_restart+0x20/0x32 [] machine_restart+0xa/0xc [] kernel_restart+0x47/0x4c [] sys_reboot+0x13e/0x17c [] ? _raw_spin_unlock_bh+0x10/0x12 [] ? bdi_queue_work+0xcf/0xd8 [] ? __bdi_start_writeback+0xae/0xb7 [] ? iterate_supers+0xa3/0xb7 [] system_call_fastpath+0x16/0x1b ---[ end trace 320af5cb1cb60c5b ]--- The root cause seems to be the default_send_IPI_mask_allbutself_phys() takes quite some time (I measured it could be several ms) to complete sending NMIs to all the other 23 CPUs, and for HZ=250/1000 system, the time is long enough for a timer interrupt to happen, which will in turn trigger to kick load balance to a stopped CPU and cause this warning in native_smp_send_reschedule(). So disabling the local irq before stop_other_cpu() can fix this problem (tested 25 times reboot ok), and it is fine as there should be nobody caring the timer interrupt in such reboot stage. The latest 3.4 kernel slightly changes this behavior by sending REBOOT_VECTOR first and only send NMI_VECTOR if the REBOOT_VCTOR fails, and this patch is still needed to prevent the problem. Signed-off-by: Feng Tang Acked-by: Don Zickus Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/20120530231541.4c13433a@feng-i7 Signed-off-by: Ingo Molnar [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings Cc: Vinson Lee (cherry picked from commit ea475029e76a0b7fc6e96baf4d414079dec8a90a) Signed-off-by: Willy Tarreau commit 6b7ba97328b8df7495885d98cc4299dcaf9235f6 Author: Steven Rostedt Date: Mon Jun 15 17:50:25 2015 -0400 tracing: Have filter check for balanced ops commit 2cf30dc180cea808077f003c5116388183e54f9e upstream. When the following filter is used it causes a warning to trigger: # cd /sys/kernel/debug/tracing # echo "((dev==1)blocks==2)" > events/ext4/ext4_truncate_exit/filter -bash: echo: write error: Invalid argument # cat events/ext4/ext4_truncate_exit/filter ((dev==1)blocks==2) ^ parse_error: No error ------------[ cut here ]------------ WARNING: CPU: 2 PID: 1223 at kernel/trace/trace_events_filter.c:1640 replace_preds+0x3c5/0x990() Modules linked in: bnep lockd grace bluetooth ... CPU: 3 PID: 1223 Comm: bash Tainted: G W 4.1.0-rc3-test+ #450 Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v02.05 05/07/2012 0000000000000668 ffff8800c106bc98 ffffffff816ed4f9 ffff88011ead0cf0 0000000000000000 ffff8800c106bcd8 ffffffff8107fb07 ffffffff8136b46c ffff8800c7d81d48 ffff8800d4c2bc00 ffff8800d4d4f920 00000000ffffffea Call Trace: [] dump_stack+0x4c/0x6e [] warn_slowpath_common+0x97/0xe0 [] ? _kstrtoull+0x2c/0x80 [] warn_slowpath_null+0x1a/0x20 [] replace_preds+0x3c5/0x990 [] create_filter+0x82/0xb0 [] apply_event_filter+0xd4/0x180 [] event_filter_write+0x8f/0x120 [] __vfs_write+0x28/0xe0 [] ? __sb_start_write+0x53/0xf0 [] ? security_file_permission+0x30/0xc0 [] vfs_write+0xb8/0x1b0 [] SyS_write+0x4f/0xb0 [] system_call_fastpath+0x12/0x6a ---[ end trace e11028bd95818dcd ]--- Worse yet, reading the error message (the filter again) it says that there was no error, when there clearly was. The issue is that the code that checks the input does not check for balanced ops. That is, having an op between a closed parenthesis and the next token. This would only cause a warning, and fail out before doing any real harm, but it should still not caues a warning, and the error reported should work: # cd /sys/kernel/debug/tracing # echo "((dev==1)blocks==2)" > events/ext4/ext4_truncate_exit/filter -bash: echo: write error: Invalid argument # cat events/ext4/ext4_truncate_exit/filter ((dev==1)blocks==2) ^ parse_error: Meaningless filter expression And give no kernel warning. Link: http://lkml.kernel.org/r/20150615175025.7e809215@gandalf.local.home Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Arnaldo Carvalho de Melo Reported-by: Vince Weaver Tested-by: Vince Weaver Signed-off-by: Steven Rostedt [bwh: Backported to 3.2: drop the check for OP_NOT, which we don't have] Signed-off-by: Ben Hutchings (cherry picked from commit 9fa3f3e6f2a4f4797df5550a33ec5ac1088647e7) Signed-off-by: Willy Tarreau commit 7d746dd5e6813a31d2ccfb923c6ea9c53e00d0c4 Author: Ben Hutchings Date: Tue Jul 21 15:42:59 2015 +0100 x86_64: Fix strnlen_user() to not touch memory after specified maximum Inspired by commit f18c34e483ff ("lib: Fix strnlen_user() to not touch memory after specified maximum") upstream. This version of strnlen_user(), no longer present upstream, has a similar off-by-one error. Signed-off-by: Ben Hutchings Cc: Jan Kara (cherry picked from commit 4797489ce83a5f42d0b38089695a48d4a3d1ee0b) Signed-off-by: Willy Tarreau commit 7366056a9f1943d924cf78f4e4924d6bbe06b607 Author: Sasha Levin Date: Thu May 28 15:44:29 2015 -0700 fs, omfs: add NULL terminator in the end up the token list commit dcbff39da3d815f08750552fdd04f96b51751129 upstream. match_token() expects a NULL terminator at the end of the token list so that it would know where to stop. Not having one causes it to overrun to invalid memory. In practice, passing a mount option that omfs didn't recognize would sometimes panic the system. Signed-off-by: Sasha Levin Signed-off-by: Bob Copeland Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings (cherry picked from commit a5045e0fee1a7b2cf132afb94977d4c8d781bd04) Signed-off-by: Willy Tarreau commit c38b1588994eb29499032b5bd58dd28a6d0097d0 Author: Rusty Russell Date: Wed May 27 10:59:26 2015 +0930 lguest: fix out-by-one error in address checking. commit 83a35114d0e4583e6b0ca39502e68b6a92e2910c upstream. This bug has been there since day 1; addresses in the top guest physical page weren't considered valid. You could map that page (the check in check_gpte() is correct), but if a guest tried to put a pagetable there we'd check that address manually when walking it, and kill the guest. Signed-off-by: Rusty Russell Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings (cherry picked from commit a8f5259269671acb4f0bdb6e0a53974aa5b351ff) Signed-off-by: Willy Tarreau commit be8ec25609be78a9536cb7c89e77a1d549fced0d Author: Mark Hounschell Date: Wed May 13 10:49:09 2015 +0200 sd: Disable support for 256 byte/sector disks commit 74856fbf441929918c49ff262ace9835048e4e6a upstream. 256 bytes per sector support has been broken since 2.6.X, and no-one stepped up to fix this. So disable support for it. Signed-off-by: Mark Hounschell Signed-off-by: Hannes Reinecke Signed-off-by: James Bottomley [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings (cherry picked from commit fd6b72574fcdaee123768804d8f1ac28c2a5b3de) Signed-off-by: Willy Tarreau commit 06763ca2d529c0f2bfcf13aa47bdf211de4259c9 Author: Darrick J. Wong Date: Thu May 14 19:11:50 2015 -0400 jbd2: fix r_count overflows leading to buffer overflow in journal recovery commit e531d0bceb402e643a4499de40dd3fa39d8d2e43 upstream. The journal revoke block recovery code does not check r_count for sanity, which means that an evil value of r_count could result in the kernel reading off the end of the revoke table and into whatever garbage lies beyond. This could crash the kernel, so fix that. However, in testing this fix, I discovered that the code to write out the revoke tables also was not correctly checking to see if the block was full -- the current offset check is fine so long as the revoke table space size is a multiple of the record size, but this is not true when either journal_csum_v[23] are set. Signed-off-by: Darrick J. Wong Signed-off-by: Theodore Ts'o Reviewed-by: Jan Kara [bwh: Backported to 3.2: journal checksumming is not supported, so only the first fix is needed] Signed-off-by: Ben Hutchings (cherry picked from commit 2f6a2bcc01bc9ed73bfb4d698da94ed2a5fcb18c) Signed-off-by: Willy Tarreau commit 6c43247b73b100ba8ff51bc06997a7c1fd157bbc Author: Anton Blanchard Date: Thu May 14 14:45:40 2015 +1000 powerpc: Align TOC to 256 bytes commit 5e95235ccd5442d4a4fe11ec4eb99ba1b7959368 upstream. Recent toolchains force the TOC to be 256 byte aligned. We need to enforce this alignment in our linker script, otherwise pointers to our TOC variables (__toc_start, __prom_init_toc_start) could be incorrect. If they are bad, we die a few hundred instructions into boot. Signed-off-by: Anton Blanchard Signed-off-by: Michael Ellerman Signed-off-by: Ben Hutchings (cherry picked from commit 303241421684cdd2f9e931bc42b9de811320e7fd) Signed-off-by: Willy Tarreau commit 26a42fd3d6d5723b970cd8251abb87984d440bb4 Author: NeilBrown Date: Fri May 8 18:19:34 2015 +1000 md/raid5: don't record new size if resize_stripes fails. commit 6e9eac2dcee5e19f125967dd2be3e36558c42fff upstream. If any memory allocation in resize_stripes fails we will return -ENOMEM, but in some cases we update conf->pool_size anyway. This means that if we try again, the allocations will be assumed to be larger than they are, and badness results. So only update pool_size if there is no error. This bug was introduced in 2.6.17 and the patch is suitable for -stable. Fixes: ad01c9e3752f ("[PATCH] md: Allow stripes to be expanded in preparation for expanding an array") Signed-off-by: NeilBrown Signed-off-by: Ben Hutchings (cherry picked from commit c20694a054e903745591f4f85b39ecbce4e58349) Signed-off-by: Willy Tarreau commit 7b5f777748799261710c6153e4e42354cc849047 Author: Dan Carpenter Date: Thu Apr 16 12:48:35 2015 -0700 memstick: mspro_block: add missing curly braces commit 13f6b191aaa11c7fd718d35a0c565f3c16bc1d99 upstream. Using the indenting we can see the curly braces were obviously intended. This is a static checker fix, but my guess is that we don't read enough bytes, because we don't calculate "t_len" correctly. Fixes: f1d82698029b ('memstick: use fully asynchronous request processing') Signed-off-by: Dan Carpenter Cc: Alex Dubov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings (cherry picked from commit 0fd0b9f448e1ff459ea4f718def61a197b15bb4c) Signed-off-by: Willy Tarreau commit f97672b998cec03dceb5a326ab671f120253554e Author: Oleg Nesterov Date: Thu Apr 16 12:47:29 2015 -0700 ptrace: fix race between ptrace_resume() and wait_task_stopped() commit b72c186999e689cb0b055ab1c7b3cd8fffbeb5ed upstream. ptrace_resume() is called when the tracee is still __TASK_TRACED. We set tracee->exit_code and then wake_up_state() changes tracee->state. If the tracer's sub-thread does wait() in between, task_stopped_code(ptrace => T) wrongly looks like another report from tracee. This confuses debugger, and since wait_task_stopped() clears ->exit_code the tracee can miss a signal. Test-case: #include #include #include #include #include #include int pid; void *waiter(void *arg) { int stat; for (;;) { assert(pid == wait(&stat)); assert(WIFSTOPPED(stat)); if (WSTOPSIG(stat) == SIGHUP) continue; assert(WSTOPSIG(stat) == SIGCONT); printf("ERR! extra/wrong report:%x\n", stat); } } int main(void) { pthread_t thread; pid = fork(); if (!pid) { assert(ptrace(PTRACE_TRACEME, 0,0,0) == 0); for (;;) kill(getpid(), SIGHUP); } assert(pthread_create(&thread, NULL, waiter, NULL) == 0); for (;;) ptrace(PTRACE_CONT, pid, 0, SIGCONT); return 0; } Note for stable: the bug is very old, but without 9899d11f6544 "ptrace: ensure arch_ptrace/ptrace_request can never race with SIGKILL" the fix should use lock_task_sighand(child). Signed-off-by: Oleg Nesterov Reported-by: Pavel Labath Tested-by: Pavel Labath Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings (cherry picked from commit e3f81ba2f0546f030fc234f7aade3016532c75b1) Signed-off-by: Willy Tarreau commit 804be11691680c2816f2978189ced2782e99935a Author: Heiko Carstens Date: Wed Mar 25 10:13:33 2015 +0100 s390/hibernate: fix save and restore of kernel text section commit d74419495633493c9cd3f2bbeb7f3529d0edded6 upstream. Sebastian reported a crash caused by a jump label mismatch after resume. This happens because we do not save the kernel text section during suspend and therefore also do not restore it during resume, but use the kernel image that restores the old system. This means that after a suspend/resume cycle we lost all modifications done to the kernel text section. The reason for this is the pfn_is_nosave() function, which incorrectly returns that read-only pages don't need to be saved. This is incorrect since we mark the kernel text section read-only. We still need to make sure to not save and restore pages contained within NSS and DCSS segment. To fix this add an extra case for the kernel text section and only save those pages if they are not contained within an NSS segment. Fixes the following crash (and the above bugs as well): Jump label code mismatch at netif_receive_skb_internal+0x28/0xd0 Found: c0 04 00 00 00 00 Expected: c0 f4 00 00 00 11 New: c0 04 00 00 00 00 Kernel panic - not syncing: Corrupted kernel text CPU: 0 PID: 9 Comm: migration/0 Not tainted 3.19.0-01975-gb1b096e70f23 #4 Call Trace: [<0000000000113972>] show_stack+0x72/0xf0 [<000000000081f15e>] dump_stack+0x6e/0x90 [<000000000081c4e8>] panic+0x108/0x2b0 [<000000000081be64>] jump_label_bug.isra.2+0x104/0x108 [<0000000000112176>] __jump_label_transform+0x9e/0xd0 [<00000000001121e6>] __sm_arch_jump_label_transform+0x3e/0x50 [<00000000001d1136>] multi_cpu_stop+0x12e/0x170 [<00000000001d1472>] cpu_stopper_thread+0xb2/0x168 [<000000000015d2ac>] smpboot_thread_fn+0x134/0x1b0 [<0000000000158baa>] kthread+0x10a/0x110 [<0000000000824a86>] kernel_thread_starter+0x6/0xc Reported-and-tested-by: Sebastian Ott Signed-off-by: Heiko Carstens Signed-off-by: Martin Schwidefsky [bwh: Backported to 3.2: add necessary #include directives] Signed-off-by: Ben Hutchings (cherry picked from commit 98b4a75c0792d281beb904911e2271d45c71511a) Signed-off-by: Willy Tarreau commit 4780b09f2888260c8c30e66cb5b5a28646a613db Author: Dave Olson Date: Thu Apr 2 21:28:45 2015 -0700 powerpc: Fix missing L2 cache size in /sys/devices/system/cpu commit f7e9e358362557c3aa2c1ec47490f29fe880a09e upstream. This problem appears to have been introduced in 2.6.29 by commit 93197a36a9c1 "Rewrite sysfs processor cache info code". This caused lscpu to error out on at least e500v2 devices, eg: error: cannot open /sys/devices/system/cpu/cpu0/cache/index2/size: No such file or directory Some embedded powerpc systems use cache-size in DTS for the unified L2 cache size, not d-cache-size, so we need to allow for both DTS names. Added a new CACHE_TYPE_UNIFIED_D cache_type_info structure to handle this. Fixes: 93197a36a9c1 ("powerpc: Rewrite sysfs processor cache info code") Signed-off-by: Dave Olson Signed-off-by: Michael Ellerman [bwh: Backported to 3.2: - Adjust context - Preserve __cpuinit attribute on cache_do_one_devnode_unified()] Signed-off-by: Ben Hutchings (cherry picked from commit d6de5ca93fd6425dcdb21cc341365991c0c444cc) Signed-off-by: Willy Tarreau commit 527eeaf4541fe88d96095ea41482a7c57c5d81e0 Author: Sabrina Dubroca Date: Thu Feb 26 05:35:41 2015 +0000 e1000: add dummy allocator to fix race condition between mtu change and netpoll commit 08e8331654d1d7b2c58045e549005bc356aa7810 upstream. There is a race condition between e1000_change_mtu's cleanups and netpoll, when we change the MTU across jumbo size: Changing MTU frees all the rx buffers: e1000_change_mtu -> e1000_down -> e1000_clean_all_rx_rings -> e1000_clean_rx_ring Then, close to the end of e1000_change_mtu: pr_info -> ... -> netpoll_poll_dev -> e1000_clean -> e1000_clean_rx_irq -> e1000_alloc_rx_buffers -> e1000_alloc_frag And when we come back to do the rest of the MTU change: e1000_up -> e1000_configure -> e1000_configure_rx -> e1000_alloc_jumbo_rx_buffers alloc_jumbo finds the buffers already != NULL, since data (shared with page in e1000_rx_buffer->rxbuf) has been re-alloc'd, but it's garbage, or at least not what is expected when in jumbo state. This results in an unusable adapter (packets don't get through), and a NULL pointer dereference on the next call to e1000_clean_rx_ring (other mtu change, link down, shutdown): BUG: unable to handle kernel NULL pointer dereference at (null) IP: [] put_compound_page+0x7e/0x330 [...] Call Trace: [] put_page+0x55/0x60 [] e1000_clean_rx_ring+0x134/0x200 [] e1000_clean_all_rx_rings+0x45/0x60 [] e1000_down+0x1c0/0x1d0 [] ? deactivate_slab+0x7f0/0x840 [] e1000_change_mtu+0xdc/0x170 [] dev_set_mtu+0xa0/0x140 [] do_setlink+0x218/0xac0 [] ? nla_parse+0xb9/0x120 [] rtnl_newlink+0x6d0/0x890 [] ? kvm_clock_read+0x20/0x40 [] ? sched_clock_cpu+0xa8/0x100 [] rtnetlink_rcv_msg+0x92/0x260 By setting the allocator to a dummy version, netpoll can't mess up our rx buffers. The allocator is set back to a sane value in e1000_configure_rx. Fixes: edbbb3ca1077 ("e1000: implement jumbo receive with partial descriptors") Signed-off-by: Sabrina Dubroca Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Ben Hutchings (cherry picked from commit f655adbac3de7ce92b2b0f9ce2d426b55b600e38) [wt: path is drivers/net/e1000/e1000_main.c in 2.6.32] Signed-off-by: Willy Tarreau commit c570ec2f868e949c952e32d95966708ee5413b76 Author: Eric Dumazet Date: Sat May 30 09:16:53 2015 -0700 udp: fix behavior of wrong checksums commit beb39db59d14990e401e235faf66a6b9b31240b0 upstream. We have two problems in UDP stack related to bogus checksums : 1) We return -EAGAIN to application even if receive queue is not empty. This breaks applications using edge trigger epoll() 2) Under UDP flood, we can loop forever without yielding to other processes, potentially hanging the host, especially on non SMP. This patch is an attempt to make things better. We might in the future add extra support for rt applications wanting to better control time spent doing a recv() in a hostile environment. For example we could validate checksums before queuing packets in socket receive queue. Signed-off-by: Eric Dumazet Cc: Willem de Bruijn Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings CVE-2015-5364 CVE-2015-5366 Signed-off-by: Willy Tarreau commit 791299da239089e4e28b5605ea91126d0cc2b722 Author: Jan Kara Date: Wed Jan 7 13:49:08 2015 +0100 udf: Check length of extended attributes and allocation descriptors commit 23b133bdc452aa441fcb9b82cbf6dd05cfd342d0 upstream. Check length of extended attributes and allocation descriptors when loading inodes from disk. Otherwise corrupted filesystems could confuse the code and make the kernel oops. Reported-by: Carl Henrik Lunde Signed-off-by: Jan Kara [bwh: Backported to 2.6.32: use make_bad_inode() instead of returning error] Signed-off-by: Ben Hutchings CVE-2015-4167 Signed-off-by: Willy Tarreau commit 835860830860a609ca2b7bdfbd5ddc342333f357 Author: Jan Kara Date: Wed Jan 7 13:46:16 2015 +0100 udf: Remove repeated loads blocksize commit 79144954278d4bb5989f8b903adcac7a20ff2a5a upstream. Store blocksize in a local variable in udf_fill_inode() since it is used a lot of times. Signed-off-by: Jan Kara [bwh: Needed for the following fix. Backported to 2.6.32: adjust context.] Signed-off-by: Ben Hutchings Signed-off-by: Willy Tarreau commit 56de771cef061319e172130ae71e281e340e13bd Author: Jan Kara Date: Fri Dec 19 14:27:55 2014 +0100 udf: Check component length before reading it commit e237ec37ec154564f8690c5bd1795339955eeef9 upstream. Check that length specified in a component of a symlink fits in the input buffer we are reading. Also properly ignore component length for component types that do not use it. Otherwise we read memory after end of buffer for corrupted udf image. Reported-by: Carl Henrik Lunde Signed-off-by: Jan Kara Signed-off-by: Ben Hutchings CVE-2014-9728, CVE-2014-9730 Signed-off-by: Willy Tarreau commit 2897fe8d016c32b83a70a645a545d78152356f36 Author: Jan Kara Date: Thu Dec 18 22:37:50 2014 +0100 udf: Check path length when reading symlink commit 0e5cc9a40ada6046e6bc3bdfcd0c0d7e4b706b14 upstream. Symlink reading code does not check whether the resulting path fits into the page provided by the generic code. This isn't as easy as just checking the symlink size because of various encoding conversions we perform on path. So we have to check whether there is still enough space in the buffer on the fly. Reported-by: Carl Henrik Lunde Signed-off-by: Jan Kara [bwh: Backported to 2.6.32: adjust context, indentation] Signed-off-by: Ben Hutchings CVE-2014-9731 Signed-off-by: Willy Tarreau commit 8b5c9cbf33c4ef5a8091c4db1b9fc9010d5f699e Author: Jan Kara Date: Mon Dec 12 15:13:50 2011 +0100 udf: Treat symlink component of type 2 as / commit fef2e9f3301934773e4f1b3cc5c7bffb119346b8 upstream. Currently, we ignore symlink component of type 2. But mkisofs and other OS' seem to treat it as / so do the same for compatibility. Reported-by: "Gábor S." Signed-off-by: Jan Kara [bwh: Needed for the following fix] Signed-off-by: Ben Hutchings Signed-off-by: Willy Tarreau commit 79ba08d93105f786f925e8de11f1d944942bd79a Author: Jan Kara Date: Fri Dec 19 12:21:47 2014 +0100 udf: Verify symlink size before loading it commit a1d47b262952a45aae62bd49cfaf33dd76c11a2c upstream. UDF specification allows arbitrarily large symlinks. However we support only symlinks at most one block large. Check the length of the symlink so that we don't access memory beyond end of the symlink block. Reported-by: Carl Henrik Lunde Signed-off-by: Jan Kara [bwh: Backported to 2.6.32: adjust context] Signed-off-by: Ben Hutchings CVE-2014-9728 Signed-off-by: Willy Tarreau commit 343fc5b21af325214a4b51c2942427fb6169f412 Author: Jan Kara Date: Fri Dec 19 12:03:53 2014 +0100 udf: Verify i_size when loading inode commit e159332b9af4b04d882dbcfe1bb0117f0a6d4b58 upstream. Verify that inode size is sane when loading inode with data stored in ICB. Otherwise we may get confused later when working with the inode and inode size is too big. Reported-by: Carl Henrik Lunde Signed-off-by: Jan Kara [bwh: Backported to 2.6.32: on error, call make_bad_inode() then return] Signed-off-by: Ben Hutchings CVE-2014-9728, CVE-2014-9729 Signed-off-by: Willy Tarreau commit d8b3be1ede7a9559cef59f8066ba90a17f989dd8 Author: Jiri Kosina Date: Thu Aug 21 09:57:48 2014 -0500 HID: fix a couple of off-by-ones commit 4ab25786c87eb20857bbb715c3ae34ec8fd6a214 upstream. There are a few very theoretical off-by-one bugs in report descriptor size checking when performing a pre-parsing fixup. Fix those. Reported-by: Ben Hawkes Reviewed-by: Benjamin Tissoires Signed-off-by: Jiri Kosina [bwh: Backported to 2.6.32: - Adjust context - Drop change to a quirk in hid-lg.c that doesn't exist here] Signed-off-by: Ben Hutchings CVE-2014-3184 Signed-off-by: Willy Tarreau commit f9e6d14d33ab7e4ada2d59acaf16196626063e95 Author: Michael Halcrow Date: Wed Nov 26 09:09:16 2014 -0800 eCryptfs: Remove buggy and unnecessary write in file name decode routine commit 942080643bce061c3dd9d5718d3b745dcb39a8bc upstream. Dmitry Chernenkov used KASAN to discover that eCryptfs writes past the end of the allocated buffer during encrypted filename decoding. This fix corrects the issue by getting rid of the unnecessary 0 write when the current bit offset is 2. Signed-off-by: Michael Halcrow Reported-by: Dmitry Chernenkov Suggested-by: Kees Cook Signed-off-by: Tyler Hicks Signed-off-by: Ben Hutchings CVE-2014-9683 Signed-off-by: Willy Tarreau commit 624f4cea32b1f9897b4bf29f12d41295409b0956 Author: Pablo Neira Ayuso Date: Thu Aug 23 02:09:11 2012 +0000 netlink: fix possible spoofing from non-root processes commit 20e1db19db5d6b9e4e83021595eab0dc8f107bef upstream. Non-root user-space processes can send Netlink messages to other processes that are well-known for being subscribed to Netlink asynchronous notifications. This allows ilegitimate non-root process to send forged messages to Netlink subscribers. The userspace process usually verifies the legitimate origin in two ways: a) Socket credentials. If UID != 0, then the message comes from some ilegitimate process and the message needs to be dropped. b) Netlink portID. In general, portID == 0 means that the origin of the messages comes from the kernel. Thus, discarding any message not coming from the kernel. However, ctnetlink sets the portID in event messages that has been triggered by some user-space process, eg. conntrack utility. So other processes subscribed to ctnetlink events, eg. conntrackd, know that the event was triggered by some user-space action. Neither of the two ways to discard ilegitimate messages coming from non-root processes can help for ctnetlink. This patch adds capability validation in case that dst_pid is set in netlink_sendmsg(). This approach is aggressive since existing applications using any Netlink bus to deliver messages between two user-space processes will break. Note that the exception is NETLINK_USERSOCK, since it is reserved for netlink-to-netlink userspace communication. Still, if anyone wants that his Netlink bus allows netlink-to-netlink userspace, then they can set NL_NONROOT_SEND. However, by default, I don't think it makes sense to allow to use NETLINK_ROUTE to communicate two processes that are sending no matter what information that is not related to link/neighbouring/routing. They should be using NETLINK_USERSOCK instead for that. Signed-off-by: Pablo Neira Ayuso Signed-off-by: David S. Miller [bwh: Backported to 2.6.32: - Adjust context - NETLINK_USERSOCK does not exist, so drop that part] Signed-off-by: Ben Hutchings CVE-2012-6689 Signed-off-by: Willy Tarreau commit d447af56f50bdcb4d5ca378ed6b2d48fb0b973ac Author: Jiri Slaby Date: Wed Oct 12 11:32:42 2011 +0200 TTY: drop driver reference in tty_open fail path commit c290f8358acaeffd8e0c551ddcc24d1206143376 upstream. When tty_driver_lookup_tty fails in tty_open, we forget to drop a reference to the tty driver. This was added by commit 4a2b5fddd5 (Move tty lookup/reopen to caller). Fix that by adding tty_driver_kref_put to the fail path. I will refactor the code later. This is for the ease of backporting to stable. Introduced-in: v2.6.28-rc2 Signed-off-by: Jiri Slaby Cc: Alan Cox Acked-by: Sukadev Bhattiprolu Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 2.6.32: adjust filename] Signed-off-by: Ben Hutchings CVE-2011-5321 Signed-off-by: Willy Tarreau commit 435f34cb44936431d6b2d8525ba6beab2a9e6b03 Author: Markus F.X.J. Oberhumer Date: Sun Oct 14 15:39:04 2012 +0200 crypto: testmgr - update LZO compression test vectors Update the LZO compression test vectors according to the latest compressor version. Signed-off-by: Markus F.X.J. Oberhumer (cherry picked from commit 0ec7382036922be063b515b2a3f1d6f7a607392c) Cc: Ben Hutchings Signed-off-by: Willy Tarreau commit b85d2929360833f267efc5d2366ee30e553d9226 Author: Al Viro Date: Sat Mar 21 20:08:18 2015 -0400 sg_start_req(): make sure that there's not too many elements in iovec commit 451a2886b6bf90e2fb378f7c46c655450fb96e81 upstream. unfortunately, allowing an arbitrary 16bit value means a possibility of overflow in the calculation of total number of pages in bio_map_user_iov() - we rely on there being no more than PAGE_SIZE members of sum in the first loop there. If that sum wraps around, we end up allocating too small array of pointers to pages and it's easy to overflow it in the second loop. X-Coverup: TINC (and there's no lumber cartel either) Signed-off-by: Al Viro [bwh: s/MAX_UIOVEC/UIO_MAXIOV/. This was fixed upstream by commit fdc81f45e9f5 ("sg_start_req(): use import_iovec()"), but we don't have that function.] Signed-off-by: Ben Hutchings (cherry picked from commit 07213eed86c17c544bb10568fc04e49e03730ab7) Signed-off-by: Willy Tarreau commit 0e1824c413ec9f0fd1e38ee30a88831473ecb24a Author: Ben Hutchings Date: Mon Jun 15 03:51:55 2015 +0100 pipe: iovec: Fix memory corruption when retrying atomic copy as non-atomic pipe_iov_copy_{from,to}_user() may be tried twice with the same iovec, the first time atomically and the second time not. The second attempt needs to continue from the iovec position, pipe buffer offset and remaining length where the first attempt failed, but currently the pipe buffer offset and remaining length are reset. This will corrupt the piped data (possibly also leading to an information leak between processes) and may also corrupt kernel memory. This was fixed upstream by commits f0d1bec9d58d ("new helper: copy_page_from_iter()") and 637b58c2887e ("switch pipe_read() to copy_page_to_iter()"), but those aren't suitable for stable. This fix for older kernel versions was made by Seth Jennings for RHEL and I have extracted it from their update. CVE-2015-1805 References: https://bugzilla.redhat.com/show_bug.cgi?id=1202855 Signed-off-by: Ben Hutchings (cherry picked from commit 75cf667b7fac08a7b21694adca7dff07361be68a) Signed-off-by: Willy Tarreau