Linux kernel stable tree https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/atom?h=linux-4.19.y 2024-09-04T11:13:07+00:00 2024-09-04T11:13:07+00:00 Long Li leo.lilong@huawei.com 2024-08-16T05:08:48+00:00 urn:sha1:a1177ea83da87a87cc352aa41f24d61c08c80b5d The locks_remove_posix() function in fcntl_setlk/fcntl_setlk64 is designed to reliably remove locks when an fcntl/close race is detected. However, it was passing in the wrong filelock owner, it looks like a mistake and resulting in a failure to remove locks. More critically, if the lock removal fails, it could lead to a uaf issue while traversing the locks. This problem occurs only in the 4.19/5.4 stable version. Fixes: a561145f3ae9 ("filelock: Fix fcntl/close race recovery compat path") Fixes: d30ff3304083 ("filelock: Remove locks reliably when fcntl/close race is detected") Cc: stable@vger.kernel.org Signed-off-by: Long Li <leo.lilong@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2024-07-27T08:33:44+00:00 Jann Horn jannh@google.com 2024-07-23T15:03:56+00:00 urn:sha1:a561145f3ae973ebf3e0aee41624e92a6c5cb38d commit f8138f2ad2f745b9a1c696a05b749eabe44337ea upstream. When I wrote commit 3cad1bc01041 ("filelock: Remove locks reliably when fcntl/close race is detected"), I missed that there are two copies of the code I was patching: The normal version, and the version for 64-bit offsets on 32-bit kernels. Thanks to Greg KH for stumbling over this while doing the stable backport... Apply exactly the same fix to the compat path for 32-bit kernels. Fixes: c293621bbf67 ("[PATCH] stale POSIX lock handling") Cc: stable@kernel.org Link: https://bugs.chromium.org/p/project-zero/issues/detail?id=2563 Signed-off-by: Jann Horn <jannh@google.com> Link: https://lore.kernel.org/r/20240723-fs-lock-recover-compatfix-v1-1-148096719529@google.com Signed-off-by: Christian Brauner <brauner@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2024-07-27T08:33:43+00:00 Jann Horn jannh@google.com 2024-07-02T16:26:52+00:00 urn:sha1:d30ff33040834c3b9eee29740acd92f9c7ba2250 commit 3cad1bc010416c6dd780643476bc59ed742436b9 upstream. When fcntl_setlk() races with close(), it removes the created lock with do_lock_file_wait(). However, LSMs can allow the first do_lock_file_wait() that created the lock while denying the second do_lock_file_wait() that tries to remove the lock. In theory (but AFAIK not in practice), posix_lock_file() could also fail to remove a lock due to GFP_KERNEL allocation failure (when splitting a range in the middle). After the bug has been triggered, use-after-free reads will occur in lock_get_status() when userspace reads /proc/locks. This can likely be used to read arbitrary kernel memory, but can't corrupt kernel memory. This only affects systems with SELinux / Smack / AppArmor / BPF-LSM in enforcing mode and only works from some security contexts. Fix it by calling locks_remove_posix() instead, which is designed to reliably get rid of POSIX locks associated with the given file and files_struct and is also used by filp_flush(). Fixes: c293621bbf67 ("[PATCH] stale POSIX lock handling") Cc: stable@kernel.org Link: https://bugs.chromium.org/p/project-zero/issues/detail?id=2563 Signed-off-by: Jann Horn <jannh@google.com> Link: https://lore.kernel.org/r/20240702-fs-lock-recover-2-v1-1-edd456f63789@google.com Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Christian Brauner <brauner@kernel.org> [stable fixup: ->c.flc_type was ->fl_type in older kernels] Signed-off-by: Jann Horn <jannh@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2020-01-09T09:19:00+00:00 Amir Goldstein amir73il@gmail.com 2019-12-22T18:45:28+00:00 urn:sha1:0211f27ac1df13e3f670ac84232719a2f8930bfc commit 98ca480a8f22fdbd768e3dad07024c8d4856576c upstream. An ino is unsigned, so display it as such in /proc/locks. Cc: stable@vger.kernel.org Signed-off-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2018-08-22T01:19:09+00:00 Linus Torvalds torvalds@linux-foundation.org 2018-08-22T01:19:09+00:00 urn:sha1:d9a185f8b49678775ef56ecbdbc7b76970302897 Pull overlayfs updates from Miklos Szeredi: "This contains two new features: - Stack file operations: this allows removal of several hacks from the VFS, proper interaction of read-only open files with copy-up, possibility to implement fs modifying ioctls properly, and others. - Metadata only copy-up: when file is on lower layer and only metadata is modified (except size) then only copy up the metadata and continue to use the data from the lower file" * tag 'ovl-update-4.19' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs: (66 commits) ovl: Enable metadata only feature ovl: Do not do metacopy only for ioctl modifying file attr ovl: Do not do metadata only copy-up for truncate operation ovl: add helper to force data copy-up ovl: Check redirect on index as well ovl: Set redirect on upper inode when it is linked ovl: Set redirect on metacopy files upon rename ovl: Do not set dentry type ORIGIN for broken hardlinks ovl: Add an inode flag OVL_CONST_INO ovl: Treat metacopy dentries as type OVL_PATH_MERGE ovl: Check redirects for metacopy files ovl: Move some dir related ovl_lookup_single() code in else block ovl: Do not expose metacopy only dentry from d_real() ovl: Open file with data except for the case of fsync ovl: Add helper ovl_inode_realdata() ovl: Store lower data inode in ovl_inode ovl: Fix ovl_getattr() to get number of blocks from lower ovl: Add helper ovl_dentry_lowerdata() to get lower data dentry ovl: Copy up meta inode data from lowest data inode ovl: Modify ovl_lookup() and friends to lookup metacopy dentry ... 2018-08-21T20:47:29+00:00 Linus Torvalds torvalds@linux-foundation.org 2018-08-21T20:47:29+00:00 urn:sha1:0214f46b3a0383d6e33c297e7706216b6a550e4b Pull core signal handling updates from Eric Biederman: "It was observed that a periodic timer in combination with a sufficiently expensive fork could prevent fork from every completing. This contains the changes to remove the need for that restart. This set of changes is split into several parts: - The first part makes PIDTYPE_TGID a proper pid type instead something only for very special cases. The part starts using PIDTYPE_TGID enough so that in __send_signal where signals are actually delivered we know if the signal is being sent to a a group of processes or just a single process. - With that prep work out of the way the logic in fork is modified so that fork logically makes signals received while it is running appear to be received after the fork completes" * 'siginfo-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace: (22 commits) signal: Don't send signals to tasks that don't exist signal: Don't restart fork when signals come in. fork: Have new threads join on-going signal group stops fork: Skip setting TIF_SIGPENDING in ptrace_init_task signal: Add calculate_sigpending() fork: Unconditionally exit if a fatal signal is pending fork: Move and describe why the code examines PIDNS_ADDING signal: Push pid type down into complete_signal. signal: Push pid type down into __send_signal signal: Push pid type down into send_signal signal: Pass pid type into do_send_sig_info signal: Pass pid type into send_sigio_to_task & send_sigurg_to_task signal: Pass pid type into group_send_sig_info signal: Pass pid and pid type into send_sigqueue posix-timers: Noralize good_sigevent signal: Use PIDTYPE_TGID to clearly store where file signals will be sent pid: Implement PIDTYPE_TGID pids: Move the pgrp and session pid pointers from task_struct to signal_struct kvm: Don't open code task_pid in kvm_vcpu_ioctl pids: Compute task_tgid using signal->leader_pid ... 2018-08-14T04:56:50+00:00 Linus Torvalds torvalds@linux-foundation.org 2018-08-14T04:56:50+00:00 urn:sha1:575b94386bd539a7d803aee9fd4a8d275844c40f Pull file locking updates from Jeff Layton: "Just a couple of patches from Konstantin to fix /proc/locks when the process that set the lock has exited, and a new tracepoint for the flock() codepath. Also threw in mailmap entries for my addresses and a comment cleanup" * tag 'locks-v4.19-1' of git://git.kernel.org/pub/scm/linux/kernel/git/jlayton/linux: locks: remove misleading obsolete comment mailmap: remap some of my email addresses to kernel.org address locks: add tracepoint in flock codepath fs/lock: show locks taken by processes from another pidns fs/lock: skip lock owner pid translation in case we are in init_pid_ns 2018-08-08T16:59:06+00:00 Jeff Layton jlayton@kernel.org 2018-08-08T16:54:09+00:00 urn:sha1:da33a871ba178dbe81da7d755818d3c2088cae32 The spinlock handling in this file has changed significantly since this comment was written, and the file_lock_lock is no more. In addition, this overall comment no longer applies. Deleting an entry now requires both locks. Signed-off-by: Jeff Layton <jlayton@kernel.org> 2018-08-06T17:15:16+00:00 Jeff Layton jlayton@kernel.org 2018-07-30T11:54:56+00:00 urn:sha1:c883da313ebf459efd33d262ca963e3a5f0ac024 Signed-off-by: Jeff Layton <jlayton@kernel.org> 2018-07-21T15:43:12+00:00 Eric W. Biederman ebiederm@xmission.com 2017-07-17T03:05:57+00:00 urn:sha1:019191342fecce4a461978a7191a43f313e19e86 When f_setown is called a pid and a pid type are stored. Replace the use of PIDTYPE_PID with PIDTYPE_TGID as PIDTYPE_TGID goes to the entire thread group. Replace the use of PIDTYPE_MAX with PIDTYPE_PID as PIDTYPE_PID now is only for a thread. Update the users of __f_setown to use PIDTYPE_TGID instead of PIDTYPE_PID. For now the code continues to capture task_pid (when task_tgid would really be appropriate), and iterate on PIDTYPE_PID (even when type == PIDTYPE_TGID) out of an abundance of caution to preserve existing behavior. Oleg Nesterov suggested using the test to ensure we use PIDTYPE_PID for tgid lookup also be used to avoid taking the tasklist lock. Suggested-by: Oleg Nesterov <oleg@redhat.com> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>