- 20 Apr, 2017 2 commits
-
-
Stefan Bader authored
Signed-off-by:Stefan Bader <stefan.bader@canonical.com>
-
Vitaly Kuznetsov authored
BugLink: http://bugs.launchpad.net/bugs/1682561 Waiting for release_event in all three drivers introduced issues on release as on_reset() hook is not always called. E.g. if the device was never opened we will never get the completion. Move the waiting code to hvutil_transport_destroy() and make sure it is only called when the device is open. hvt->lock serialization should guarantee the absence of races. Fixes: 5a66fecb ("Drivers: hv: util: kvp: Fix a rescind processing issue") Fixes: 20951c75 ("Drivers: hv: util: Fcopy: Fix a rescind processing issue") Fixes: d77044d1 ("Drivers: hv: util: Backup: Fix a rescind processing issue") Reported-by:
Dexuan Cui <decui@microsoft.com> Tested-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit e9c18ae6) Signed-off-by:
Joseph Salisbury <joseph.salisbury@canonical.com> Acked-by:
Brad Figg <brad.figg@canonical.com> Acked-by:
Colin King <colin.king@canonical.com> Signed-off-by:
-
- 19 Apr, 2017 1 commit
-
-
Stefan Bader authored
Ignore: yes Signed-off-by:
-
- 12 Apr, 2017 3 commits
-
-
Stefan Bader authored
-
Vitaly Kuznetsov authored
BugLink: http://bugs.launchpad.net/bugs/1681893 DoS protection conditions were altered in WS2016 and now it's easy to get -EAGAIN returned from vmbus_post_msg() (e.g. when we try changing MTU on a netvsc device in a loop). All vmbus_post_msg() callers don't retry the operation and we usually end up with a non-functional device or crash. While host's DoS protection conditions are unknown to me my tests show that it can take up to 10 seconds before the message is sent so doing udelay() is not an option, we really need to sleep. Almost all vmbus_post_msg() callers are ready to sleep but there is one special case: vmbus_initiate_unload() which can be called from interrupt/NMI context and we can't sleep there. I'm also not sure about the lonely vmbus_send_tl_connect_request() which has no in-tree users but its external users are most likely waiting for the host to reply so sleeping there is also appropriate. Signed-off-by:
Marcelo Cerri <marcelo.cerri@canonical.com> Signed-off-by:
-
Stefan Bader authored
Ignore: yes Signed-off-by:
-
- 06 Apr, 2017 34 commits
-
-
Thadeu Lima de Souza Cascardo authored
Signed-off-by:Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-
Marcelo Ricardo Leitner authored
commit 2dcab598 ("sctp: avoid BUG_ON on sctp_wait_for_sndbuf") attempted to avoid a BUG_ON call when the association being used for a sendmsg() is blocked waiting for more sndbuf and another thread did a peeloff operation on such asoc, moving it to another socket. As Ben Hutchings noticed, then in such case it would return without locking back the socket and would cause two unlocks in a row. Further analysis also revealed that it could allow a double free if the application managed to peeloff the asoc that is created during the sendmsg call, because then sctp_sendmsg() would try to free the asoc that was created only for that call. This patch takes another approach. It will deny the peeloff operation if there is a thread sleeping on the asoc, so this situation doesn't exist anymore. This avoids the issues described above and also honors the syscalls that are already being handled (it can be multiple sendmsg calls). Joint work with Xin Long. Fixes: 2dcab598 ("sctp: avoid BUG_ON on sctp_wait_for_sndbuf") Cc: Alexander Popov <alex.popov@linux.com> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by:
Xin Long <lucien.xin@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry picked from commit dfcb9f4f) CVE-2017-6353 Signed-off-by:
Tim Gardner <tim.gardner@canonical.com>
-
Paolo Pisati authored
BugLink: http://bugs.launchpad.net/bugs/1677230Signed-off-by:
Paolo Pisati <paolo.pisati@canonical.com> Acked-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1678099Signed-off-by:
-
John Johansen authored
The lperms struct is uninitialized for use with auditing if there is an early failure due to a path name error. This can result in incorrect logging or in the extreme case apparmor killing the task with a signal which results in the failure in the referenced bug. BugLink: http://bugs.launchpad.net/bugs/1664912Signed-off-by:
John Johansen <john.johansen@canonical.com> Acked-by:
-
John Johansen authored
The patch Fix no_new_privs blocking change_onexec when using stacked namespaces changed when the no_new_privs checks is processed so the test could be correctly applied in a stacked profile situation. However it changed the behavior of the error returned in complain mode, which will have both @error and @new set. Fix this by introducing a new var to indicate the no_new_privs condition instead of relying on error. While doing this allow the new label under no new privs to be audited, by having its reference put in the error path, instead of in the no_new_privs condition check. BugLink: http://bugs.launchpad.net/bugs/1661030 BugLink: http://bugs.launchpad.net/bugs/1648903Signed-off-by:
-
John Johansen authored
null profiles that don't have the same control flags as the parent behave in unexpected ways and can cause failures. BugLink: http://bugs.launchpad.net/bugs/1656121Signed-off-by:
-
John Johansen authored
BugLink: http://bugs.launchpad.net/bugs/1660849Signed-off-by:
-
John Johansen authored
Push the no_new_privs logic into the per profile transition fns, so that the no_new_privs check can be done at the ns level instead of the aggregate stack level. BugLink: http://bugs.launchpad.net/bugs/1648143Signed-off-by:
-
John Johansen authored
Bind mounts can oops when devname lookup fails because the devname is uninitialized and used in auditing the denial. BugLink: http://bugs.launchpad.net/bugs/1660840Signed-off-by:
-
John Johansen authored
When an fd is disallowed from being inherited during exec, instead of closed it is duped to a special apparmor/.null file. This prevents the fd from being reused by another file in case the application expects the original file on a give fd (eg stdin/stdout etc). This results in a denial message like [32375.561535] audit: type=1400 audit(1478825963.441:358): apparmor="DENIED" operation="file_inherit" namespace="root//lxd-t_<var-lib-lxd>" profile="/sbin/dhclient" name="/dev/pts/1" pid=16795 comm="dhclient" requested_mask="wr" denied_mask="wr" fsuid=165536 ouid=165536 Further access to the fd is resultin in the rather useless denial message of [32375.566820] audit: type=1400 audit(1478825963.445:359): apparmor="DENIED" operation="file_perm" namespace="root//lxd-t_<var-lib-lxd>" profile="/sbin/dhclient" name="/apparmor/.null" pid=16795 comm="dhclient" requested_mask="w" denied_mask="w" fsuid=165536 ouid=0 since we have the original denial, the noisy and useless .null based denials can be skipped. BugLink: http://bugs.launchpad.net/bugs/1660836Signed-off-by:
-
John Johansen authored
When a new label is created, it is created with a proxy in a circular ref count that is broken by replacement. However if the label is not used it will never be replaced and the circular ref count will never be broken resulting in a leak. BugLink: http://bugs.launchpad.net/bugs/1660834Signed-off-by:
-
John Johansen authored
@new does not have a reference taken locally and should not have its reference put locally either. BugLink: http://bugs.launchpad.net/bugs/1660833Signed-off-by:
-
John Johansen authored
The reading of rawdata is subject to a replacement race when the rawdata is read in chunks smaller than the data size. For each read the profile proxy is rechecked for the newest profile; Which means if a profile is replaced between reads later chunks will contain data from the new version of the profile while the earlier reads will contain data from the previous version. This can result in data that is inconsistent and corrupt. Instead of rechecking for the current profile at each read. Get the current profile at the time of the open and use the rawdata of the profile for the lifetime that the file handle is open. BugLink: http://bugs.launchpad.net/bugs/1638996Signed-off-by:
-
John Johansen authored
When using nested namespaces policy within the nested namespace is trying to cross validate with policy outside of the namespace that is not visible to it. This results the access being denied and with no way to add a rule to policy that would allow it. The check should only be done again policy that is visible. BugLink: http://bugs.launchpad.net/bugs/1660832Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: http://bugs.launchpad.net/bugs/1678960Signed-off-by:
-
Sebastian Andrzej Siewior authored
BugLink: http://bugs.launchpad.net/bugs/1678960 commit 619bd4a7 upstream. Since the change in commit: fd7a4bed ("sched, rt: Convert switched_{from, to}_rt() / prio_changed_rt() to balance callbacks") ... we don't reschedule a task under certain circumstances: Lets say task-A, SCHED_OTHER, is running on CPU0 (and it may run only on CPU0) and holds a PI lock. This task is removed from the CPU because it used up its time slice and another SCHED_OTHER task is running. Task-B on CPU1 runs at RT priority and asks for the lock owned by task-A. This results in a priority boost for task-A. Task-B goes to sleep until the lock has been made available. Task-A is already runnable (but not active), so it receives no wake up. The reality now is that task-A gets on the CPU once the scheduler decides to remove the current task despite the fact that a high priority task is enqueued and waiting. This may take a long time. The desired behaviour is that CPU0 immediately reschedules after the priority boost which made task-A the task with the lowest priority. Suggested-by:
Peter Zijlstra <peterz@infradead.org> Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Eric Biggers authored
BugLink: http://bugs.launchpad.net/bugs/1678960 commit 1b53cf98 upstream. Filesystem encryption ostensibly supported revoking a keyring key that had been used to "unlock" encrypted files, causing those files to become "locked" again. This was, however, buggy for several reasons, the most severe of which was that when key revocation happened to be detected for an inode, its fscrypt_info was immediately freed, even while other threads could be using it for encryption or decryption concurrently. This could be exploited to crash the kernel or worse. This patch fixes the use-after-free by removing the code which detects the keyring key having been revoked, invalidated, or expired. Instead, an encrypted inode that is "unlocked" now simply remains unlocked until it is evicted from memory. Note that this is no worse than the case for block device-level encryption, e.g. dm-crypt, and it still remains possible for a privileged user to evict unused pages, inodes, and dentries by running 'sync; echo 3 > /proc/sys/vm/drop_caches', or by simply unmounting the filesystem. In fact, one of those actions was already needed anyway for key revocation to work even somewhat sanely. This change is not expected to break any applications. In the future I'd like to implement a real API for fscrypt key revocation that interacts sanely with ongoing filesystem operations --- waiting for existing operations to complete and blocking new operations, and invalidating and sanitizing key material and plaintext from the VFS caches. But this is a hard problem, and for now this bug must be fixed. This bug affected almost all versions of ext4, f2fs, and ubifs encryption, and it was potentially reachable in any kernel configured with encryption support (CONFIG_EXT4_ENCRYPTION=y, CONFIG_EXT4_FS_ENCRYPTION=y, CONFIG_F2FS_FS_ENCRYPTION=y, or CONFIG_UBIFS_FS_ENCRYPTION=y). Note that older kernels did not use the shared fs/crypto/ code, but due to the potential security implications of this bug, it may still be worthwhile to backport this fix to them. Fixes: b7236e21 ("ext4 crypto: reorganize how we store keys in the inode") Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Acked-by:
Michael Halcrow <mhalcrow@google.com> Signed-off-by:
-
Dave Martin authored
BugLink: http://bugs.launchpad.net/bugs/1678960 commit 7195ee31 upstream. It's not clear what behaviour is sensible when doing partial write of NT_METAG_RPIPE, so just don't bother. This patch assumes that userspace will never rely on a partial SETREGSET in this case, since it's not clear what should happen anyway. Signed-off-by:
Dave Martin <Dave.Martin@arm.com> Acked-by:
James Hogan <james.hogan@imgtec.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Dave Martin authored
BugLink: http://bugs.launchpad.net/bugs/1678960 commit 5fe81fe9 upstream. Ensure that if userspace supplies insufficient data to PTRACE_SETREGSET to fill TXSTATUS, a well-defined default value is used, based on the task's current value. Suggested-by:
-
Dave Martin authored
BugLink: http://bugs.launchpad.net/bugs/1678960 commit a78ce80d upstream. Ensure that if userspace supplies insufficient data to PTRACE_SETREGSET to fill all the registers, the thread's old registers are preserved. Signed-off-by:
-
Dave Martin authored
BugLink: http://bugs.launchpad.net/bugs/1678960 commit d3805c54 upstream. Ensure that if userspace supplies insufficient data to PTRACE_SETREGSET to fill all the registers, the thread's old registers are preserved. Signed-off-by:
-
Dave Martin authored
BugLink: http://bugs.launchpad.net/bugs/1678960 commit d614fd58 upstream. Ensure that if userspace supplies insufficient data to PTRACE_SETREGSET to fill all the registers, the thread's old registers are preserved. Signed-off-by:
-
Dave Martin authored
BugLink: http://bugs.launchpad.net/bugs/1678960 commit 502585c7 upstream. regs_set() and regs_get() are vulnerable to an off-by-1 buffer overrun if CONFIG_CPU_H8S is set, since this adds an extra entry to register_offset[] but not to user_regs_struct. So, iterate over user_regs_struct based on its actual size, not based on the length of register_offset[]. Signed-off-by:
-
Dave Martin authored
BugLink: http://bugs.launchpad.net/bugs/1678960 commit fb411b83 upstream. gpr_set won't work correctly and can never have been tested, and the correct behaviour is not clear due to the endianness-dependent task layout. So, just remove it. The core code will now return -EOPNOTSUPPORT when trying to set NT_PRSTATUS on this architecture until/unless a correct implementation is supplied. Signed-off-by:
-
Bjorn Andersson authored
BugLink: http://bugs.launchpad.net/bugs/1678960 commit a6566710 upstream. Clearing the status bit on irq_unmask will discard any pending interrupt that did arrive after the irq_ack, i.e. while the IRQ handler function was executing. Fixes: f365be09 ("pinctrl: Add Qualcomm TLMM driver") Cc: Stephen Boyd <sboyd@codeaurora.org> Reported-by:
Timur Tabi <timur@codeaurora.org> Signed-off-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Ladi Prosek authored
BugLink: http://bugs.launchpad.net/bugs/1678960 commit fc865322 upstream. When init_vqs runs, virtio_balloon.stats is either uninitialized or contains stale values. The host updates its state with garbage data because it has no way of knowing that this is just a marker buffer used for signaling. This patch updates the stats before pushing the initial buffer. Alternative fixes: * Push an empty buffer in init_vqs. Not easily done with the current virtio implementation and violates the spec "Driver MUST supply the same subset of statistics in all buffers submitted to the statsq". * Push a buffer with invalid tags in init_vqs. Violates the same spec clause, plus "invalid tag" is not really defined. Note: the spec says: When using the legacy interface, the device SHOULD ignore all values in the first buffer in the statsq supplied by the driver after device initialization. Note: Historically, drivers supplied an uninitialized buffer in the first buffer. Unfortunately QEMU does not seem to implement the recommendation even for the legacy interface. Signed-off-by:
Ladi Prosek <lprosek@redhat.com> Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
-
Florian Westphal authored
BugLink: http://bugs.launchpad.net/bugs/1678960 commit c282222a upstream. Dmitry reports following splat: INFO: trying to register non-static key. the code is fine but needs lockdep annotation. turning off the locking correctness validator. CPU: 0 PID: 13059 Comm: syz-executor1 Not tainted 4.10.0-rc7-next-20170207 #1 [..] spin_lock_bh include/linux/spinlock.h:304 [inline] xfrm_policy_flush+0x32/0x470 net/xfrm/xfrm_policy.c:963 xfrm_policy_fini+0xbf/0x560 net/xfrm/xfrm_policy.c:3041 xfrm_net_init+0x79f/0x9e0 net/xfrm/xfrm_policy.c:3091 ops_init+0x10a/0x530 net/core/net_namespace.c:115 setup_net+0x2ed/0x690 net/core/net_namespace.c:291 copy_net_ns+0x26c/0x530 net/core/net_namespace.c:396 create_new_namespaces+0x409/0x860 kernel/nsproxy.c:106 unshare_nsproxy_namespaces+0xae/0x1e0 kernel/nsproxy.c:205 SYSC_unshare kernel/fork.c:2281 [inline] Problem is that when we get error during xfrm_net_init we will call xfrm_policy_fini which will acquire xfrm_policy_lock before it was initialized. Just move it around so locks get set up first. Reported-by:
Dmitry Vyukov <dvyukov@google.com> Fixes: 283bc9f3 ("xfrm: Namespacify xfrm state/policy locks") Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by:
-
Netanel Belgazal authored
BugLink: http://bugs.launchpad.net/bugs/1664312Signed-off-by:
Netanel Belgazal <netanel@annapurnalabs.com> Signed-off-by:
Kamal Mostafa <kamal@canonical.com> Acked-by:
-
Netanel Belgazal authored
BugLink: http://bugs.launchpad.net/bugs/1664312 Move the host info config to be the first admin command that is executed. This change require the driver to remove the 'feature check' from host info configuration flow. The check is removed since the supported features bitmask field is retrieved only after calling ENA_ADMIN_DEVICE_ATTRIBUTES admin command. If set host info is not supported an error will be returned by the device. Signed-off-by:
-
Netanel Belgazal authored
BugLink: http://bugs.launchpad.net/bugs/1664312 The timeouts were too agressive and sometimes cause false alarms. Signed-off-by:
-
Netanel Belgazal authored
BugLink: http://bugs.launchpad.net/bugs/1664312Signed-off-by:
-
Netanel Belgazal authored
BugLink: http://bugs.launchpad.net/bugs/1664312 Completion descriptors are accessed from the driver and from the device. To avoid reading the old value, use READ_ONCE macro. Signed-off-by:
-
Netanel Belgazal authored
BugLink: http://bugs.launchpad.net/bugs/1664312 If the ena driver detects that the device is not behave as expected, it tries to reset the device. The reset flow calls ena_down, which will frees all the resources the driver allocates and then it will reset the device. This flow can cause memory corruption if the device is still writes to the driver's memory space. To overcome this potential race, move the reset before the device resources are freed. Signed-off-by:
-
