- 08 Nov, 2016 40 commits
-
-
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:
Seth Forshee <seth.forshee@canonical.com> Acked-by:
Serge Hallyn <serge.hallyn@canonical.com> Signed-off-by:
Eric W. Biederman <ebiederm@xmission.com> Acked-by:
Tim Gardner <tim.gardner@canonical.com> Signed-off-by:
Luis Henriques <luis.henriques@canonical.com>
-
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:
Robert Hooker <robert.hooker@canonical.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 <linus.walleij@linaro.org> (cherry picked from commit c538b943) 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:
-
Greg Kroah-Hartman authored
BugLink: http://bugs.launchpad.net/bugs/1638272Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: http://bugs.launchpad.net/bugs/1638272 This reverts commit 9d25c78e which is 1c109fab upstream Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: http://bugs.launchpad.net/bugs/1638272 This reverts commit fcf5e519 which is 548acf19 upstream. Cc: Tony Luck <tony.luck@intel.com> Cc: Borislav Petkov <bp@suse.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: http://bugs.launchpad.net/bugs/1638267Signed-off-by:
-
Robert Jarzmik authored
BugLink: http://bugs.launchpad.net/bugs/1638267 commit 9ba63e3c upstream. Since its initial commit, the driver is buggy for multiple interrupts handling. The translation from the former lubbock.c file was not complete, and might stall all interrupt handling when multiple interrupts occur. This is especially true when inside the interrupt handler and if a new interrupt comes and is not handled, leaving the output line still held, and not creating a transition as the GPIO block behind would expect to trigger another cplds_irq_handler() call. For the record, the hardware is working as follows. The interrupt mechanism relies on : - one status register - one mask register Let's suppose the input irq lines are called : - i_sa1111 - i_lan91x - i_mmc_cd Let's suppose the status register for each irq line is called : - status_sa1111 - status_lan91x - status_mmc_cd Let's suppose the interrupt mask for each irq line is called : - irqen_sa1111 - irqen_lan91x - irqen_mmc_cd Let's suppose the output irq line, connected to GPIO0 is called : - o_gpio0 The behavior is as follows : - o_gpio0 = not((status_sa1111 & irqen_sa1111) | (status_lan91x & irqen_lan91x) | (status_mmc_cd & irqen_mmc_cd)) => this is a N-to-1 NOR gate and multiple AND gates - irqen_* is exactly as programmed by a write to the FPGA - status_* behavior is governed by a bi-stable D flip-flop => on next FPGA clock : - if i_xxx is high, status_xxx becomes 1 - if i_xxx is low, status_xxx remains as it is - if software sets status_xxx to 0, the D flip-flop is reset => status_xxx becomes 0 => on next FPGA clock cycle, if i_xxx is high, status_xxx becomes 1 again Fixes: fc9e38c0 ("ARM: pxa: lubbock: use new pxa_cplds driver") Reported-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by:
-
Pan Xinhui authored
BugLink: http://bugs.launchpad.net/bugs/1638267 commit 11b7e154 upstream. When we merge two contiguous partitions whose signatures are marked NVRAM_SIG_FREE, We need update prev's length and checksum, then write it to nvram, not cur's. So lets fix this mistake now. Also use memset instead of strncpy to set the partition's name. It's more readable if we want to fill up with duplicate chars . Fixes: fa2b4e54 ("powerpc/nvram: Improve partition removal") Signed-off-by:
Pan Xinhui <xinhui.pan@linux.vnet.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Johannes Thumshirn authored
BugLink: http://bugs.launchpad.net/bugs/1638267 commit 0d667f72 upstream. In _scsih_io_done() we test if the ioc->logging_level does _not_ have the MPT_DEBUG_REPLY bit set and if it hasn't we print the debug messages. This unfortunately is the wrong way around. Note, the actual bug is older than af009411 but this commit removed the CONFIG_SCSI_MPT3SAS_LOGGING Kconfig option which hid the bug. Fixes: af009411 'mpt2sas, mpt3sas: Remove SCSI_MPTXSAS_LOGGING entry from Kconfig' Signed-off-by:
Johannes Thumshirn <jthumshirn@suse.de> Acked-by:
Chaitra P B <chaitra.basappa@broadcom.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Arnaldo Carvalho de Melo authored
BugLink: http://bugs.launchpad.net/bugs/1638267 commit 432746f8 upstream. When we call symbol__fixup_duplicate() we use algorithms to pick the "best" symbols for cases where there are various functions/aliases to an address, and those check zero size symbols, which, before calling symbol__fixup_end() are _all_ symbols in a just parsed kallsyms file. So first fixup the end, then fixup the duplicates. Found while trying to figure out why 'perf test vmlinux' failed, see the output of 'perf test -v vmlinux' to see cases where the symbols picked as best for vmlinux don't match the ones picked for kallsyms. Cc: Anton Blanchard <anton@samba.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Fixes: 694bf407 ("perf symbols: Add some heuristics for choosing the best duplicate symbol") Link: http://lkml.kernel.org/n/tip-rxqvdgr0mqjdxee0kf8i2ufn@git.kernel.orgSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
