- 03 Oct, 2016 40 commits
-
-
Al Viro authored
[ Upstream commit e23d4159 ] Switching iov_iter fault-in to multipages variants has exposed an old bug in underlying fault_in_multipages_...(); they break if the range passed to them wraps around. Normally access_ok() done by callers will prevent such (and it's a guaranteed EFAULT - ERR_PTR() values fall into such a range and they should not point to any valid objects). However, on architectures where userland and kernel live in different MMU contexts (e.g. s390) access_ok() is a no-op and on those a range with a wraparound can reach fault_in_multipages_...(). Since any wraparound means EFAULT there, the fix is trivial - turn those while (uaddr <= end) ... into if (unlikely(uaddr > end)) return -EFAULT; do ... while (uaddr <= end); Reported-by:
Jan Stancek <jstancek@redhat.com> Tested-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Sasha Levin <alexander.levin@verizon.com>
-
Ashish Samant authored
[ Upstream commit d21c353d ] If we punch a hole on a reflink such that following conditions are met: 1. start offset is on a cluster boundary 2. end offset is not on a cluster boundary 3. (end offset is somewhere in another extent) or (hole range > MAX_CONTIG_BYTES(1MB)), we dont COW the first cluster starting at the start offset. But in this case, we were wrongly passing this cluster to ocfs2_zero_range_for_truncate() to zero out. This will modify the cluster in place and zero it in the source too. Fix this by skipping this cluster in such a scenario. To reproduce: 1. Create a random file of say 10 MB xfs_io -c 'pwrite -b 4k 0 10M' -f 10MBfile 2. Reflink it reflink -f 10MBfile reflnktest 3. Punch a hole at starting at cluster boundary with range greater that 1MB. You can also use a range that will put the end offset in another extent. fallocate -p -o 0 -l 1048615 reflnktest 4. sync 5. Check the first cluster in the source file. (It will be zeroed out). dd if=10MBfile iflag=direct bs=<cluster size> count=1 | hexdump -C Link: http://lkml.kernel.org/r/1470957147-14185-1-git-send-email-ashish.samant@oracle.comSigned-off-by:
Ashish Samant <ashish.samant@oracle.com> Reported-by:
Saar Maoz <saar.maoz@oracle.com> Reviewed-by:
Srinivas Eeda <srinivas.eeda@oracle.com> Cc: Mark Fasheh <mfasheh@suse.de> Cc: Joel Becker <jlbec@evilplan.org> Cc: Junxiao Bi <junxiao.bi@oracle.com> Cc: Joseph Qi <joseph.qi@huawei.com> Cc: Eric Ren <zren@suse.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Jan Kara authored
[ Upstream commit 96d41019 ] fanotify_get_response() calls fsnotify_remove_event() when it finds that group is being released from fanotify_release() (bypass_perm is set). However the event it removes need not be only in the group's notification queue but it can have already moved to access_list (userspace read the event before closing the fanotify instance fd) which is protected by a different lock. Thus when fsnotify_remove_event() races with fanotify_release() operating on access_list, the list can get corrupted. Fix the problem by moving all the logic removing permission events from the lists to one place - fanotify_release(). Fixes: 5838d444 ("fanotify: fix double free of pending permission events") Link: http://lkml.kernel.org/r/1473797711-14111-3-git-send-email-jack@suse.czSigned-off-by:
Jan Kara <jack@suse.cz> Reported-by:
Miklos Szeredi <mszeredi@redhat.com> Tested-by:
-
Jan Kara authored
[ Upstream commit 12703dbf ] Implement a function that can be called when a group is being shutdown to stop queueing new events to the group. Fanotify will use this. Fixes: 5838d444 ("fanotify: fix double free of pending permission events") Link: http://lkml.kernel.org/r/1473797711-14111-2-git-send-email-jack@suse.czSigned-off-by:
-
Ian Kent authored
[ Upstream commit 7cbdb4a2 ] Somewhere along the way the autofs expire operation has changed to hold a spin lock over expired dentry selection. The autofs indirect mount expired dentry selection is complicated and quite lengthy so it isn't appropriate to hold a spin lock over the operation. Commit 47be6184 ("fs/dcache.c: avoid soft-lockup in dput()") added a might_sleep() to dput() causing a WARN_ONCE() about this usage to be issued. But the spin lock doesn't need to be held over this check, the autofs dentry info. flags are enough to block walks into dentrys during the expire. I've left the direct mount expire as it is (for now) because it is much simpler and quicker than the indirect mount expire and adding spin lock release and re-aquires would do nothing more than add overhead. Fixes: 47be6184 ("fs/dcache.c: avoid soft-lockup in dput()") Link: http://lkml.kernel.org/r/20160912014017.1773.73060.stgit@pluto.themaw.netSigned-off-by:
Ian Kent <raven@themaw.net> Reported-by:
Takashi Iwai <tiwai@suse.de> Tested-by:
-
Al Viro authored
[ Upstream commit ea01a184 ] * make autofs4_expire_indirect() skip the dentries being in process of expiry * do *not* mess with list_move(); making sure that dentry with AUTOFS_INF_EXPIRING are not picked for expiry is enough. * do not remove NO_RCU when we set EXPIRING, don't bother with smp_mb() there. Clear it at the same time we clear EXPIRING. Makes a bunch of tests simpler. * rename NO_RCU to WANT_EXPIRE, which is what it really is. Signed-off-by:
-
Joseph Qi authored
[ Upstream commit e6f0c6e6 ] Commit ac7cf246 ("ocfs2/dlm: fix race between convert and recovery") checks if lockres master has changed to identify whether new master has finished recovery or not. This will introduce a race that right after old master does umount ( means master will change), a new convert request comes. In this case, it will reset lockres state to DLM_RECOVERING and then retry convert, and then fail with lockres->l_action being set to OCFS2_AST_INVALID, which will cause inconsistent lock level between ocfs2 and dlm, and then finally BUG. Since dlm recovery will clear lock->convert_pending in dlm_move_lockres_to_recovery_list, we can use it to correctly identify the race case between convert and recovery. So fix it. Fixes: ac7cf246 ("ocfs2/dlm: fix race between convert and recovery") Link: http://lkml.kernel.org/r/57CE1569.8010704@huawei.comSigned-off-by:
Joseph Qi <joseph.qi@huawei.com> Signed-off-by:
Jun Piao <piaojun@huawei.com> Cc: Mark Fasheh <mfasheh@suse.de> Cc: Joel Becker <jlbec@evilplan.org> Cc: Junxiao Bi <junxiao.bi@oracle.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
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:
-
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:
-
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:
-
