commit d4c162c56b4b9af4dda113f865c23ee48df20ad4 Author: Greg Kroah-Hartman Date: Tue Oct 1 09:12:49 2013 -0700 Linux 3.4.64 commit 93751c2630fa7eb277b54274e7e7b6cd7660d9ac Author: Daniel Santos Date: Thu Oct 4 17:15:05 2012 -0700 kernel-doc: bugfix - multi-line macros commit 654784284430bf2739985914b65e09c7c35a7273 upstream. Prior to this patch the following code breaks: /** * multiline_example - this breaks kernel-doc */ #define multiline_example( \ myparam) Producing this error: Error(somefile.h:983): cannot understand prototype: 'multiline_example( \ ' This patch fixes the issue by appending all lines ending in a blackslash (optionally followed by whitespace), removing the backslash and any whitespace after it prior to appending (just like the C pre-processor would). This fixes a break in kerel-doc introduced by the additions to rbtree.h. Signed-off-by: Daniel Santos Cc: Randy Dunlap Cc: Michal Marek Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit 43cbf1f46f0cdc56db7a424c6dda57bd9288376e Author: Ben Hutchings Date: Fri Sep 6 22:39:20 2013 +0100 sfc: Fix efx_rx_buf_offset() for recycled pages This bug fix is only for stable branches older than 3.10. The bug was fixed upstream by commit 2768935a4660 ('sfc: reuse pages to avoid DMA mapping/unmapping costs'), but that change is totally unsuitable for stable. Commit b590ace09d51 ('sfc: Fix efx_rx_buf_offset() in the presence of swiotlb') added an explicit page_offset member to struct efx_rx_buffer, which must be set consistently with the u.page and dma_addr fields. However, it failed to add the necessary assignment in efx_resurrect_rx_buffer(). It also did not correct the calculation of efx_rx_buffer::dma_addr in efx_resurrect_rx_buffer(), which assumes that DMA-mapping a page will result in a page-aligned DMA address (exactly what swiotlb violates). Add the assignment of efx_rx_buffer::page_offset and change the calculation of dma_addr to make use of it. Signed-off-by: Ben Hutchings Acked-by: David Miller Signed-off-by: Greg Kroah-Hartman commit 4d75da4294e10475b3b255e34f446999832f4d17 Author: Andi Kleen Date: Wed Apr 24 17:03:02 2013 -0700 perf tools: Handle JITed code in shared memory commit 89365e6c9ad4c0e090e4c6a4b67a3ce319381d89 upstream. Need to check for /dev/zero. Most likely more strings are missing too. Signed-off-by: Andi Kleen Link: http://lkml.kernel.org/r/1366848182-30449-1-git-send-email-andi@firstfloor.org Signed-off-by: Arnaldo Carvalho de Melo Cc: Vinson Lee Signed-off-by: Greg Kroah-Hartman commit db68549fe3aee4045e1d7348b20d7c8baf4518c0 Author: Lino Sanfilippo Date: Fri Mar 23 02:42:23 2012 +0100 fanotify: dont merge permission events commit 03a1cec1f17ac1a6041996b3e40f96b5a2f90e1b upstream. Boyd Yang reported a problem for the case that multiple threads of the same thread group are waiting for a reponse for a permission event. In this case it is possible that some of the threads are never woken up, even if the response for the event has been received (see http://marc.info/?l=linux-kernel&m=131822913806350&w=2). The reason is that we are currently merging permission events if they belong to the same thread group. But we are not prepared to wake up more than one waiter for each event. We do wait_event(group->fanotify_data.access_waitq, event->response || atomic_read(&group->fanotify_data.bypass_perm)); and after that event->response = 0; which is the reason that even if we woke up all waiters for the same event some of them may see event->response being already set 0 again, then go back to sleep and block forever. With this patch we avoid that more than one thread is waiting for a response by not merging permission events for the same thread group any more. Reported-by: Boyd Yang Signed-off-by: Lino Sanfilippo Signed-off-by: Eric Paris Cc: Mihai Donțu Signed-off-by: Greg Kroah-Hartman commit 1d48ca6f38fa39298474708abebeffef4ef2cd2d Author: Peter Zijlstra Date: Tue Oct 2 15:41:23 2012 +0200 perf: Fix perf_cgroup_switch for sw-events commit 95cf59ea72331d0093010543b8951bb43f262cac upstream. Jiri reported that he could trigger the WARN_ON_ONCE() in perf_cgroup_switch() using sw-events. This is because sw-events share a cpuctx with multiple PMUs. Use the ->unique_pmu pointer to limit the pmu iteration to unique cpuctx instances. Reported-and-Tested-by: Jiri Olsa Signed-off-by: Peter Zijlstra Link: http://lkml.kernel.org/n/tip-so7wi2zf3jjzrwcutm2mkz0j@git.kernel.org Signed-off-by: Ingo Molnar Cc: Li Zefan Signed-off-by: Greg Kroah-Hartman commit 2cd21fa1b54efaf6b5912ef2833fa474fdcf92b7 Author: Peter Zijlstra Date: Tue Oct 2 15:38:52 2012 +0200 perf: Clarify perf_cpu_context::active_pmu usage by renaming it to ::unique_pmu commit 3f1f33206c16c7b3839d71372bc2ac3f305aa802 upstream. Stephane thought the perf_cpu_context::active_pmu name confusing and suggested using 'unique_pmu' instead. This pointer is a pointer to a 'random' pmu sharing the cpuctx instance, therefore limiting a for_each_pmu loop to those where cpuctx->unique_pmu matches the pmu we get a loop over unique cpuctx instances. Suggested-by: Stephane Eranian Signed-off-by: Peter Zijlstra Link: http://lkml.kernel.org/n/tip-kxyjqpfj2fn9gt7kwu5ag9ks@git.kernel.org Signed-off-by: Ingo Molnar Cc: Li Zefan Signed-off-by: Greg Kroah-Hartman commit 2927937899b958de968119856ba659d8a4eff037 Author: Li Zefan Date: Mon Feb 18 14:13:35 2013 +0800 cgroup: fail if monitored file and event_control are in different cgroup commit f169007b2773f285e098cb84c74aac0154d65ff7 upstream. If we pass fd of memory.usage_in_bytes of cgroup A to cgroup.event_control of cgroup B, then we won't get memory usage notification from A but B! What's worse, if A and B are in different mount hierarchy, we'll end up accessing NULL pointer! Disallow this kind of invalid usage. Signed-off-by: Li Zefan Acked-by: Kirill A. Shutemov Signed-off-by: Tejun Heo Cc: Weng Meiling Signed-off-by: Greg Kroah-Hartman commit 72417b659ae9c36e1807bc930240aec202970861 Author: Alex Deucher Date: Mon Sep 9 10:54:22 2013 -0400 drm/radeon/atom: workaround vbios bug in transmitter table on rs880 (v2) commit 91f3a6aaf280294b07c05dfe606e6c27b7ba3c72 upstream. The OUTPUT_ENABLE action jumps past the point in the coder where the data_offset is set on certain rs780 cards. This worked previously because the OUTPUT_ENABLE action is always called immediately after the ENABLE action so the data_offset remained set. In 6f8bbaf568c7f2c497558bfd04654c0b9841ad57 (drm/radeon/atom: initialize more atom interpretor elements to 0), we explictly reset data_offset to 0 between atom calls which then caused this to fail. The fix is to just skip calling the OUTPUT_ENABLE action on the problematic chipsets. The ENABLE action does the same thing and more. Ultimately, we could probably drop the OUTPUT_ENABLE action all together on DCE3 asics. fixes: https://bugzilla.kernel.org/show_bug.cgi?id=60791 v2: only rs880 seems to be affected Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit a59b428bd6a05560d7cb656849866e220946da87 Author: Alex Deucher Date: Tue Aug 27 12:36:01 2013 -0400 drm/radeon: fix handling of variable sized arrays for router objects commit fb93df1c2d8b3b1fb16d6ee9e32554e0c038815d upstream. The table has the following format: typedef struct _ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT //usSrcDstTableOffset pointing to this structure { UCHAR ucNumberOfSrc; USHORT usSrcObjectID[1]; UCHAR ucNumberOfDst; USHORT usDstObjectID[1]; }ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT; usSrcObjectID[] and usDstObjectID[] are variably sized, so we can't access them directly. Use pointers and update the offset appropriately when accessing the Dst members. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit b805676fd8265b428ff2a15b3aaa15adecc55bb8 Author: Alex Deucher Date: Mon Aug 26 17:52:12 2013 -0400 drm/radeon: fix resume on some rs4xx boards (v2) commit acf88deb8ddbb73acd1c3fa32fde51af9153227f upstream. Setting MC_MISC_CNTL.GART_INDEX_REG_EN causes hangs on some boards on resume. The systems seem to work fine without touching this bit so leave it as is. v2: read-modify-write the GART_INDEX_REG_EN bit. I suspect the problem is that we are losing the other settings in the register. fixes: https://bugs.freedesktop.org/show_bug.cgi?id=52952 Reported-by: Ondrej Zary Tested-by: Daniel Tobias Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit da2f15e84f3a463a2f643c0c9922126ebdc7233c Author: Alex Deucher Date: Mon Aug 19 11:15:43 2013 -0400 drm/radeon: update line buffer allocation for dce6 commit 290d24576ccf1aa0373d2185cedfe262d0d4952a upstream. We need to allocate line buffer to each display when setting up the watermarks. Failure to do so can lead to a blank screen. This fixes blank screen problems on dce6 asics. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=64850 Based on an initial fix from: Jay Cornwall Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit be70f1f28ecd59be723b3183539255944dad5df5 Author: Alex Deucher Date: Mon Aug 19 11:06:50 2013 -0400 drm/radeon: update line buffer allocation for dce4.1/5 commit 0b31e02363b0db4e7931561bc6c141436e729d9f upstream. We need to allocate line buffer to each display when setting up the watermarks. Failure to do so can lead to a blank screen. This fixes blank screen problems on dce4.1/5 asics. Based on an initial fix from: Jay Cornwall Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 63fffa36d35fedf0124522b8748a79e6817889e9 Author: Alex Deucher Date: Wed Aug 7 19:34:53 2013 -0400 drm/radeon: fix endian bugs in hw i2c atom routines commit 4543eda52113d1e2cc0e9bf416f79597e6ef1ec7 upstream. Need to swap the data fetched over i2c properly. This is the same fix as the endian fix for aux channel transactions. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit e3695a4006bcddfb92e7f04e7bbf9837972d2768 Author: Alex Deucher Date: Tue Aug 20 14:59:01 2013 -0400 drm/radeon: fix LCD record parsing commit 95663948ba22a4be8b99acd67fbf83e86ddffba4 upstream. If the LCD table contains an EDID record, properly account for the edid size when walking through the records. This should fix error messages about unknown LCD records. Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 0498605a9cf5417da2306b484f255282b2413688 Author: Ben Skeggs Date: Tue Sep 17 14:21:15 2013 +1000 drm/ttm: fix the tt_populated check in ttm_tt_destroy() commit 182b17c8dc4e83aab000ce86587b6810e515da87 upstream. After a vmalloc failure in ttm_dma_tt_alloc_page_directory(), ttm_dma_tt_init() will call ttm_tt_destroy() to cleanup, and end up inside the driver's unpopulate() hook when populate() has never yet been called. On nouveau, the first issue to be hit because of this is that dma_address[] may be a NULL pointer. After working around this, ttm_pool_unpopulate() may potentially hit the same issue with the pages[] array. It seems to make more sense to avoid calling unpopulate on already unpopulated TTMs than to add checks to all the implementations. Signed-off-by: Ben Skeggs Reviewed-by: Thomas Hellstrom Cc: Jerome Glisse Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit c931726692f5a8e294d96cec603d3e4ce4f34538 Author: Kees Cook Date: Wed Sep 11 21:56:56 2013 +0200 HID: logitech-dj: validate output report details commit 297502abb32e225fb23801fcdb0e4f6f8e17099a upstream. A HID device could send a malicious output report that would cause the logitech-dj HID driver to leak kernel memory contents to the device, or trigger a NULL dereference during initialization: [ 304.424553] usb 1-1: New USB device found, idVendor=046d, idProduct=c52b ... [ 304.780467] BUG: unable to handle kernel NULL pointer dereference at 0000000000000028 [ 304.781409] IP: [] logi_dj_recv_send_report.isra.11+0x1a/0x90 CVE-2013-2895 Signed-off-by: Kees Cook Signed-off-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit b77d6514bc7631d95528e63989dbb11d97c7c115 Author: Kees Cook Date: Wed Sep 11 21:56:51 2013 +0200 HID: zeroplus: validate output report details commit 78214e81a1bf43740ce89bb5efda78eac2f8ef83 upstream. The zeroplus HID driver was not checking the size of allocated values in fields it used. A HID device could send a malicious output report that would cause the driver to write beyond the output report allocation during initialization, causing a heap overflow: [ 1442.728680] usb 1-1: New USB device found, idVendor=0c12, idProduct=0005 ... [ 1466.243173] BUG kmalloc-192 (Tainted: G W ): Redzone overwritten CVE-2013-2889 Signed-off-by: Kees Cook Reviewed-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 0049b62c9efc4ef23492976512d4722b3e63de45 Author: Kees Cook Date: Wed Sep 11 21:56:50 2013 +0200 HID: provide a helper for validating hid reports commit 331415ff16a12147d57d5c953f3a961b7ede348b upstream. Many drivers need to validate the characteristics of their HID report during initialization to avoid misusing the reports. This adds a common helper to perform validation of the report exisitng, the field existing, and the expected number of values within the field. Signed-off-by: Kees Cook Reviewed-by: Benjamin Tissoires Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 62875332eafea9ee150a6037c0a1a20669e02aa1 Author: Daisuke Nishimura Date: Tue Sep 10 18:16:36 2013 +0900 sched/fair: Fix small race where child->se.parent,cfs_rq might point to invalid ones commit 6c9a27f5da9609fca46cb2b183724531b48f71ad upstream. There is a small race between copy_process() and cgroup_attach_task() where child->se.parent,cfs_rq points to invalid (old) ones. parent doing fork() | someone moving the parent to another cgroup -------------------------------+--------------------------------------------- copy_process() + dup_task_struct() -> parent->se is copied to child->se. se.parent,cfs_rq of them point to old ones. cgroup_attach_task() + cgroup_task_migrate() -> parent->cgroup is updated. + cpu_cgroup_attach() + sched_move_task() + task_move_group_fair() +- set_task_rq() -> se.parent,cfs_rq of parent are updated. + cgroup_fork() -> parent->cgroup is copied to child->cgroup. (*1) + sched_fork() + task_fork_fair() -> se.parent,cfs_rq of child are accessed while they point to old ones. (*2) In the worst case, this bug can lead to "use-after-free" and cause a panic, because it's new cgroup's refcount that is incremented at (*1), so the old cgroup(and related data) can be freed before (*2). In fact, a panic caused by this bug was originally caught in RHEL6.4. BUG: unable to handle kernel NULL pointer dereference at (null) IP: [] sched_slice+0x6e/0xa0 [...] Call Trace: [] place_entity+0x75/0xa0 [] task_fork_fair+0xaa/0x160 [] sched_fork+0x6b/0x140 [] copy_process+0x5b2/0x1450 [] ? wake_up_new_task+0xd9/0x130 [] do_fork+0x94/0x460 [] ? sys_wait4+0xae/0x100 [] sys_clone+0x28/0x30 [] stub_clone+0x13/0x20 [] ? system_call_fastpath+0x16/0x1b Signed-off-by: Daisuke Nishimura Signed-off-by: Peter Zijlstra Link: http://lkml.kernel.org/r/039601ceae06$733d3130$59b79390$@mxp.nes.nec.co.jp Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit ebce1a846aa297022fc372d59e6829d0453125f2 Author: Stanislaw Gruszka Date: Mon Aug 26 15:18:53 2013 +0200 rt2800: fix wrong TX power compensation commit 6e956da2027c767859128b9bfef085cf2a8e233b upstream. We should not do temperature compensation on devices without EXTERNAL_TX_ALC bit set (called DynamicTxAgcControl on vendor driver). Such devices can have totally bogus TSSI parameters on the EEPROM, but still threaded by us as valid and result doing wrong TX power calculations. This fix inability to connect to AP on slightly longer distance on some Ralink chips/devices. Reported-and-tested-by: Fabien ADAM Signed-off-by: Stanislaw Gruszka Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 9f76c47a322910215c42c2e4226f2bef173c84ea Author: Fabio Porcedda Date: Mon Sep 16 11:47:50 2013 +0200 net: usb: cdc_ether: Use wwan interface for Telit modules commit 0092820407901a0b2c4e343e85f96bb7abfcded1 upstream. Signed-off-by: Fabio Porcedda Acked-by: Oliver Neukum Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 1c1c7a7342cb6ef5976823616de9114554796592 Author: Greg Kroah-Hartman Date: Fri Sep 27 08:34:49 2013 -0700 Revert "sctp: fix call to SCTP_CMD_PROCESS_SACK in sctp_cmd_interpreter()" This reverts commit c2f5b7507ac5d808f29287d77ee6148358d7fbfe which is commit f6e80abeab928b7c47cc1fbf53df13b4398a2bec. Michal writes: Mainline commit f6e80abe was introduced in v3.7-rc2 as a follow-up fix to commit edfee033 sctp: check src addr when processing SACK to update transport state (from v3.7-rc1) which changed the interpretation of third argument to sctp_cmd_process_sack() and sctp_outq_sack(). But as commit edfee033 has never been backported to stable branches, backport of commit f6e80abe actually breaks the code rather than fixing it. Reported-by: Michal Kubecek Cc: Zijie Pan Cc: Nicolas Dichtel Cc: Vlad Yasevich Acked-by: David S. Miller Signed-off-by: Greg Kroah-Hartman