commit 0fbca6ce4174724f28be5268c5d210f51ed96e31 Author: Greg Kroah-Hartman Date: Sat Jan 30 13:54:11 2021 +0100 Linux 5.4.94 Link: https://lore.kernel.org/r/20210129105910.132680016@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 315cd8fc2ad2248948c6fc8b450f0a8bd8831e60 Author: Eric Biggers Date: Tue Jan 12 11:02:43 2021 -0800 fs: fix lazytime expiration handling in __writeback_single_inode() commit 1e249cb5b7fc09ff216aa5a12f6c302e434e88f9 upstream. When lazytime is enabled and an inode is being written due to its in-memory updated timestamps having expired, either due to a sync() or syncfs() system call or due to dirtytime_expire_interval having elapsed, the VFS needs to inform the filesystem so that the filesystem can copy the inode's timestamps out to the on-disk data structures. This is done by __writeback_single_inode() calling mark_inode_dirty_sync(), which then calls ->dirty_inode(I_DIRTY_SYNC). However, this occurs after __writeback_single_inode() has already cleared the dirty flags from ->i_state. This causes two bugs: - mark_inode_dirty_sync() redirties the inode, causing it to remain dirty. This wastefully causes the inode to be written twice. But more importantly, it breaks cases where sync_filesystem() is expected to clean dirty inodes. This includes the FS_IOC_REMOVE_ENCRYPTION_KEY ioctl (as reported at https://lore.kernel.org/r/20200306004555.GB225345@gmail.com), as well as possibly filesystem freezing (freeze_super()). - Since ->i_state doesn't contain I_DIRTY_TIME when ->dirty_inode() is called from __writeback_single_inode() for lazytime expiration, xfs_fs_dirty_inode() ignores the notification. (XFS only cares about lazytime expirations, and it assumes that i_state will contain I_DIRTY_TIME during those.) Therefore, lazy timestamps aren't persisted by sync(), syncfs(), or dirtytime_expire_interval on XFS. Fix this by moving the call to mark_inode_dirty_sync() to earlier in __writeback_single_inode(), before the dirty flags are cleared from i_state. This makes filesystems be properly notified of the timestamp expiration, and it avoids incorrectly redirtying the inode. This fixes xfstest generic/580 (which tests FS_IOC_REMOVE_ENCRYPTION_KEY) when run on ext4 or f2fs with lazytime enabled. It also fixes the new lazytime xfstest I've proposed, which reproduces the above-mentioned XFS bug (https://lore.kernel.org/r/20210105005818.92978-1-ebiggers@kernel.org). Alternatively, we could call ->dirty_inode(I_DIRTY_SYNC) directly. But due to the introduction of I_SYNC_QUEUED, mark_inode_dirty_sync() is the right thing to do because mark_inode_dirty_sync() now knows not to move the inode to a writeback list if it is currently queued for sync. Fixes: 0ae45f63d4ef ("vfs: add support for a lazytime mount option") Cc: stable@vger.kernel.org Depends-on: 5afced3bf281 ("writeback: Avoid skipping inode writeback") Link: https://lore.kernel.org/r/20210112190253.64307-2-ebiggers@kernel.org Suggested-by: Jan Kara Reviewed-by: Christoph Hellwig Reviewed-by: Jan Kara Signed-off-by: Eric Biggers Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 5f8b8fccdfbc7d05fb146b00d812a777370de71a Author: Jan Kara Date: Fri May 29 16:24:43 2020 +0200 writeback: Drop I_DIRTY_TIME_EXPIRE commit 5fcd57505c002efc5823a7355e21f48dd02d5a51 upstream. The only use of I_DIRTY_TIME_EXPIRE is to detect in __writeback_single_inode() that inode got there because flush worker decided it's time to writeback the dirty inode time stamps (either because we are syncing or because of age). However we can detect this directly in __writeback_single_inode() and there's no need for the strange propagation with I_DIRTY_TIME_EXPIRE flag. Reviewed-by: Christoph Hellwig Signed-off-by: Jan Kara Cc: Eric Biggers Signed-off-by: Greg Kroah-Hartman commit 2d8848edc96b43d1dd8823a533e702953048b33e Author: Mikulas Patocka Date: Wed Jan 20 13:59:11 2021 -0500 dm integrity: conditionally disable "recalculate" feature commit 5c02406428d5219c367c5f53457698c58bc5f917 upstream. Otherwise a malicious user could (ab)use the "recalculate" feature that makes dm-integrity calculate the checksums in the background while the device is already usable. When the system restarts before all checksums have been calculated, the calculation continues where it was interrupted even if the recalculate feature is not requested the next time the dm device is set up. Disable recalculating if we use internal_hash or journal_hash with a key (e.g. HMAC) and we don't have the "legacy_recalculate" flag. This may break activation of a volume, created by an older kernel, that is not yet fully recalculated -- if this happens, the user should add the "legacy_recalculate" flag to constructor parameters. Cc: stable@vger.kernel.org Signed-off-by: Mikulas Patocka Reported-by: Daniel Glockner Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 43546b74ce6cae3d0c2fa772970f2f3eeb2a0d6e Author: Jean-Philippe Brucker Date: Tue Nov 10 17:43:05 2020 +0100 tools: Factor HOSTCC, HOSTLD, HOSTAR definitions commit c8a950d0d3b926a02c7b2e713850d38217cec3d1 upstream. Several Makefiles in tools/ need to define the host toolchain variables. Move their definition to tools/scripts/Makefile.include Signed-off-by: Jean-Philippe Brucker Signed-off-by: Andrii Nakryiko Acked-by: Jiri Olsa Acked-by: Rafael J. Wysocki Link: https://lore.kernel.org/bpf/20201110164310.2600671-2-jean-philippe@linaro.org Cc: Alistair Delva Signed-off-by: Greg Kroah-Hartman commit ab85b382dcf7ba13d29d1693622c7ed8bfa4e98c Author: Steve French Date: Wed Dec 9 22:19:00 2020 -0600 SMB3.1.1: do not log warning message if server doesn't populate salt commit 7955f105afb6034af344038d663bc98809483cdd upstream. In the negotiate protocol preauth context, the server is not required to populate the salt (although it is done by most servers) so do not warn on mount. We retain the checks (warn) that the preauth context is the minimum size and that the salt does not exceed DataLength of the SMB response. Although we use the defaults in the case that the preauth context response is invalid, these checks may be useful in the future as servers add support for additional mechanisms. CC: Stable Reviewed-by: Shyam Prasad N Reviewed-by: Pavel Shilovsky Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 0edc78af73d054d01dc14d7344024362811d8bd3 Author: Ard Biesheuvel Date: Thu Oct 8 17:35:59 2020 +0200 arm64: mm: use single quantity to represent the PA to VA translation commit 7bc1a0f9e1765830e945669c99c59c35cf9bca82 upstream. On arm64, the global variable memstart_addr represents the physical address of PAGE_OFFSET, and so physical to virtual translations or vice versa used to come down to simple additions or subtractions involving the values of PAGE_OFFSET and memstart_addr. When support for 52-bit virtual addressing was introduced, we had to deal with PAGE_OFFSET potentially being outside of the region that can be covered by the virtual range (as the 52-bit VA capable build needs to be able to run on systems that are only 48-bit VA capable), and for this reason, another translation was introduced, and recorded in the global variable physvirt_offset. However, if we go back to the original definition of memstart_addr, i.e., the physical address of PAGE_OFFSET, it turns out that there is no need for two separate translations: instead, we can simply subtract the size of the unaddressable VA space from memstart_addr to make the available physical memory appear in the 48-bit addressable VA region. This simplifies things, but also fixes a bug on KASLR builds, which may update memstart_addr later on in arm64_memblock_init(), but fails to update vmemmap and physvirt_offset accordingly. Fixes: 5383cc6efed1 ("arm64: mm: Introduce vabits_actual") Signed-off-by: Ard Biesheuvel Reviewed-by: Steve Capper Link: https://lore.kernel.org/r/20201008153602.9467-2-ardb@kernel.org Signed-off-by: Will Deacon Signed-off-by: Catalin Marinas Signed-off-by: Vincenzo Frascino Signed-off-by: Greg Kroah-Hartman commit b899d5b2a42a963d6ca7e33d51a35b2eb25f6d10 Author: Gaurav Kohli Date: Tue Oct 6 15:03:53 2020 +0530 tracing: Fix race in trace_open and buffer resize call commit bbeb97464eefc65f506084fd9f18f21653e01137 upstream. Below race can come, if trace_open and resize of cpu buffer is running parallely on different cpus CPUX CPUY ring_buffer_resize atomic_read(&buffer->resize_disabled) tracing_open tracing_reset_online_cpus ring_buffer_reset_cpu rb_reset_cpu rb_update_pages remove/insert pages resetting pointer This race can cause data abort or some times infinte loop in rb_remove_pages and rb_insert_pages while checking pages for sanity. Take buffer lock to fix this. Link: https://lkml.kernel.org/r/1601976833-24377-1-git-send-email-gkohli@codeaurora.org Cc: stable@vger.kernel.org Fixes: 83f40318dab00 ("ring-buffer: Make removal of ring buffer pages atomic") Reported-by: Denis Efremov Signed-off-by: Gaurav Kohli Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit c4a23c852e80a3921f56c6fbc851a21c84a6d06b Author: Nicolai Stange Date: Wed Jan 27 14:34:43 2021 +0100 io_uring: Fix current->fs handling in io_sq_wq_submit_work() No upstream commit, this is a fix to a stable 5.4 specific backport. The intention of backport commit cac68d12c531 ("io_uring: grab ->fs as part of async offload") as found in the stable 5.4 tree was to make io_sq_wq_submit_work() to switch the workqueue task's ->fs over to the submitting task's one during the IO operation. However, due to a small logic error, this change turned out to not have any actual effect. From a high level, the relevant code in io_sq_wq_submit_work() looks like old_fs_struct = current->fs; do { ... if (req->fs != current->fs && current->fs != old_fs_struct) { task_lock(current); if (req->fs) current->fs = req->fs; else current->fs = old_fs_struct; task_unlock(current); } ... } while (req); The if condition is supposed to cover the case that current->fs doesn't match what's needed for processing the request, but observe how it fails to ever evaluate to true due to the second clause: current->fs != old_fs_struct will be false in the first iteration as per the initialization of old_fs_struct and because this prevents current->fs from getting replaced, the same follows inductively for all subsequent iterations. Fix said if condition such that - if req->fs is set and doesn't match current->fs, the latter will be switched to the former - or if req->fs is unset, the switch back to the initial old_fs_struct will be made, if necessary. While at it, also correct the condition for the ->fs related cleanup right before the return of io_sq_wq_submit_work(): currently, old_fs_struct is restored only if it's non-NULL. It is always non-NULL though and thus, the if-condition is rendundant. Supposedly, the motivation had been to optimize and avoid switching current->fs back to the initial old_fs_struct in case it is found to have the desired value already. Make it so. Cc: stable@vger.kernel.org # v5.4 Fixes: cac68d12c531 ("io_uring: grab ->fs as part of async offload") Reviewed-by: Jens Axboe Signed-off-by: Nicolai Stange Signed-off-by: Greg Kroah-Hartman commit 336bb7dc5a1cc30b88b97652642ab82a104544a0 Author: Jason Gerecke Date: Thu Jan 21 10:46:49 2021 -0800 HID: wacom: Correct NULL dereference on AES pen proximity commit 179e8e47c02a1950f1c556f2b854bdb2259078fb upstream. The recent commit to fix a memory leak introduced an inadvertant NULL pointer dereference. The `wacom_wac->pen_fifo` variable was never intialized, resuling in a crash whenever functions tried to use it. Since the FIFO is only used by AES pens (to buffer events from pen proximity until the hardware reports the pen serial number) this would have been easily overlooked without testing an AES device. This patch converts `wacom_wac->pen_fifo` over to a pointer (since the call to `devres_alloc` allocates memory for us) and ensures that we assign it to point to the allocated and initalized `pen_fifo` before the function returns. Link: https://github.com/linuxwacom/input-wacom/issues/230 Fixes: 37309f47e2f5 ("HID: wacom: Fix memory leakage caused by kfifo_alloc") CC: stable@vger.kernel.org # v4.19+ Signed-off-by: Jason Gerecke Tested-by: Ping Cheng Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit ecd62d2e9ab405d9575c3aa8eb44e44e523a0d19 Author: Thomas Gleixner Date: Mon Jan 18 19:01:21 2021 +0100 futex: Handle faults correctly for PI futexes commit 34b1a1ce1458f50ef27c54e28eb9b1947012907a upstream fixup_pi_state_owner() tries to ensure that the state of the rtmutex, pi_state and the user space value related to the PI futex are consistent before returning to user space. In case that the user space value update faults and the fault cannot be resolved by faulting the page in via fault_in_user_writeable() the function returns with -EFAULT and leaves the rtmutex and pi_state owner state inconsistent. A subsequent futex_unlock_pi() operates on the inconsistent pi_state and releases the rtmutex despite not owning it which can corrupt the RB tree of the rtmutex and cause a subsequent kernel stack use after free. It was suggested to loop forever in fixup_pi_state_owner() if the fault cannot be resolved, but that results in runaway tasks which is especially undesired when the problem happens due to a programming error and not due to malice. As the user space value cannot be fixed up, the proper solution is to make the rtmutex and the pi_state consistent so both have the same owner. This leaves the user space value out of sync. Any subsequent operation on the futex will fail because the 10th rule of PI futexes (pi_state owner and user space value are consistent) has been violated. As a consequence this removes the inept attempts of 'fixing' the situation in case that the current task owns the rtmutex when returning with an unresolvable fault by unlocking the rtmutex which left pi_state::owner and rtmutex::owner out of sync in a different and only slightly less dangerous way. Fixes: 1b7558e457ed ("futexes: fix fault handling in futex_lock_pi") Reported-by: gzobqq@gmail.com Signed-off-by: Thomas Gleixner Acked-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 55ea172ce3ebe276e734352eb1b236b3065496c3 Author: Thomas Gleixner Date: Tue Jan 19 16:26:38 2021 +0100 futex: Simplify fixup_pi_state_owner() commit f2dac39d93987f7de1e20b3988c8685523247ae2 upstream Too many gotos already and an upcoming fix would make it even more unreadable. Signed-off-by: Thomas Gleixner Acked-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit a3155c362ca0a4677d0c886798bbeb5f0a9efe86 Author: Thomas Gleixner Date: Wed Jan 20 11:35:19 2021 +0100 futex: Use pi_state_update_owner() in put_pi_state() commit 6ccc84f917d33312eb2846bd7b567639f585ad6d upstream No point in open coding it. This way it gains the extra sanity checks. Signed-off-by: Thomas Gleixner Acked-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit ceb83cf9ed6764977c86a03fe187578def3b4e18 Author: Thomas Gleixner Date: Wed Jan 20 11:32:07 2021 +0100 rtmutex: Remove unused argument from rt_mutex_proxy_unlock() commit 2156ac1934166d6deb6cd0f6ffc4c1076ec63697 upstream Nothing uses the argument. Remove it as preparation to use pi_state_update_owner(). Signed-off-by: Thomas Gleixner Acked-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 015b6a4c2564a9385401a6105e80a20c333e1d44 Author: Thomas Gleixner Date: Tue Jan 19 15:21:35 2021 +0100 futex: Provide and use pi_state_update_owner() commit c5cade200ab9a2a3be9e7f32a752c8d86b502ec7 upstream Updating pi_state::owner is done at several places with the same code. Provide a function for it and use that at the obvious places. This is also a preparation for a bug fix to avoid yet another copy of the same code or alternatively introducing a completely unpenetratable mess of gotos. Originally-by: Peter Zijlstra Signed-off-by: Thomas Gleixner Acked-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 65aad57cac8db8dd0d1dcdd86bc8603039d937b7 Author: Thomas Gleixner Date: Tue Jan 19 16:06:10 2021 +0100 futex: Replace pointless printk in fixup_owner() commit 04b79c55201f02ffd675e1231d731365e335c307 upstream If that unexpected case of inconsistent arguments ever happens then the futex state is left completely inconsistent and the printk is not really helpful. Replace it with a warning and make the state consistent. Signed-off-by: Thomas Gleixner Acked-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 0dae88a92596db9405fd4a341c1915cf7d8fbad4 Author: Thomas Gleixner Date: Wed Jan 20 16:00:24 2021 +0100 futex: Ensure the correct return value from futex_lock_pi() commit 12bb3f7f1b03d5913b3f9d4236a488aa7774dfe9 upstream In case that futex_lock_pi() was aborted by a signal or a timeout and the task returned without acquiring the rtmutex, but is the designated owner of the futex due to a concurrent futex_unlock_pi() fixup_owner() is invoked to establish consistent state. In that case it invokes fixup_pi_state_owner() which in turn tries to acquire the rtmutex again. If that succeeds then it does not propagate this success to fixup_owner() and futex_lock_pi() returns -EINTR or -ETIMEOUT despite having the futex locked. Return success from fixup_pi_state_owner() in all cases where the current task owns the rtmutex and therefore the futex and propagate it correctly through fixup_owner(). Fixup the other callsite which does not expect a positive return value. Fixes: c1e2f0eaf015 ("futex: Avoid violating the 10th rule of futex") Signed-off-by: Thomas Gleixner Acked-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit c27a2a1ecf699ed8d77eafa59ae28d81347eac20 Author: Wang Hai Date: Thu Jan 28 19:32:50 2021 +0800 Revert "mm/slub: fix a memory leak in sysfs_slab_add()" commit 757fed1d0898b893d7daa84183947c70f27632f3 upstream. This reverts commit dde3c6b72a16c2db826f54b2d49bdea26c3534a2. syzbot report a double-free bug. The following case can cause this bug. - mm/slab_common.c: create_cache(): if the __kmem_cache_create() fails, it does: out_free_cache: kmem_cache_free(kmem_cache, s); - but __kmem_cache_create() - at least for slub() - will have done sysfs_slab_add(s) -> sysfs_create_group() .. fails .. -> kobject_del(&s->kobj); .. which frees s ... We can't remove the kmem_cache_free() in create_cache(), because other error cases of __kmem_cache_create() do not free this. So, revert the commit dde3c6b72a16 ("mm/slub: fix a memory leak in sysfs_slab_add()") to fix this. Reported-by: syzbot+d0bd96b4696c1ef67991@syzkaller.appspotmail.com Fixes: dde3c6b72a16 ("mm/slub: fix a memory leak in sysfs_slab_add()") Acked-by: Vlastimil Babka Signed-off-by: Wang Hai Cc: Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 4afd772371d98e7569e26286c217db34479bb82b Author: Baruch Siach Date: Sun Jan 17 15:17:02 2021 +0200 gpio: mvebu: fix pwm .get_state period calculation commit e73b0101ae5124bf7cd3fb5d250302ad2f16a416 upstream. The period is the sum of on and off values. That is, calculate period as ($on + $off) / clkrate instead of $off / clkrate - $on / clkrate that makes no sense. Reported-by: Russell King Reviewed-by: Uwe Kleine-König Fixes: 757642f9a584e ("gpio: mvebu: Add limited PWM support") Signed-off-by: Baruch Siach Signed-off-by: Bartosz Golaszewski [baruch: backport to kernels <= v5.10] Reviewed-by: Uwe Kleine-König Signed-off-by: Baruch Siach Signed-off-by: Greg Kroah-Hartman