They uses the codec ALC255, and have the different pin cfg definition
from the ones in the existing pin quirk table. Now adding them into
the table to fix the problem.
Signed-off-by: Hui Wang <hui.wang@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
We have a new Dell laptop model which uses ALC295, the pin definition
is different from the existing ones in the pin quirk table, to fix the
headset mic detection and mic mute led's problem, we need to add the
new pin defintion into the pin quirk table.
Signed-off-by: Hui Wang <hui.wang@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Commit 49d9e77e72cf ("ALSA: hda - Fix system panic when DMA > 40 bits
for Nvidia audio controllers") simply disabled any DMA exceeding 32
bits for NVidia devices, even though they are capable of performing
DMA up to 40 bits. On some architectures (such as arm64), system memory
is not guaranteed to be 32-bit addressable by PCI devices, and so this
change prevents NVidia devices from working on platforms such as AMD
Seattle.
Since the original commit already mentioned that up to 40 bits of DMA
is supported, and given that the code has been updated in the meantime
to support a 40 bit DMA mask on other devices, revert commit 49d9e77e72cf
and explicitly set the DMA mask to 40 bits for NVidia devices.
Fixes: 49d9e77e72cf ('ALSA: hda - Fix system panic when DMA > 40 bits...') Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
AZX_DCAPS_RIRB_DELAY is dedicated only for Nvidia and its purpose is
just to set a flag in bus. So it's better to be set in the toplevel
driver, either hda_intel.c or hda_tegra.c, instead of the common
hda_controller.c. This also allows us to strip this flag from dcaps,
so save one more bit there.
AZX_DCAPS_RIRB_PRE_DELAY is always tied with AZX_DCAPS_CTX_WORKAROUND,
which is Creative's XFi specific. So, we can replace it and reduce
one more bit free for DCAPS.
The stk1160 chip needs QUIRK_AUDIO_ALIGN_TRANSFER. This patch resolves
the issue reported on the mailing list
(http://marc.info/?l=linux-sound&m=139223599126215&w=2) and also fixes
bug 180071 (https://bugzilla.kernel.org/show_bug.cgi?id=180071).
On 4.0, we saw a stack corruption from a page fault entering direct
memory cgroup reclaim, calling into btrfs_releasepage(), which then
tried to allocate an extent and recursed back into a kmem charge ad
nauseam:
On later kernels, kmem charging is opt-in rather than opt-out, and that
particular kmem allocation in btrfs_releasepage() is no longer being
charged and won't recurse and overrun the stack anymore.
But it's not impossible for an accounted allocation to happen from the
memcg direct reclaim context, and we needed to reproduce this crash many
times before we even got a useful stack trace out of it.
Like other direct reclaimers, mark tasks in memcg reclaim PF_MEMALLOC to
avoid recursing into any other form of direct reclaim. Then let
recursive charges from PF_MEMALLOC contexts bypass the cgroup limit.
Link: http://lkml.kernel.org/r/20161025141050.GA13019@cmpxchg.org Signed-off-by: Johannes Weiner <hannes@cmpxchg.org> Acked-by: Michal Hocko <mhocko@suse.com> Cc: Vladimir Davydov <vdavydov.dev@gmail.com> Cc: Tejun Heo <tj@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
As described in https://bugzilla.kernel.org/show_bug.cgi?id=177821:
After some analysis it seems to be that the problem is in alloc_super().
In case list_lru_init_memcg() fails it goes into destroy_super(), which
calls list_lru_destroy().
And in list_lru_init() we see that in case memcg_init_list_lru() fails,
lru->node is freed, but not set NULL, which then leads list_lru_destroy()
to believe it is initialized and call memcg_destroy_list_lru().
memcg_destroy_list_lru() in turn can access lru->node[i].memcg_lrus,
which is NULL.
[akpm@linux-foundation.org: add comment] Signed-off-by: Alexander Polakov <apolyakov@beget.ru> Acked-by: Vladimir Davydov <vdavydov.dev@gmail.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
The function xfs_calc_dquots_per_chunk takes a parameter in units
of basic blocks. The kernel seems to get the units wrong, but
userspace got 'fixed' by commenting out the unnecessary conversion.
Fix both.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by: Eric Sandeen <sandeen@redhat.com> Signed-off-by: Dave Chinner <david@fromorbit.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Back in commit f56141e3e2d9 ("all arches, signal: move restart_block to
struct task_struct"), all architectures and core code were changed to
use task_struct::restart_block. However, when h8300 support was
subsequently restored in v4.2, it was not updated to account for this,
and maintains thread_info::restart_block, which is not kept in sync.
This patch drops the redundant restart_block from thread_info, and moves
h8300 to the common one in task_struct, ensuring that syscall restarting
always works as expected.
Fixes: f56141e3e2d9 ("all arches, signal: move restart_block to struct task_struct") Link: http://lkml.kernel.org/r/1476714934-11635-1-git-send-email-mark.rutland@arm.com Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Cc: uclinux-h8-devel@lists.sourceforge.jp Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
The i2c adapter is only relevant for some peer device types, so
let's clear the pdt if it's still the same as the old_pdt when we
tear down the i2c adapter.
I don't really like this design pattern of updating port->whatever
before doing the accompanying changes and passing around old_whatever
to figure stuff out. Would make much more sense to me to the pass the
new value around and only update the port->whatever when things are
consistent. But let's try to work with what we have right now.
Quoting a follow-up from Ville:
"And naturally I forgot to amend the commit message w.r.t. this guy
[the change in drm_dp_destroy_port]. We don't really need to do this
here, but I figured I'd try to be a bit more consistent by having it,
just to avoid accidental mistakes if/when someone changes this stuff
again later."
v2: Clear port->pdt in the caller, if needed (Daniel)
Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Carlos Santa <carlos.santa@intel.com> Cc: Kirill A. Shutemov <kirill@shutemov.name> Tested-by: Carlos Santa <carlos.santa@intel.com> Tested-by: Kirill A. Shutemov <kirill@shutemov.name>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97666 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1477488633-16544-1-git-send-email-ville.syrjala@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Race condition between registering an I2C device driver and
deregistering an I2C adapter device which is assumed to manage that
I2C device may lead to a NULL pointer dereference due to the
uninitialized list head of driver clients.
The root cause of the issue is that the I2C bus may know about the
registered device driver and thus it is matched by bus_for_each_drv(),
but the list of clients is not initialized and commonly it is NULL,
because I2C device drivers define struct i2c_driver as static and
clients field is expected to be initialized by I2C core:
To solve the problem it is sufficient to do clients list head
initialization before calling driver_register().
The problem was found while using an I2C device driver with a sluggish
registration routine on a bus provided by a physically detachable I2C
master controller, but practically the oops may be reproduced under
the race between arbitraty I2C device driver registration and managing
I2C bus device removal e.g. by unbinding the latter over sysfs:
% echo 21a4000.i2c > /sys/bus/platform/drivers/imx-i2c/unbind
Unable to handle kernel NULL pointer dereference at virtual address 00000000
Internal error: Oops: 17 [#1] SMP ARM
CPU: 2 PID: 533 Comm: sh Not tainted 4.9.0-rc3+ #61
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
task: e5ada400 task.stack: e4936000
PC is at i2c_do_del_adapter+0x20/0xcc
LR is at __process_removed_adapter+0x14/0x1c
Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
Control: 10c5387d Table: 35bd004a DAC: 00000051
Process sh (pid: 533, stack limit = 0xe4936210)
Stack: (0xe4937d28 to 0xe4938000)
Backtrace:
[<c0667be0>] (i2c_do_del_adapter) from [<c0667cc0>] (__process_removed_adapter+0x14/0x1c)
[<c0667cac>] (__process_removed_adapter) from [<c0516998>] (bus_for_each_drv+0x6c/0xa0)
[<c051692c>] (bus_for_each_drv) from [<c06685ec>] (i2c_del_adapter+0xbc/0x284)
[<c0668530>] (i2c_del_adapter) from [<bf0110ec>] (i2c_imx_remove+0x44/0x164 [i2c_imx])
[<bf0110a8>] (i2c_imx_remove [i2c_imx]) from [<c051a838>] (platform_drv_remove+0x2c/0x44)
[<c051a80c>] (platform_drv_remove) from [<c05183d8>] (__device_release_driver+0x90/0x12c)
[<c0518348>] (__device_release_driver) from [<c051849c>] (device_release_driver+0x28/0x34)
[<c0518474>] (device_release_driver) from [<c0517150>] (unbind_store+0x80/0x104)
[<c05170d0>] (unbind_store) from [<c0516520>] (drv_attr_store+0x28/0x34)
[<c05164f8>] (drv_attr_store) from [<c0298acc>] (sysfs_kf_write+0x50/0x54)
[<c0298a7c>] (sysfs_kf_write) from [<c029801c>] (kernfs_fop_write+0x100/0x214)
[<c0297f1c>] (kernfs_fop_write) from [<c0220130>] (__vfs_write+0x34/0x120)
[<c02200fc>] (__vfs_write) from [<c0221088>] (vfs_write+0xa8/0x170)
[<c0220fe0>] (vfs_write) from [<c0221e74>] (SyS_write+0x4c/0xa8)
[<c0221e28>] (SyS_write) from [<c0108a20>] (ret_fast_syscall+0x0/0x1c)
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
mnt: Add a per mount namespace limit on the number of mounts
CAI Qian <caiqian@redhat.com> pointed out that the semantics
of shared subtrees make it possible to create an exponentially
increasing number of mounts in a mount namespace.
mkdir /tmp/1 /tmp/2
mount --make-rshared /
for i in $(seq 1 20) ; do mount --bind /tmp/1 /tmp/2 ; done
Will create create 2^20 or 1048576 mounts, which is a practical problem
as some people have managed to hit this by accident.
As such CVE-2016-6213 was assigned.
Ian Kent <raven@themaw.net> described the situation for autofs users
as follows:
> The number of mounts for direct mount maps is usually not very large because of
> the way they are implemented, large direct mount maps can have performance
> problems. There can be anywhere from a few (likely case a few hundred) to less
> than 10000, plus mounts that have been triggered and not yet expired.
>
> Indirect mounts have one autofs mount at the root plus the number of mounts that
> have been triggered and not yet expired.
>
> The number of autofs indirect map entries can range from a few to the common
> case of several thousand and in rare cases up to between 30000 and 50000. I've
> not heard of people with maps larger than 50000 entries.
>
> The larger the number of map entries the greater the possibility for a large
> number of active mounts so it's not hard to expect cases of a 1000 or somewhat
> more active mounts.
So I am setting the default number of mounts allowed per mount
namespace at 100,000. This is more than enough for any use case I
know of, but small enough to quickly stop an exponential increase
in mounts. Which should be perfect to catch misconfigurations and
malfunctioning programs.
For anyone who needs a higher limit this can be changed by writing
to the new /proc/sys/fs/mount-max sysctl.
Tested-by: CAI Qian <caiqian@redhat.com> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
CVE-2016-6213
(backported from commit d29216842a85c7970c536108e093963f02714498)
[ luis: adjust context ] Signed-off-by: Luis Henriques <luis.henriques@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com>
Lenovo Thinkpad devices T460, T460s, T460p, T560, X260 use
HKEY version 0x200 without adaptive keyboard.
HKEY version 0x200 has method MHKA with one parameter value.
Passing parameter value 1 will get hotkey_all_mask (the same like
HKEY version 0x100 without parameter). Passing parameter value 2 to
MHKA method will retrieve hotkey_all_adaptive_mask. If 0 is returned in
that case there is no adaptive keyboard available.
BugLink: http://bugs.launchpad.net/bugs/1642114 Signed-off-by: Dennis Wassenberg <dennis.wassenberg@secunet.com> Signed-off-by: Lyude <cpaul@redhat.com> Tested-by: Lyude <cpaul@redhat.com> Tested-by: Marco Trevisan <marco@ubuntu.com> Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
[dvhart: Keep MHKA error string on one line in new and existing pr_err calls] Signed-off-by: Darren Hart <dvhart@linux.intel.com>
(cherry picked from commit 0118c2d3eac0545d4095877e5a015b5dc763b3c2) Signed-off-by: Alex Hung <alex.hung@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Colin Ian King <colin.king@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Sakari Ailus [Tue, 15 Nov 2016 12:03:02 +0000 (12:03 +0000)]
videobuf2-v4l2: Verify planes array in buffer dequeueing
When a buffer is being dequeued using VIDIOC_DQBUF IOCTL, the exact buffer
which will be dequeued is not known until the buffer has been removed from
the queue. The number of planes is specific to a buffer, not to the queue.
This does lead to the situation where multi-plane buffers may be requested
and queued with n planes, but VIDIOC_DQBUF IOCTL may be passed an argument
struct with fewer planes.
__fill_v4l2_buffer() however uses the number of planes from the dequeued
videobuf2 buffer, overwriting kernel memory (the m.planes array allocated
in video_usercopy() in v4l2-ioctl.c) if the user provided fewer
planes than the dequeued buffer had. Oops!
Fixes: b0e0e1f83de3 ("[media] media: videobuf2: Prepare to divide videobuf2") Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Cc: stable@vger.kernel.org # for v4.4 and later Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
CVE-2016-4568
(cherry picked from commit 83934b75c368f529d084815c463a7ef781dc9751) Signed-off-by: Luis Henriques <luis.henriques@canonical.com> Acked-by: Colin Ian King <colin.king@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com>
UBUNTU: SAUCE: Bluetooth: decrease refcount after use
BugLink: https://launchpad.net/bugs/1641569
pci_get_subsys() will increase pci device refcount if it finds a
match. Explicitly decrease refcount if a device is found.
Signed-off-by: Wen-chien Jesse Sung <jesse.sung@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Long Li [Thu, 10 Nov 2016 20:51:50 +0000 (15:51 -0500)]
hv: do not lose pending heartbeat vmbus packets
BugLink: http://bugs.launchpad.net/bugs/1632786
The host keeps sending heartbeat packets independent of the
guest responding to them. Even though we respond to the heartbeat messages at
interrupt level, we can have situations where there maybe multiple heartbeat
messages pending that have not been responded to. For instance this occurs when the
VM is paused and the host continues to send the heartbeat messages.
Address this issue by draining and responding to all
the heartbeat messages that maybe pending.
Signed-off-by: Long Li <longli@microsoft.com> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com> CC: Stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 407a3aee6ee2d2cb46d9ba3fc380bc29f35d020c) Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Nicolas Dichtel [Thu, 10 Nov 2016 19:00:23 +0000 (14:00 -0500)]
ipv6: correctly add local routes when lo goes up
BugLink: http://bugs.launchpad.net/bugs/1634545
The goal of the patch is to fix this scenario:
ip link add dummy1 type dummy
ip link set dummy1 up
ip link set lo down ; ip link set lo up
After that sequence, the local route to the link layer address of dummy1 is
not there anymore.
When the loopback is set down, all local routes are deleted by
addrconf_ifdown()/rt6_ifdown(). At this time, the rt6_info entry still
exists, because the corresponding idev has a reference on it. After the rcu
grace period, dst_rcu_free() is called, and thus ___dst_free(), which will
set obsolete to DST_OBSOLETE_DEAD.
In this case, init_loopback() is called before dst_rcu_free(), thus
obsolete is still sets to something <= 0. So, the function doesn't add the
route again. To avoid that race, let's check the rt6 refcnt instead.
Fixes: 25fb6ca4ed9c ("net IPv6 : Fix broken IPv6 routing table after loopback down-up") Fixes: a881ae1f625c ("ipv6: don't call addrconf_dst_alloc again when enable lo") Fixes: 33d99113b110 ("ipv6: reallocate addrconf router for ipv6 address when lo device up") Reported-by: Francesco Santoro <francesco.santoro@6wind.com> Reported-by: Samuel Gauthier <samuel.gauthier@6wind.com> CC: Balakumaran Kannan <Balakumaran.Kannan@ap.sony.com> CC: Maruthi Thotad <Maruthi.Thotad@ap.sony.com> CC: Sabrina Dubroca <sd@queasysnail.net> CC: Hannes Frederic Sowa <hannes@stressinduktion.org> CC: Weilong Chen <chenweilong@huawei.com> CC: Gao feng <gaofeng@cn.fujitsu.com> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit a220445f9f4382c36a53d8ef3e08165fa27f7e2c) Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
audit: stop an old auditd being starved out by a new auditd
BugLink: http://bugs.launchpad.net/bugs/1633404
Nothing prevents a new auditd starting up and replacing a valid
audit_pid when an old auditd is still running, effectively starving out
the old auditd since audit_pid no longer points to the old valid
auditd.
If no message to auditd has been attempted since auditd died
unnaturally or got killed, audit_pid will still indicate it is alive.
There isn't an easy way to detect if an old auditd is still running on
the existing audit_pid other than attempting to send a message to see
if it fails. An -ECONNREFUSED almost certainly means it disappeared
and can be replaced. Other errors are not so straightforward and may
indicate transient problems that will resolve themselves and the old
auditd will recover. Yet others will likely need manual intervention
for which a new auditd will not solve the problem.
Send a new message type (AUDIT_REPLACE) to the old auditd containing a
u32 with the PID of the new auditd. If the audit replace message
succeeds (or doesn't fail with certainty), fail to register the new
auditd and return an error (-EEXIST).
This is expected to make the patch preventing an old auditd orphaning a
new auditd redundant.
V3: Switch audit message type from 1000 to 1300 block.
Signed-off-by: Richard Guy Briggs <rgb@redhat.com> Signed-off-by: Paul Moore <pmoore@redhat.com>
(cherry picked from commit 133e1e5acd4a63c4a0dcc413e90d5decdbce9c4a) Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Andy Whitcroft [Wed, 9 Nov 2016 10:23:37 +0000 (10:23 +0000)]
UBUNTU: hv_set_ifconfig -- ensure we include the last stanza
BugLink: http://bugs.launchpad.net/bugs/1640109 Signed-off-by: Andy Whitcroft <apw@canonical.com> Acked-by: Colin Ian King <colin.king@canonical.com> Acked-by: Brad Figg <brad.figg@canonical.com> Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
BugLink: http://bugs.launchpad.net/bugs/1640109 Signed-off-by: Andy Whitcroft <apw@canonical.com> Acked-by: Colin Ian King <colin.king@canonical.com> Acked-by: Brad Figg <brad.figg@canonical.com> Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
BugLink: http://bugs.launchpad.net/bugs/1646318
When packet_set_ring creates a ring buffer it will initialize a
struct timer_list if the packet version is TPACKET_V3. This value
can then be raced by a different thread calling setsockopt to
set the version to TPACKET_V1 before packet_set_ring has finished.
This leads to a use-after-free on a function pointer in the
struct timer_list when the socket is closed as the previously
initialized timer will not be deleted.
The bug is fixed by taking lock_sock(sk) in packet_setsockopt when
changing the packet version while also taking the lock at the start
of packet_set_ring.
Fixes: f6fb8f100b80 ("af-packet: TPACKET_V3 flexible buffer implementation.") Signed-off-by: Philip Pettersson <philip.pettersson@gmail.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Brad Figg <brad.figg@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Ben Romer <ben.romer@canonical.com>
The backports that fix bug #1633128 for xenial, in particular the backport
of upstream commit a9a62c938441 ("dma-mapping: introduce the
DMA_ATTR_NO_WARN attribute"), introduce a regression.
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
The backports that fix bug #1633128 for xenial, in particular the backport
of upstream commit a9a62c938441 ("dma-mapping: introduce the
DMA_ATTR_NO_WARN attribute"), introduce a regression.
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
The backports that fix bug #1633128 for xenial, in particular the backport
of upstream commit a9a62c938441 ("dma-mapping: introduce the
DMA_ATTR_NO_WARN attribute"), introduce a regression.
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
The kernel fix for bug #1634964 breaks LXD userspace, in particular the
following commits:
ac7f3f73cb39 (namespace) vfs: Don't modify inodes with a uid or gid unknown to the vfs ca52383ad6a6 (namespace) vfs: Don't create inodes with a uid or gid unknown to the vfs
LXD 2.0.6 will include changes to support these kernel changes, but it isn't
available yet on xenial, so for now we just revert these commits.
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
The kernel fix for bug #1634964 breaks LXD userspace, in particular the
following commits:
ac7f3f73cb39 (namespace) vfs: Don't modify inodes with a uid or gid unknown to the vfs ca52383ad6a6 (namespace) vfs: Don't create inodes with a uid or gid unknown to the vfs
LXD 2.0.6 will include changes to support these kernel changes, but it isn't
available yet on xenial, so for now we just revert these commits.
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
The kernel fix for bug #1634964 breaks LXD userspace, in particular the
following commits:
ac7f3f73cb39 (namespace) vfs: Don't modify inodes with a uid or gid unknown to the vfs ca52383ad6a6 (namespace) vfs: Don't create inodes with a uid or gid unknown to the vfs
LXD 2.0.6 will include changes to support these kernel changes, but it isn't
available yet on xenial, so for now we just revert these commits.
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
The kernel fix for bug #1634964 breaks LXD userspace, in particular the
following commits:
ac7f3f73cb39 (namespace) vfs: Don't modify inodes with a uid or gid unknown to the vfs ca52383ad6a6 (namespace) vfs: Don't create inodes with a uid or gid unknown to the vfs
LXD 2.0.6 will include changes to support these kernel changes, but it isn't
available yet on xenial, so for now we just revert these commits.
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
The kernel fix for bug #1634964 breaks LXD userspace, in particular the
following commits:
ac7f3f73cb39 (namespace) vfs: Don't modify inodes with a uid or gid unknown to the vfs ca52383ad6a6 (namespace) vfs: Don't create inodes with a uid or gid unknown to the vfs
LXD 2.0.6 will include changes to support these kernel changes, but it isn't
available yet on xenial, so for now we just revert these commits.
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
The kernel fix for bug #1634964 breaks LXD userspace, in particular the
following commits:
ac7f3f73cb39 (namespace) vfs: Don't modify inodes with a uid or gid unknown to the vfs ca52383ad6a6 (namespace) vfs: Don't create inodes with a uid or gid unknown to the vfs
LXD 2.0.6 will include changes to support these kernel changes, but it isn't
available yet on xenial, so for now we just revert these commits.
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
The kernel fix for bug #1634964 breaks LXD userspace, in particular the
following commits:
ac7f3f73cb39 (namespace) vfs: Don't modify inodes with a uid or gid unknown to the vfs ca52383ad6a6 (namespace) vfs: Don't create inodes with a uid or gid unknown to the vfs
LXD 2.0.6 will include changes to support these kernel changes, but it isn't
available yet on xenial, so for now we just revert these commits.
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
The kernel fix for bug #1634964 breaks LXD userspace, in particular the
following commits:
ac7f3f73cb39 (namespace) vfs: Don't modify inodes with a uid or gid unknown to the vfs ca52383ad6a6 (namespace) vfs: Don't create inodes with a uid or gid unknown to the vfs
LXD 2.0.6 will include changes to support these kernel changes, but it isn't
available yet on xenial, so for now we just revert these commits.
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
The kernel fix for bug #1634964 breaks LXD userspace, in particular the
following commits:
ac7f3f73cb39 (namespace) vfs: Don't modify inodes with a uid or gid unknown to the vfs ca52383ad6a6 (namespace) vfs: Don't create inodes with a uid or gid unknown to the vfs
LXD 2.0.6 will include changes to support these kernel changes, but it isn't
available yet on xenial, so for now we just revert these commits.
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
The kernel fix for bug #1634964 breaks LXD userspace, in particular the
following commits:
ac7f3f73cb39 (namespace) vfs: Don't modify inodes with a uid or gid unknown to the vfs ca52383ad6a6 (namespace) vfs: Don't create inodes with a uid or gid unknown to the vfs
LXD 2.0.6 will include changes to support these kernel changes, but it isn't
available yet on xenial, so for now we just revert these commits.
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
The kernel fix for bug #1634964 breaks LXD userspace, in particular the
following commits:
ac7f3f73cb39 (namespace) vfs: Don't modify inodes with a uid or gid unknown to the vfs ca52383ad6a6 (namespace) vfs: Don't create inodes with a uid or gid unknown to the vfs
LXD 2.0.6 will include changes to support these kernel changes, but it isn't
available yet on xenial, so for now we just revert these commits.
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
The kernel fix for bug #1634964 breaks LXD userspace, in particular the
following commits:
ac7f3f73cb39 (namespace) vfs: Don't modify inodes with a uid or gid unknown to the vfs ca52383ad6a6 (namespace) vfs: Don't create inodes with a uid or gid unknown to the vfs
LXD 2.0.6 will include changes to support these kernel changes, but it isn't
available yet on xenial, so for now we just revert these commits.
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
The kernel fix for bug #1634964 breaks LXD userspace, in particular the
following commits:
ac7f3f73cb39 (namespace) vfs: Don't modify inodes with a uid or gid unknown to the vfs ca52383ad6a6 (namespace) vfs: Don't create inodes with a uid or gid unknown to the vfs
LXD 2.0.6 will include changes to support these kernel changes, but it isn't
available yet on xenial, so for now we just revert these commits.
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
The kernel fix for bug #1634964 breaks LXD userspace, in particular the
following commits:
ac7f3f73cb39 (namespace) vfs: Don't modify inodes with a uid or gid unknown to the vfs ca52383ad6a6 (namespace) vfs: Don't create inodes with a uid or gid unknown to the vfs
LXD 2.0.6 will include changes to support these kernel changes, but it isn't
available yet on xenial, so for now we just revert these commits.
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
The kernel fix for bug #1634964 breaks LXD userspace, in particular the
following commits:
ac7f3f73cb39 (namespace) vfs: Don't modify inodes with a uid or gid unknown to the vfs ca52383ad6a6 (namespace) vfs: Don't create inodes with a uid or gid unknown to the vfs
LXD 2.0.6 will include changes to support these kernel changes, but it isn't
available yet on xenial, so for now we just revert these commits.
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
The kernel fix for bug #1634964 breaks LXD userspace, in particular the
following commits:
ac7f3f73cb39 (namespace) vfs: Don't modify inodes with a uid or gid unknown to the vfs ca52383ad6a6 (namespace) vfs: Don't create inodes with a uid or gid unknown to the vfs
LXD 2.0.6 will include changes to support these kernel changes, but it isn't
available yet on xenial, so for now we just revert these commits.
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
The kernel fix for bug #1634964 breaks LXD userspace, in particular the
following commits:
ac7f3f73cb39 (namespace) vfs: Don't modify inodes with a uid or gid unknown to the vfs ca52383ad6a6 (namespace) vfs: Don't create inodes with a uid or gid unknown to the vfs
LXD 2.0.6 will include changes to support these kernel changes, but it isn't
available yet on xenial, so for now we just revert these commits.
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
The kernel fix for bug #1634964 breaks LXD userspace, in particular the
following commits:
ac7f3f73cb39 (namespace) vfs: Don't modify inodes with a uid or gid unknown to the vfs ca52383ad6a6 (namespace) vfs: Don't create inodes with a uid or gid unknown to the vfs
LXD 2.0.6 will include changes to support these kernel changes, but it isn't
available yet on xenial, so for now we just revert these commits.
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
The kernel fix for bug #1634964 breaks LXD userspace, in particular the
following commits:
ac7f3f73cb39 (namespace) vfs: Don't modify inodes with a uid or gid unknown to the vfs ca52383ad6a6 (namespace) vfs: Don't create inodes with a uid or gid unknown to the vfs
LXD 2.0.6 will include changes to support these kernel changes, but it isn't
available yet on xenial, so for now we just revert these commits.
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
The kernel fix for bug #1634964 breaks LXD userspace, in particular the
following commits:
ac7f3f73cb39 (namespace) vfs: Don't modify inodes with a uid or gid unknown to the vfs ca52383ad6a6 (namespace) vfs: Don't create inodes with a uid or gid unknown to the vfs
LXD 2.0.6 will include changes to support these kernel changes, but it isn't
available yet on xenial, so for now we just revert these commits.
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
The kernel fix for bug #1634964 breaks LXD userspace, in particular the
following commits:
ac7f3f73cb39 (namespace) vfs: Don't modify inodes with a uid or gid unknown to the vfs ca52383ad6a6 (namespace) vfs: Don't create inodes with a uid or gid unknown to the vfs
LXD 2.0.6 will include changes to support these kernel changes, but it isn't
available yet on xenial, so for now we just revert these commits.
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Ubuntu [Mon, 7 Nov 2016 21:43:58 +0000 (21:43 +0000)]
UBUNTU: SAUCE: Makefile RDMA infiniband driver for Windows Azure
BugLink: http://bugs.launchpad.net/bugs/1641139
Committer: Long Li <longli@microsoft.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Brad Figg <brad.figg@canonical.com> Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
(upstream) mm: Add a user_ns owner to mm_struct and fix ptrace permission checks
BugLink: https://bugs.launchpad.net/bugs/1639345
During exec dumpable is cleared if the file that is being executed is
not readable by the user executing the file. A bug in
ptrace_may_access allows reading the file if the executable happens to
enter into a subordinate user namespace (aka clone(CLONE_NEWUSER),
unshare(CLONE_NEWUSER), or setns(fd, CLONE_NEWUSER).
This problem is fixed with only necessary userspace breakage by adding
a user namespace owner to mm_struct, captured at the time of exec, so
it is clear in which user namespace CAP_SYS_PTRACE must be present in
to be able to safely give read permission to the executable.
The function ptrace_may_access is modified to verify that the ptracer
has CAP_SYS_ADMIN in task->mm->user_ns instead of task->cred->user_ns.
This ensures that if the task changes it's cred into a subordinate
user namespace it does not become ptraceable.
The function ptrace_attach is modified to only set PT_PTRACE_CAP when
CAP_SYS_PTRACE is held over task->mm->user_ns. The intent of
PT_PTRACE_CAP is to be a flag to note that whatever permission changes
the task might go through the tracer has sufficient permissions for
it not to be an issue. task->cred->user_ns is always the same
as or descendent of mm->user_ns. Which guarantees that having
CAP_SYS_PTRACE over mm->user_ns is the worst case for the tasks
credentials.
To prevent regressions mm->dumpable and mm->user_ns are not considered
when a task has no mm. As simply failing ptrace_may_attach causes
regressions in privileged applications attempting to read things
such as /proc/<pid>/stat
Cc: stable@vger.kernel.org Acked-by: Kees Cook <keescook@chromium.org> Tested-by: Cyrill Gorcunov <gorcunov@openvz.org> Fixes: 8409cca70561 ("userns: allow ptrace from non-init user namespaces") Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
(cherry picked from commit 2e41414828bb0b066bde2f156cfa848c38531edf 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 [Mon, 7 Nov 2016 16:32:36 +0000 (09:32 -0700)]
powerpc/xmon: Add xmon command to dump process/task similar to ps(1)
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 6dfb54049f9a99b24fe5d5cd2d3af19eadc8f31f) Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Brad Figg <brad.figg@canonical.com> Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Colin Ian King [Wed, 26 Oct 2016 09:06:08 +0000 (05:06 -0400)]
UBUNTU: SAUCE: (noup) Update zfs to 0.6.5.6-0ubuntu15
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: Tim Gardner <tim.gardner@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
pinctrl/amd: Configure GPIO register using BIOS settings
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/1612006 Reviewed-by: Pankaj Sen <Pankaj.Sen@amd.com>
Signed-off-by:Nitesh Kumar Agrawal <Nitesh-kumar.Agrawal@amd.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
(cherry picked from commit 499c7196dd182ba513ccb9620ee22aed3f9096fd) Signed-off-by: Alex Hung <alex.hung@canonical.com> Acked-by: Robert Hooker <robert.hooker@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Paul Mackerras [Thu, 27 Oct 2016 14:24:04 +0000 (08:24 -0600)]
KVM: PPC: Always select KVM_VFIO, plus Makefile cleanup
BugLink: http://bugs.launchpad.net/bugs/1630554
As discussed recently on the kvm mailing list, David Gibson's
intention in commit 178a78750212 ("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 4b3d173d0440d37534906b6d93c02dfb577c68ce) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Conflicts:
arch/powerpc/kvm/Makefile Acked-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Seth Forshee [Mon, 17 Oct 2016 22:02:48 +0000 (17:02 -0500)]
UBUNTU: SAUCE: (namespace) fuse: Allow user namespace mounts by default
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 <seth.forshee@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
UBUNTU: SAUCE: (namespace) fs: Don't remove suid for CAP_FSETID for userns root
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>
UBUNTU: SAUCE: (namespace) fs: Allow superblock owner to change ownership of inodes
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 <seth.forshee@canonical.com> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
UBUNTU: SAUCE: (namespace) security/integrity: Harden against malformed xattrs
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 <seth.forshee@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
(namespace) dquot: For now explicitly don't support filesystems outside of init_user_ns
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: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
(cherry picked from commit 5c0048280babd579fa9e5f0e787122b06aee3f3b) Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
(namespace) quota: Ensure qids map to the filesystem
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 <seth.forshee@canonical.com> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
(backported from commit d49d37624a1931c2f3b5d0cbe95bd5181cbdc279) Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
(namespace) vfs: Don't create inodes with a uid or gid unknown to the vfs
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: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
(cherry picked from commit 036d523641c66bef713042894a17f4335f199e49) Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
(namespace) vfs: Don't modify inodes with a uid or gid unknown to the vfs
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 <seth.forshee@canonical.com> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
(cherry picked from commit 0bd23d09b874e53bd1a2fe2296030aa2720d7b08) Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Seth Forshee [Wed, 24 Aug 2016 16:47:05 +0000 (11:47 -0500)]
UBUNTU: SAUCE: (namespace) fuse: Translate ids in posix acl xattrs
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 <seth.forshee@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
UBUNTU: SAUCE: (namespace) posix_acl: Export posix_acl_fix_xattr_userns() to modules
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: Seth Forshee <seth.forshee@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
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 <seth.forshee@canonical.com> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
(backported from commit 0d4d717f25834134bb6f43284f84c8ccee5bbf2a)
[ saf: Adjust context for addition of set_posix_acl(), update zfs
calls to posix_acl_valid() ] Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
(namespace) fs: Refuse uid/gid changes which don't map into s_user_ns
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 <seth.forshee@canonical.com> Acked-by: Serge Hallyn <serge.hallyn@canonical.com> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
(cherry picked from commit a475acf01f79e89a1a5845733e10108d80f77188) Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
(namespace) mnt: Move the FS_USERNS_MOUNT check into sget_userns
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: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
(cherry picked from commit a001e74cef34d95ede6535ef521011c612657a3a) Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
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: Tim Gardner <tim.gardner@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Acked-by: Robert Hooker <robert.hooker@canonical.com> Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Ming Lei [Thu, 3 Nov 2016 01:20:01 +0000 (09:20 +0800)]
UBUNTU: SAUCE: hio: splitting bio in the entry of .make_request_fn
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.
Signed-off-by: Ming Lei <ming.lei@canonical.com> Signed-off-by: Kamal Mostafa <kamal@canonical.com> Acked-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com>
Wang, Rui Y [Thu, 27 Oct 2016 12:25:26 +0000 (10:25 -0200)]
crypto: mcryptd - Fix load failure
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 ddef482420b1ba8ec45e6123a7e8d3f67b21e5e3) Signed-off-by: Marcelo Cerri <marcelo.cerri@canonical.com> Acked-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
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:
projects / mirror_ubuntu-zesty-kernel.git / log