- 09 Nov, 2016 2 commits
-
-
Seth Forshee authored
BugLink: https://bugs.launchpad.net/bugs/1639345 This reverts commit a76b8ce7 to apply a more complete fix from linux-next. CVE-2015-8709 Signed-off-by:
Seth Forshee <seth.forshee@canonical.com> Acked-by:
Brad Figg <brad.figg@canonical.com> Acked-by:
Tim Gardner <tim.gardner@canonical.com> Signed-off-by:
Luis Henriques <luis.henriques@canonical.com>
-
Douglas Miller authored
BugLink: http://bugs.launchpad.net/bugs/1637978 Add 'P' command with optional task_struct address to dump all/one task's information: task pointer, kernel stack pointer, PID, PPID, state (interpreted), CPU where (last) running, and command. Signed-off-by:
Douglas Miller <dougmill@linux.vnet.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> (cherry picked from commit 6dfb5404) Signed-off-by:
-
- 08 Nov, 2016 38 commits
-
-
Colin Ian King authored
BugLink: http://bugs.launchpad.net/bugs/1636517 Xenial kernel commit 193fb6a2c94fab8eb8ce70a5da4d21c7d4023bee ("block_dev: Support checking inode permissions in lookup_bdev()") added a flags argument to block_dev which caused this breakage. Add detection of 1 or 2 arg block_dev and add a zfs_block_dev shim to abstract these differences away. Kudos to Fabian Grünbichler for the original fix that this fix is based on. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
-
Agrawal, Nitesh-kumar authored
The earlier patch can be simplified by using a bool to indicate level trigger. BugLink: http://bugs.launchpad.net/bugs/1612006Reviewed-by:
Pankaj Sen <Pankaj.Sen@amd.com> Signed-off-by:
Nitesh Kumar Agrawal <Nitesh-kumar.Agrawal@amd.com> [Fixup to earlier manually applied patch] Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> (cherry picked from commit e084448b) Signed-off-by:
Alex Hung <alex.hung@canonical.com> Acked-by:
Robert Hooker <robert.hooker@canonical.com> Acked-by:
-
Agrawal, Nitesh-kumar authored
In the function amd_gpio_irq_set_type, use the settings provided by the BIOS,when the LevelTrig is Edge and activeLevel is HIGH, to configure the GPIO registers. Ignore the settings from client. BugLink: http://bugs.launchpad.net/bugs/1612006Reviewed-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1636733Signed-off-by:
-
Paul Mackerras authored
BugLink: http://bugs.launchpad.net/bugs/1630554 As discussed recently on the kvm mailing list, David Gibson's intention in commit 178a7875 ("vfio: Enable VFIO device for powerpc", 2016-02-01) was to have the KVM VFIO device built in on all powerpc platforms. This patch adds the "select KVM_VFIO" statement that makes this happen. Currently, arch/powerpc/kvm/Makefile doesn't include vfio.o for the 64-bit kvm module, because the list of objects doesn't use the $(common-objs-y) list. The reason it doesn't is because we don't necessarily want coalesced_mmio.o or emulate.o (for example if HV KVM is the only target), and common-objs-y includes both. Since this is confusing, this patch adjusts the definitions so that we now use $(common-objs-y) in the list for the 64-bit kvm.ko module, emulate.o is removed from common-objs-y and added in the places that need it, and the inclusion of coalesced_mmio.o now depends on CONFIG_KVM_MMIO. Reviewed-by:
Paolo Bonzini <pbonzini@redhat.com> Reviewed-by:
David Gibson <david@gibson.dropbear.id.au> Signed-off-by:
Paul Mackerras <paulus@ozlabs.org> (back ported from commit 4b3d173d) Signed-off-by:
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1634964 Supporting snaps in lxd containers requires mounting filesystems in user namespaces using fuse. Enable this by default, but keep the module parameter to allow users to disable it if desired. Signed-off-by:
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1634964 Expand the check in should_remove_suid() to keep privileges for CAP_FSETID in s_user_ns rather than init_user_ns. --EWB Changed from ns_capable(sb->s_user_ns, ) to capable_wrt_inode_uidgid Signed-off-by:
Serge Hallyn <serge.hallyn@canonical.com> Signed-off-by:
Eric W. Biederman <ebiederm@xmission.com> Acked-by:
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1634964 This reverts commit b50099a2 in order to apply the version in yakkety. Signed-off-by:
-
Eric W. Biederman authored
BugLink: http://bugs.launchpad.net/bugs/1634964 Allow users with CAP_SYS_CHOWN over the superblock of a filesystem to chown files. Ordinarily the capable_wrt_inode_uidgid check is sufficient to allow access to files but when the underlying filesystem has uids or gids that don't map to the current user namespace it is not enough, so the chown permission checks need to be extended to allow this case. Calling chown on filesystem nodes whose uid or gid don't map is necessary if those nodes are going to be modified as writing back inodes which contain uids or gids that don't map is likely to cause filesystem corruption of the uid or gid fields. Once chown has been called the existing capable_wrt_inode_uidgid checks are sufficient, to allow the owner of a superblock to do anything the global root user can do with an appropriate set of capabilities. For the proc filesystem this relaxation of permissions is not safe, as some files are owned by users (particularly GLOBAL_ROOT_UID) outside of the control of the mounter of the proc and that would be unsafe to grant chown access to. So update setattr on proc to disallow changing files whose uids or gids are outside of proc's s_user_ns. The original version of this patch was written by: Seth Forshee. I have rewritten and rethought this patch enough so it's really not the same thing (certainly it needs a different description), but he deserves credit for getting out there and getting the conversation started, and finding the potential gotcha's and putting up with my semi-paranoid feedback. Inspired-by:
-
Seth Forshee authored
(namespace) Revert "UBUNTU: SAUCE: fs: Allow superblock owner to change ownership of inodes with unmappable ids" This reverts commit 6e42b32e in order to apply the version in yakkety. Signed-off-by:
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1634964 In general the handling of IMA/EVM xattrs is good, but I found a few locations where either the xattr size or the value of the type field in the xattr are not checked. Add a few simple checks to these locations to prevent malformed or malicious xattrs from causing problems. Signed-off-by:
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1634964 This reverts commit 5d96fa44, as it adds attack surface without any clear use case at this point. Signed-off-by:
-
Eric W. Biederman authored
BugLink: http://bugs.launchpad.net/bugs/1634964 Mostly supporting filesystems outside of init_user_ns is s/&init_usre_ns/dquot->dq_sb->s_user_ns/. An actual need for supporting quotas on filesystems outside of s_user_ns is quite a ways away and to be done responsibily needs an audit on what can happen with hostile quota files. Until that audit is complete don't attempt to support quota files on filesystems outside of s_user_ns. Cc: Jan Kara <jack@suse.cz> Acked-by:
-
Eric W. Biederman authored
BugLink: http://bugs.launchpad.net/bugs/1634964 In Q_XSETQLIMIT use sb->s_user_ns to detect when we are dealing with the filesystems notion of id 0. Cc: Jan Kara <jack@suse.cz> Acked-by:
-
Eric W. Biederman authored
BugLink: http://bugs.launchpad.net/bugs/1634964 Introduce the helper qid_has_mapping and use it to ensure that the quota system only considers qids that map to the filesystems s_user_ns. In practice for quota supporting filesystems today this is the exact same check as qid_valid. As only 0xffffffff aka (qid_t)-1 does not map into init_user_ns. Replace the qid_valid calls with qid_has_mapping as values come in from userspace. This is harmless today and it prepares the quota system to work on filesystems with quotas but mounted by unprivileged users. Call qid_has_mapping from dqget. This ensures the passed in qid has a prepresentation on the underlying filesystem. Previously this was unnecessary as filesystesm never had qids that could not map. With the introduction of filesystems outside of s_user_ns this will not remain true. All of this ensures the quota code never has to deal with qids that don't map to the underlying filesystem. Cc: Jan Kara <jack@suse.cz> Acked-by:
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1634964 This reverts commit 95317559 in order to apply the corresponding upstream patches. Signed-off-by:
-
Seth Forshee authored
(namespace) Revert "UBUNTU: SAUCE: quota: Require that qids passed to dqget() be valid and map into s_user_ns" BugLink: http://bugs.launchpad.net/bugs/1634964 This reverts commit 2c79b9bf in order to apply the corresponding upstream patches. Signed-off-by:
-
Eric W. Biederman authored
BugLink: http://bugs.launchpad.net/bugs/1634964 It is expected that filesystems can not represent uids and gids from outside of their user namespace. Keep things simple by not even trying to create filesystem nodes with non-sense uids and gids. Acked-by:
-
Eric W. Biederman authored
BugLink: http://bugs.launchpad.net/bugs/1634964 When a filesystem outside of init_user_ns is mounted it could have uids and gids stored in it that do not map to init_user_ns. The plan is to allow those filesystems to set i_uid to INVALID_UID and i_gid to INVALID_GID for unmapped uids and gids and then to handle that strange case in the vfs to ensure there is consistent robust handling of the weirdness. Upon a careful review of the vfs and filesystems about the only case where there is any possibility of confusion or trouble is when the inode is written back to disk. In that case filesystems typically read the inode->i_uid and inode->i_gid and write them to disk even when just an inode timestamp is being updated. Which leads to a rule that is very simple to implement and understand inodes whose i_uid or i_gid is not valid may not be written. In dealing with access times this means treat those inodes as if the inode flag S_NOATIME was set. Reads of the inodes appear safe and useful, but any write or modification is disallowed. The only inode write that is allowed is a chown that sets the uid and gid on the inode to valid values. After such a chown the inode is normal and may be treated as such. Denying all writes to inodes with uids or gids unknown to the vfs also prevents several oddball cases where corruption would have occurred because the vfs does not have complete information. One problem case that is prevented is attempting to use the gid of a directory for new inodes where the directories sgid bit is set but the directories gid is not mapped. Another problem case avoided is attempting to update the evm hash after setxattr, removexattr, and setattr. As the evm hash includeds the inode->i_uid or inode->i_gid not knowning the uid or gid prevents a correct evm hash from being computed. evm hash verification also fails when i_uid or i_gid is unknown but that is essentially harmless as it does not cause filesystem corruption. Acked-by:
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1634964 Fuse currently lacks comprehensive support for posix ACLs, but some fuse filesystems process the acl xattrs internally. For this to continue to work the ids within the xattrs need to be mapped into s_user_ns when written to the filesystem and mapped from s_user_ns when read. Signed-off-by:
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1634964 Fuse will make use of this function to provide backwards- compatible acl support when proper posix acl support is added. Add a check to return immediately if the to and from namespaces are the same, and remove equivalent checks from its callers. Also return an error code to indicate to callers whether or not the conversion of the id between the user namespaces was successful. For a valid xattr the id will continue to be changed regardless to maintain the current behaviour for existing callers, so they do not require updates to handle failed conversions. Signed-off-by:
-
Eric W. Biederman authored
BugLink: http://bugs.launchpad.net/bugs/1634964 Update posix_acl_valid to verify that an acl is within a user namespace. Update the callers of posix_acl_valid to pass in an appropriate user namespace. For posix_acl_xattr_set and v9fs_xattr_set_acl pass in inode->i_sb->s_user_ns to posix_acl_valid. For md_unpack_acl pass in &init_user_ns as no inode or superblock is in sight. Acked-by:
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1634964 This reverts commit 7efdc167 in order to apply the corresponding upstream patch. Signed-off-by:
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1634964 Add checks to notify_change to verify that uid and gid changes will map into the superblock's user namespace. If they do not fail with -EOVERFLOW. This is mandatory so that fileystems don't have to even think of dealing with ia_uid and ia_gid that --EWB Moved the test from inode_change_ok to notify_change Signed-off-by:
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1634964 This reverts commit fe50b8ac in order to apply the upstream version of the same patch. Signed-off-by:
-
Eric W. Biederman authored
BugLink: http://bugs.launchpad.net/bugs/1634964 Allowing a filesystem to be mounted by other than root in the initial user namespace is a filesystem property not a mount namespace property and as such should be checked in filesystem specific code. Move the FS_USERNS_MOUNT test into super.c:sget_userns(). Acked-by:
-
Jarkko Nikula authored
BugLink: http://bugs.launchpad.net/bugs/1591618 https://lkml.org/lkml/2016/9/29/123 There are a few issues on Intel Kaby Lake PCH-H properties added by commit a6a576b78e09 ("mfd: lpss: Add Intel Kaby Lake PCH-H PCI IDs"): - Input clock of I2C controller on Intel Kaby Lake PCH-H is 120 MHz not 133 MHz. This was probably copy-paste error from Intel Broxton I2C properties. - There is no default I2C SDA hold time specified which is used when ACPI doesn't provide it. I got information from Windows driver team that Kaby Lake PCH-H can use the same configuration than Intel Sunrisepoint PCH. - Common HS-UART properties are not used. Fix these by reusing the Sunrisepoint properties on Kaby Lake PCH-H. Fixes: a6a576b78e09 ("mfd: lpss: Add Intel Kaby Lake PCH-H PCI IDs") Reported-by:
Xiang A Wang <xiang.a.wang@intel.com> Signed-off-by:
Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by:
-
Ming Lei authored
BugLink: http://bugs.launchpad.net/bugs/1638700 From v4.3, the incoming bio can be very big[1], and it is required to split it first in .make_request_fn(), so we need to do that for hio.c too. [1] c66a14d0(block: simplify bio_add_page()) Signed-off-by:
Ming Lei <ming.lei@canonical.com> Signed-off-by:
Kamal Mostafa <kamal@canonical.com> Acked-by:
-
Kamal Mostafa authored
BugLink: http://bugs.launchpad.net/bugs/1638700 The hio driver needs to accommodate handling the following which was introduced in 4.3-rc1: commit 4246a0b6 Author: Christoph Hellwig <hch@lst.de> Date: Mon Jul 20 15:29:37 2015 +0200 block: add a bi_error field to struct bio Signed-off-by:
Leann Ogasawara <leann.ogasawara@canonical.com> Acked-by:
-
Wang, Rui Y authored
BugLink: https://bugs.launchpad.net/bugs/1637165 mcryptd_create_hash() fails by returning -EINVAL, causing any driver using mcryptd to fail to load. It is because it needs to set its statesize properly. Signed-off-by:
Rui Wang <rui.y.wang@intel.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> (cherry picked from commit ddef4824) Signed-off-by:
Marcelo Cerri <marcelo.cerri@canonical.com> Acked-by:
-
Wang, Rui Y authored
BugLink: https://bugs.launchpad.net/bugs/1637165 On Monday, February 1, 2016 4:18 PM, Herbert Xu wrote: > > On Wed, Jan 27, 2016 at 05:08:35PM +0800, Rui Wang wrote: >> >> +static int sha1_mb_async_import(struct ahash_request *req, const void >> +*in) { >> + struct ahash_request *mcryptd_req = ahash_request_ctx(req); >> + struct crypto_ahash *tfm = crypto_ahash_reqtfm(req); >> + struct sha1_mb_ctx *ctx = crypto_ahash_ctx(tfm); >> + struct mcryptd_ahash *mcryptd_tfm = ctx->mcryptd_tfm; >> + struct crypto_shash *child = mcryptd_ahash_child(mcryptd_tfm); >> + struct mcryptd_hash_request_ctx *rctx; >> + struct shash_desc *desc; >> + int err; >> + >> + memcpy(mcryptd_req, req, sizeof(*req)); >> + ahash_request_set_tfm(mcryptd_req, &mcryptd_tfm->base); >> + rctx = ahash_request_ctx(mcryptd_req); >> + desc = &rctx->desc; >> + desc->tfm = child; >> + desc->flags = CRYPTO_TFM_REQ_MAY_SLEEP; >> + >> + err = crypto_shash_init(desc); >> + if (err) >> + return err; > > What is this desc for? Hi Herbert, Yeah I just realized that the call to crypto_shash_init() isn't necessary here. What it does is overwritten by crypto_ahash_import(). But this desc still needs to be initialized here because it's newly allocated by ahash_request_alloc(). We eventually calls the shash version of import() which needs desc as an argument. The real context to be imported is then derived from shash_desc_ctx(desc). desc is a sub-field of struct mcryptd_hash_request_ctx, which is again a sub-field of the bigger blob allocated by ahash_request_alloc(). The entire blob's size is set in sha1_mb_async_init_tfm(). So a better version is as follows: (just removed the call to crypto_shash_init()) >From 4bcb73adbef99aada94c49f352063619aa24d43d Mon Sep 17 00:00:00 2001 From: Rui Wang <rui.y.wang@intel.com> Date: Mon, 14 Dec 2015 17:22:13 +0800 Subject: [PATCH v2 1/4] crypto x86/sha1_mb: Fix load failure modprobe sha1_mb fails with the following message: modprobe: ERROR: could not insert 'sha1_mb': No such device It is because it needs to set its statesize and implement its import() and export() interface. v2: remove redundant call to crypto_shash_init() Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1635223Signed-off-by:
Joseph Salisbury <joseph.salisbury@canonical.com> Acked-by:
-
Axel Lin authored
BugLink: https://launchpad.net/bugs/1625232 devm_kzalloc() returns NULL on failure. Signed-off-by:
Axel Lin <axel.lin@ingics.com> Signed-off-by:
Jassi Brar <jaswinder.singh@linaro.org> (cherry picked from commit a61b37ea) Signed-off-by:
Craig Magina <craig.magina@canonical.com> Acked-by:
-
Dan Carpenter authored
BugLink: https://launchpad.net/bugs/1625232 devm_ioremap() returns NULL, it never returns an ERR_PTR. Fixes: f700e84f ('mailbox: Add support for APM X-Gene platform mailbox driver') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Duc Dang authored
BugLink: https://launchpad.net/bugs/1625232 X-Gene mailbox controller provides 8 mailbox channels, with each channel has a dedicated interrupt line. Signed-off-by:
Feng Kan <fkan@apm.com> Signed-off-by:
Duc Dang <dhdang@apm.com> Signed-off-by:
-
Craig Magina authored
Signed-off-by:
-
Mika Westerberg authored
BugLink: http://bugs.launchpad.net/bugs/1632527 Dell XPS 13 (and maybe some others) uses a GPIO (CPU_GP_1) during suspend to explicitly disable USB touchscreen interrupt. This is done to prevent situation where the lid is closed the touchscreen is left functional. The pinctrl driver (wrongly) assumes it owns all pins which are owned by host and not locked down. It is perfectly fine for BIOS to use those pins as it is also considered as host in this context. What happens is that when the lid of Dell XPS 13 is closed, the BIOS configures CPU_GP_1 low disabling the touchscreen interrupt. During resume we restore all host owned pins to the known state which includes CPU_GP_1 and this overwrites what the BIOS has programmed there causing the touchscreen to fail as no interrupts are reaching the CPU anymore. Fix this by restoring only those pins we know are explicitly requested by the kernel one way or other. Cc: stable@vger.kernel.org Link: https://bugzilla.kernel.org/show_bug.cgi?id=176361Reported-by:
AceLan Kao <acelan.kao@canonical.com> Tested-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
-
Linus Walleij authored
BugLink: http://bugs.launchpad.net/bugs/1632527 This kind of hacks disturbs the refactoring of the gpiolib. The descriptor table belongs to the gpiolib, if we want to know something about something in it, use or define the proper accessor functions. Let's add this gpiochip_lins_is_irq() to do what the sunxi driver is trying at so we can privatize the descriptors properly. Cc: Maxime Ripard <maxime.ripard@free-electrons.com> Cc: Chen-Yu Tsai <wens@csie.org> Signed-off-by:
-
