- 03 Oct, 2016 40 commits
-
-
Marcin Nowakowski authored
[ Upstream commit b244614a ] cpu_has_fpu macro uses smp_processor_id() and is currently executed with preemption enabled, that triggers the warning at runtime. It is assumed throughout the kernel that if any CPU has an FPU, then all CPUs would have an FPU as well, so it is safe to perform the check with preemption enabled - change the code to use raw_ variant of the check to avoid the warning. Signed-off-by:
Marcin Nowakowski <marcin.nowakowski@imgtec.com> Cc: linux-mips@linux-mips.org Cc: stable@vger.kernel.org # 4.0+ Patchwork: https://patchwork.linux-mips.org/patch/14125/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
Sasha Levin <alexander.levin@verizon.com>
-
Fabio Estevam authored
[ Upstream commit 4de349e7 ] On a imx6ul-pico board the following error is seen during system suspend: dpm_run_callback(): platform_pm_resume+0x0/0x54 returns -110 PM: Device 2090000.flexcan failed to resume: error -110 The reason for this suspend error is because when the CAN interface is not active the clocks are disabled and then flexcan_chip_enable() will always fail due to a timeout error. In order to fix this issue, only call flexcan_chip_enable/disable() when the CAN interface is active. Based on a patch from Dong Aisheng in the NXP kernel. Signed-off-by:
Fabio Estevam <fabio.estevam@nxp.com> Cc: linux-stable <stable@vger.kernel.org> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
-
Kristian H. Kristensen authored
[ Upstream commit 47a66e45 ] Similar to struct drm_update_draw, struct drm_mode_fb_cmd2 has an unaligned 64 bit field (modifier). This get packed differently between 32 bit and 64 bit modes on architectures that can handle unaligned 64 bit access (X86 and IA64). Other architectures pack the structs the same and don't need the compat wrapper. Use the same condition for drm_mode_fb_cmd2 as we use for drm_update_draw. Note that only the modifier will be packed differently between compat and non-compat versions. Reviewed-by:
Rob Clark <robdclark@gmail.com> Signed-off-by:
Kristian H. Kristensen <hoegsberg@chromium.org> [seanpaul added not at bottom of commit msg re: modifier] Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/1473801645-116011-1-git-send-email-hoegsberg@chromium.org Cc: stable@vger.kernel.org Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Al Viro authored
[ Upstream commit d4690f1e ] ... by turning it into what used to be multipages counterpart Cc: stable@vger.kernel.org Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Alan Stern authored
[ Upstream commit 08c5cd37 ] Some full-speed mceusb infrared transceivers contain invalid endpoint descriptors for their interrupt endpoints, with bInterval set to 0. In the past they have worked out okay with the mceusb driver, because the driver sets the bInterval field in the descriptor to 1, overwriting whatever value may have been there before. However, this approach was never sanctioned by the USB core, and in fact it does not work with xHCI controllers, because they use the bInterval value that was present when the configuration was installed. Currently usbcore uses 32 ms as the default interval if the value in the endpoint descriptor is invalid. It turns out that these IR transceivers don't work properly unless the interval is set to 10 ms or below. To work around this mceusb problem, this patch changes the endpoint-descriptor parsing routine, making the default interval value be 10 ms rather than 32 ms. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Tested-by:
Wade Berrier <wberrier@gmail.com> CC: <stable@vger.kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Al Viro authored
[ Upstream commit 1c109fab ] get_user_ex(x, ptr) should zero x on failure. It's not a lot of a leak (at most we are leaking uninitialized 64bit value off the kernel stack, and in a fairly constrained situation, at that), but the fix is trivial, so... Cc: stable@vger.kernel.org Signed-off-by:
-
Al Viro authored
[ Upstream commit 8630c322 ] really ugly, but apparently avr32 compilers turns access_ok() into something so bad that they want it in assembler. Left that way, zeroing added in inline wrapper. Cc: stable@vger.kernel.org Signed-off-by:
-
Al Viro authored
[ Upstream commit e98b9e37 ] Cc: stable@vger.kernel.org Signed-off-by:
-
Al Viro authored
[ Upstream commit d0cf3851 ] Cc: stable@vger.kernel.org Signed-off-by:
-
Al Viro authored
[ Upstream commit c90a3bc5 ] Cc: stable@vger.kernel.org Signed-off-by:
-
Al Viro authored
[ Upstream commit 8f035983 ] Cc: stable@vger.kernel.org Signed-off-by:
-
Al Viro authored
[ Upstream commit 917400ce ] Cc: stable@vger.kernel.org Acked-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Al Viro authored
[ Upstream commit 6e050503 ] Cc: stable@vger.kernel.org Signed-off-by:
-
Al Viro authored
[ Upstream commit c6852389 ] It could be done in exception-handling bits in __get_user_b() et.al., but the surgery involved would take more knowledge of sh64 details than I have or _want_ to have. Cc: stable@vger.kernel.org Signed-off-by:
-
Al Viro authored
[ Upstream commit b615e3c7 ] Cc: stable@vger.kernel.org Signed-off-by:
-
Al Viro authored
[ Upstream commit c2f18fa4 ] * should zero on any failure * __get_user() should use __copy_from_user(), not copy_from_user() Cc: stable@vger.kernel.org Signed-off-by:
-
Al Viro authored
[ Upstream commit fd2d2b19 ] Cc: stable@vger.kernel.org Signed-off-by:
-
Al Viro authored
[ Upstream commit 22426465 ] should clear on access_ok() failures. Also remove the useless range truncation logics. Cc: stable@vger.kernel.org Signed-off-by:
-
Al Viro authored
[ Upstream commit aace880f ] Cc: stable@vger.kernel.org Signed-off-by:
-
Al Viro authored
[ Upstream commit acb2505d ] ... that should zero on faults. Also remove the <censored> helpful logics wrt range truncation copied from ppc32. Where it had ever been needed only in case of copy_from_user() *and* had not been merged into the mainline until a month after the need had disappeared. A decade before openrisc went into mainline, I might add... Cc: stable@vger.kernel.org Signed-off-by:
-
Al Viro authored
[ Upstream commit 2e29f50a ] a) should not leave crap on fault b) should _not_ require access_ok() in any cases. Cc: stable@vger.kernel.org Signed-off-by:
-
Al Viro authored
[ Upstream commit e33d1f6f ] Cc: stable@vger.kernel.org Signed-off-by:
-
Al Viro authored
[ Upstream commit ae7cc577 ] Cc: stable@vger.kernel.org Signed-off-by:
-
Al Viro authored
[ Upstream commit 43403eab ] Cc: stable@vger.kernel.org Signed-off-by:
-
Al Viro authored
[ Upstream commit e69d7005 ] Cc: stable@vger.kernel.org Signed-off-by:
-
Vineet Gupta authored
[ Upstream commit 05d9d0b9 ] Al reported potential issue with ARC get_user() as it wasn't clearing out destination pointer in case of fault due to bad address etc. Verified using following | { | u32 bogus1 = 0xdeadbeef; | u64 bogus2 = 0xdead; | int rc1, rc2; | | pr_info("Orig values %x %llx\n", bogus1, bogus2); | rc1 = get_user(bogus1, (u32 __user *)0x40000000); | rc2 = get_user(bogus2, (u64 __user *)0x50000000); | pr_info("access %d %d, new values %x %llx\n", | rc1, rc2, bogus1, bogus2); | } | [ARCLinux]# insmod /mnt/kernel-module/qtn.ko | Orig values deadbeef dead | access -14 -14, new values 0 0 Reported-by:
Vineet Gupta <vgupta@synopsys.com> Signed-off-by:
-
Al Viro authored
[ Upstream commit 8ae95ed4 ] Cc: stable@vger.kernel.org Acked-by:
James Hogan <james.hogan@imgtec.com> Signed-off-by:
-
Al Viro authored
[ Upstream commit a5e541f7 ] Cc: stable@vger.kernel.org Signed-off-by:
-
Al Viro authored
[ Upstream commit f35c1e06 ] It's -EFAULT, not -1 (and contrary to the comment in there, __strnlen_user() can return 0 - on faults). Cc: stable@vger.kernel.org Acked-by:
Richard Kuo <rkuo@codeaurora.org> Signed-off-by:
-
Al Viro authored
[ Upstream commit 3b8767a8 ] It should check access_ok(). Otherwise a bunch of places turn into trivially exploitable rootholes. Cc: stable@vger.kernel.org Signed-off-by:
-
Al Viro authored
[ Upstream commit eb47e029 ] * copy_from_user() on access_ok() failure ought to zero the destination * none of those primitives should skip the access_ok() check in case of small constant size. Cc: stable@vger.kernel.org Acked-by:
Jesper Nilsson <jesper.nilsson@axis.com> Signed-off-by:
-
Al Viro authored
[ Upstream commit 9ad18b75 ] both for access_ok() failures and for faults halfway through Cc: stable@vger.kernel.org Signed-off-by:
-
Yoshinori Sato authored
[ Upstream commit a02613a4 ] Current implemantation ptr argument evaluate 2 times. It'll be an unexpected result. Changes v5: Remove unnecessary const. Changes v4: Temporary pointer type change to const void* Changes v3: Some build error fix. Changes v2: Argument x protect. Signed-off-by:
Yoshinori Sato <ysato@users.sourceforge.jp> Signed-off-by:
-
Johannes Berg authored
[ Upstream commit ad5987b4 ] Due to an apparent copy/paste bug, the number of counters for the beacon configuration were checked twice, instead of checking the number of probe response counters. Fix this to check the number of probe response counters before parsing those. Cc: stable@vger.kernel.org Fixes: 9a774c78 ("cfg80211: Support multiple CSA counters") Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Huacai Chen authored
[ Upstream commit 3cbc6fc9 ] Commit 842dfc11 ("MIPS: Fix build with binutils 2.24.51+") missing a ".set pop" in macro fpu_restore_16even, so add it. Signed-off-by:
Huacai Chen <chenhc@lemote.com> Acked-by:
Manuel Lauss <manuel.lauss@gmail.com> Cc: Steven J . Hill <Steven.Hill@caviumnetworks.com> Cc: Fuxin Zhang <zhangfx@lemote.com> Cc: Zhangjin Wu <wuzhangjin@gmail.com> Cc: linux-mips@linux-mips.org Cc: stable@vger.kernel.org # 3.18+ Patchwork: https://patchwork.linux-mips.org/patch/14210/Signed-off-by:
-
Boris Brezillon authored
[ Upstream commit ebf9ff75 ] Some irqchip drivers need to take the generic chip lock outside of the irq context. Provide the irq_gc_{lock_irqsave,unlock_irqrestore}() helpers to allow one to disable irqs while entering a critical section protected by gc->lock. Note that we do not provide optimized version of these helpers for !SMP, because they are not called from the hot-path. [ tglx: Added a comment when these helpers should be [not] used ] Signed-off-by:
Boris Brezillon <boris.brezillon@free-electrons.com> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Nicolas Ferre <nicolas.ferre@atmel.com> Cc: stable@vger.kernel.org Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com> Link: http://lkml.kernel.org/r/1473775109-4192-1-git-send-email-boris.brezillon@free-electrons.comSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Matt Redfearn authored
[ Upstream commit 951c39cd ] If the paravirt machine is compiles without CONFIG_SMP, the following linker error occurs arch/mips/kernel/head.o: In function `kernel_entry': (.ref.text+0x10): undefined reference to `smp_bootstrap' due to the kernel entry macro always including SMP startup code. Wrap this code in CONFIG_SMP to fix the error. Signed-off-by:
Matt Redfearn <matt.redfearn@imgtec.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org # 3.16+ Patchwork: https://patchwork.linux-mips.org/patch/14212/Signed-off-by:
-
Ard Biesheuvel authored
[ Upstream commit 2db34e78 ] The AES-CTR glue code avoids calling into the blkcipher API for the tail portion of the walk, by comparing the remainder of walk.nbytes modulo AES_BLOCK_SIZE with the residual nbytes, and jumping straight into the tail processing block if they are equal. This tail processing block checks whether nbytes != 0, and does nothing otherwise. However, in case of an allocation failure in the blkcipher layer, we may enter this code with walk.nbytes == 0, while nbytes > 0. In this case, we should not dereference the source and destination pointers, since they may be NULL. So instead of checking for nbytes != 0, check for (walk.nbytes % AES_BLOCK_SIZE) != 0, which implies the former in non-error conditions. Fixes: 49788fe2 ("arm64/crypto: AES-ECB/CBC/CTR/XTS using ARMv8 NEON and Crypto Extensions") Cc: stable@vger.kernel.org Reported-by:
xiakaixu <xiakaixu@huawei.com> Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Ard Biesheuvel authored
[ Upstream commit f82e90b2 ] The AES-CTR glue code avoids calling into the blkcipher API for the tail portion of the walk, by comparing the remainder of walk.nbytes modulo AES_BLOCK_SIZE with the residual nbytes, and jumping straight into the tail processing block if they are equal. This tail processing block checks whether nbytes != 0, and does nothing otherwise. However, in case of an allocation failure in the blkcipher layer, we may enter this code with walk.nbytes == 0, while nbytes > 0. In this case, we should not dereference the source and destination pointers, since they may be NULL. So instead of checking for nbytes != 0, check for (walk.nbytes % AES_BLOCK_SIZE) != 0, which implies the former in non-error conditions. Fixes: 86464859 ("crypto: arm - AES in ECB/CBC/CTR/XTS modes using ARMv8 Crypto Extensions") Cc: stable@vger.kernel.org Reported-by:
-
Herbert Xu authored
[ Upstream commit acdb04d0 ] When we need to allocate a temporary blkcipher_walk_next and it fails, the code is supposed to take the slow path of processing the data block by block. However, due to an unrelated change we instead end up dereferencing the NULL pointer. This patch fixes it by moving the unrelated bsize setting out of the way so that we enter the slow path as inteded. Fixes: 7607bd8f ("[CRYPTO] blkcipher: Added blkcipher_walk_virt_block") Cc: stable@vger.kernel.org Reported-by:
-
