Kernel Panic on EC2 After Upgrading from 14.04 to 16.04 via do-release-upgrade -d

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1573231/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

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

apport-collect 1573231

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.

Sorry, I don't think there's any possible way to do it. The machine won't boot. I could try to reproduce the issue again on a different VM, but I still wouldn't be able to collect logs.

Currently also encountering this issue (the same kernel panic) with ami-3079f543 on eu-west-1 with a c3.large instance.

So this seems to be a general ubuntu 16.04 on AWS issue and not an upgrade specific issue. I haven't seen this issue with the beta2 AMIs.

Interestingly I seem to be able to start the AMI on t2.micro instances, so this could well be instance type specific.

I've tested with some instance types with the ami-3079f543 image (eg. ubuntu 16.04 final with Ubuntu 4.4.0-21.37-generic 4.4.6)

The following instance types fail to start with a kernel panic:

r3.large
c3.large

The following instance types seem to work:

t2.micro
c4.large
m3.medium

I haven't tested with all sizes, but I suspect all t2, c4 and m3 instances are good.

FWIW, m3.large is also affected.

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.6 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.6-rc5-wily/

I can still reproduce this in 4.6-rc5. See attached boot log.

I might do a bisect on this if I find the time...

Bisecting...

Current candidate seems to be 31c2013e4ea2e594522980acc3d20e88664b19f1

According to my bisect this commit is responsible:

commit 8ae10f463b7ae3455e9d0507176349c76580995f
Author: Vikas Shivappa <email address hidden>
Date: Thu Mar 10 15:32:09 2016 -0800

    perf/x86/mbm: Add Intel Memory B/W Monitoring enumeration and init

    BugLink: http://bugs.launchpad.net/bugs/1397880

    The MBM init patch enumerates the Intel MBM (Memory b/w monitoring)
    and initializes the perf events and datastructures for monitoring the
    memory b/w.

    Its based on original patch series by Tony Luck and Kanaka Juvva.

    Memory bandwidth monitoring (MBM) provides OS/VMM a way to monitor
    bandwidth from one level of cache to another. The current patches
    support L3 external bandwidth monitoring. It supports both 'local
    bandwidth' and 'total bandwidth' monitoring for the socket. Local
    bandwidth measures the amount of data sent through the memory controller
    on the socket and total b/w measures the total system bandwidth.

    Extending the cache quality of service monitoring (CQM) we add two
    more events to the perf infrastructure:

      intel_cqm_llc/local_bytes - bytes sent through local socket memory controller
      intel_cqm_llc/total_bytes - total L3 external bytes sent

    The tasks are associated with a Resouce Monitoring ID (RMID) just like
    in CQM and OS uses a MSR write to indicate the RMID of the task during
    scheduling.

    Signed-off-by: Vikas Shivappa <email address hidden>
    Signed-off-by: Peter Zijlstra (Intel) <email address hidden>
    Reviewed-by: Tony Luck <email address hidden>
    Acked-by: Thomas Gleixner <email address hidden>
    Cc: Alexander Shishkin <email address hidden>
    Cc: Andy Lutomirski <email address hidden>
    Cc: Arnaldo Carvalho de Melo <email address hidden>
    Cc: Borislav Petkov <email address hidden>
    Cc: Brian Gerst <email address hidden>
    Cc: David Ahern <email address hidden>
    Cc: Denys Vlasenko <email address hidden>
    Cc: H. Peter Anvin <email address hidden>
    Cc: Jiri Olsa <email address hidden>
    Cc: Linus Torvalds <email address hidden>
    Cc: Matt Fleming <email address hidden>
    Cc: Namhyung Kim <email address hidden>
    Cc: Peter Zijlstra <email address hidden>
    Cc: Stephane Eranian <email address hidden>
    Cc: Vince Weaver <email address hidden>
    Cc: <email address hidden>
    Cc: <email address hidden>
    Cc: <email address hidden>
    Cc: <email address hidden>
    Link: http://lkml<email address hidden>
    Signed-off-by: Ingo Molnar <email address hidden>
    (back ported from commit 33c3cc7acfd95968d74247f1a4e1b0727a07ed43)
    Signed-off-by: Tim Gardner <email address hidden>

     Conflicts:
        arch/x86/kernel/cpu/common.c

Verified it on multiple instances.

31c2013e4ea2e594522980acc3d20e88664b19f1 is the last good commit.
8ae10f463b7ae3455e9d0507176349c76580995f is the first bad commit.

I built a test kernel with a revert of 33c3cc7(8ae10f463 in Xenial). To revert this commit, I also had to revert e7ee3e8, 2d4de83 and 87f01cc.

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1573231/

Can you test this kernel and see if it resolves this bug?

I get the same issue with the build, which seemed weird so I retested and it looks like I must have mislabeled one of my builds, because now when I build 31c2013e4ea2e594522980acc3d20e88664b19f1, I still get the issue, but if I go back to a6ebb4464659d35e0516900a8493f9720dd77d67 it works.
Somehow I must have swapped some builds...

a6ebb4464659d35e0516900a8493f9720dd77d67 Good
31c2013e4ea2e594522980acc3d20e88664b19f1 Bad
8ae10f463b7ae3455e9d0507176349c76580995f Bad

Really sorry about the detour Joseph.

I built a test kernel with a revert of 1f12e32f4. To revert this commit, I also had to revert e7ee3e8, 2d4de83, 87f01cc and 33c3cc7

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1573231/

Can you test this kernel and see if it resolves this bug?

I can confirm that I can boot with this kernel on a C3.large instance.

If anyone else wants to verify this, the procedure is to boot one of the failing instances with the Beta 2 AMIs and install the build (and reboot).

Hi Thomas,

A kernel bug report was opened against Ubuntu [0]. After a kernel
bisect, it was found that reverting the following commit resolved this bug:

commit 1f12e32f4cd5243ae46d8b933181be0d022c6793
Author: Thomas Gleixner <email address hidden>
Date: Mon Feb 22 22:19:15 2016 +0000

    x86/topology: Create logical package id

To build successfully with this commit reverted, I also had to revert
commits: e7ee3e8,2d4de83,87f01cc and 33c3cc7.

The regression was introduced as of v4.6-rc1.

I was hoping to get your feedback, since you are the patch author. Do
you think gathering any additional data will help diagnose this issue,
or would it be best to submit a revert request?

Thanks,

Joe

[0] http://pad.lv/1573231

comment #16 is the message I sent to upstream.

On Fri, 6 May 2016, Joseph Salisbury wrote:
> A kernel bug report was opened against Ubuntu [0]. After a kernel
> bisect, it was found that reverting the following commit resolved this bug:
>
> commit 1f12e32f4cd5243ae46d8b933181be0d022c6793
> Author: Thomas Gleixner <email address hidden>
> Date: Mon Feb 22 22:19:15 2016 +0000
>
> x86/topology: Create logical package id
>
> To build successfully with this commit reverted, I also had to revert
> commits: e7ee3e8,2d4de83,87f01cc and 33c3cc7.
>
> The regression was introduced as of v4.6-rc1.
>
> I was hoping to get your feedback, since you are the patch author. Do
> you think gathering any additional data will help diagnose this issue,
> or would it be best to submit a revert request?

Yuck. That dies with a divide error. And that looks like XEN is supplying crap
data in the CPUID.

Does the patch below cure the issue?

Thanks,

        tglx

8<---------------

--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -332,6 +332,11 @@ static void __init smp_init_package_map(
   * primary cores.
   */
  ncpus = boot_cpu_data.x86_max_cores;
+ if (!ncpus) {
+ pr_warn("x86_max_cores == zero !?!?");
+ ncpus = 1;
+ }
+
  __max_logical_packages = DIV_ROUND_UP(total_cpus, ncpus);

  /*

@Joe, based upon the identified commit, I wonder if it would be worth testing backports of follow-on fixes specifically for that commit?

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b5d5f27d938fb6fc8d3202704e699d2694a02da6
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=63d1e995be455ae9196270eb4b789de21afd42ed
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b5d5f27d938fb6fc8d3202704e699d2694a02da6

Not sure if all of them are necessary but the second one esp. might be relevant as it changes the divisor.

Err, apologies Joe, it does seem like upon more careful reading of the bug report, the second mentioned commit (comment #18) specifically introduced the regression? That seems unlikely at best given it's contents, rights? That is, if the divisor was zero after that commit, it was zero before it, too, unless there's another division going on that's implicit.

On 05/06/2016 02:48 PM, Thomas Gleixner wrote:
> On Fri, 6 May 2016, Joseph Salisbury wrote:
>> A kernel bug report was opened against Ubuntu [0]. After a kernel
>> bisect, it was found that reverting the following commit resolved this bug:
>>
>> commit 1f12e32f4cd5243ae46d8b933181be0d022c6793
>> Author: Thomas Gleixner <email address hidden>
>> Date: Mon Feb 22 22:19:15 2016 +0000
>>
>> x86/topology: Create logical package id
>>
>> To build successfully with this commit reverted, I also had to revert
>> commits: e7ee3e8,2d4de83,87f01cc and 33c3cc7.
>>
>> The regression was introduced as of v4.6-rc1.
>>
>> I was hoping to get your feedback, since you are the patch author. Do
>> you think gathering any additional data will help diagnose this issue,
>> or would it be best to submit a revert request?
> Yuck. That dies with a divide error. And that looks like XEN is supplying crap
> data in the CPUID.

Joe, do you have

ed6069b xen/apic: Provide Xen-specific version of cpu_present_to_apicid
APIC op

-boris

>
> Does the patch below cure the issue?
>
> Thanks,
>
> tglx
>
> 8<---------------
>
> --- a/arch/x86/kernel/smpboot.c
> +++ b/arch/x86/kernel/smpboot.c
> @@ -332,6 +332,11 @@ static void __init smp_init_package_map(
> * primary cores.
> */
> ncpus = boot_cpu_data.x86_max_cores;
> + if (!ncpus) {
> + pr_warn("x86_max_cores == zero !?!?");
> + ncpus = 1;
> + }
> +
> __max_logical_packages = DIV_ROUND_UP(total_cpus, ncpus);
>
> /*

On 05/06/2016 03:13 PM, Boris Ostrovsky wrote:
> On 05/06/2016 02:48 PM, Thomas Gleixner wrote:
>> On Fri, 6 May 2016, Joseph Salisbury wrote:
>>> A kernel bug report was opened against Ubuntu [0]. After a kernel
>>> bisect, it was found that reverting the following commit resolved this bug:
>>>
>>> commit 1f12e32f4cd5243ae46d8b933181be0d022c6793
>>> Author: Thomas Gleixner <email address hidden>
>>> Date: Mon Feb 22 22:19:15 2016 +0000
>>>
>>> x86/topology: Create logical package id
>>>
>>> To build successfully with this commit reverted, I also had to revert
>>> commits: e7ee3e8,2d4de83,87f01cc and 33c3cc7.
>>>
>>> The regression was introduced as of v4.6-rc1.
>>>
>>> I was hoping to get your feedback, since you are the patch author. Do
>>> you think gathering any additional data will help diagnose this issue,
>>> or would it be best to submit a revert request?
>> Yuck. That dies with a divide error. And that looks like XEN is supplying crap
>> data in the CPUID.
> Joe, do you have
>
> ed6069b xen/apic: Provide Xen-specific version of cpu_present_to_apicid
> APIC op
>
> -boris
Yes the commit is in the 4.4 based Ubuntu kernel. This bug also happens
with the vanilla 4.6-rc5 kernel, which also has that commit.

>
>
>> Does the patch below cure the issue?
>>
>> Thanks,
>>
>> tglx
>>
>> 8<---------------
>>
>> --- a/arch/x86/kernel/smpboot.c
>> +++ b/arch/x86/kernel/smpboot.c
>> @@ -332,6 +332,11 @@ static void __init smp_init_package_map(
>> * primary cores.
>> */
>> ncpus = boot_cpu_data.x86_max_cores;
>> + if (!ncpus) {
>> + pr_warn("x86_max_cores == zero !?!?");
>> + ncpus = 1;
>> + }
>> +
>> __max_logical_packages = DIV_ROUND_UP(total_cpus, ncpus);
>>
>> /*
>

On 05/06/2016 02:48 PM, Thomas Gleixner wrote:
> On Fri, 6 May 2016, Joseph Salisbury wrote:
>> A kernel bug report was opened against Ubuntu [0]. After a kernel
>> bisect, it was found that reverting the following commit resolved this bug:
>>
>> commit 1f12e32f4cd5243ae46d8b933181be0d022c6793
>> Author: Thomas Gleixner <email address hidden>
>> Date: Mon Feb 22 22:19:15 2016 +0000
>>
>> x86/topology: Create logical package id
>>
>> To build successfully with this commit reverted, I also had to revert
>> commits: e7ee3e8,2d4de83,87f01cc and 33c3cc7.
>>
>> The regression was introduced as of v4.6-rc1.
>>
>> I was hoping to get your feedback, since you are the patch author. Do
>> you think gathering any additional data will help diagnose this issue,
>> or would it be best to submit a revert request?
> Yuck. That dies with a divide error. And that looks like XEN is supplying crap
> data in the CPUID.
>
> Does the patch below cure the issue?
>
> Thanks,
>
> tglx
>
> 8<---------------
>
> --- a/arch/x86/kernel/smpboot.c
> +++ b/arch/x86/kernel/smpboot.c
> @@ -332,6 +332,11 @@ static void __init smp_init_package_map(
> * primary cores.
> */
> ncpus = boot_cpu_data.x86_max_cores;
> + if (!ncpus) {
> + pr_warn("x86_max_cores == zero !?!?");
> + ncpus = 1;
> + }
> +
> __max_logical_packages = DIV_ROUND_UP(total_cpus, ncpus);
>
> /*
I'll have this patch tested and report back.

Thanks,

Joe

I built a test kernel with the patch suggested by Thomas Gleixner. The test kernel can be downloaded from:

http://kernel.ubuntu.com/~jsalisbury/lp1573231/

Can you test this kernel and see if it resolves this bug?

Kernel boots correctly on a c3.large with Thomas patch.

I've attached the output of the cpuid command (apt-get install cpuid) on the instance, in case it has any interest.

CPUID output posted before was truncated...

On 05/06/2016 03:38 PM, Joseph Salisbury wrote:
> On 05/06/2016 03:13 PM, Boris Ostrovsky wrote:
>> On 05/06/2016 02:48 PM, Thomas Gleixner wrote:
>>>
>>> Yuck. That dies with a divide error. And that looks like XEN is supplying crap
>>> data in the CPUID.
>> Joe, do you have
>>
>> ed6069b xen/apic: Provide Xen-specific version of cpu_present_to_apicid
>> APIC op
>>
>> -boris
> Yes the commit is in the 4.4 based Ubuntu kernel. This bug also happens
> with the vanilla 4.6-rc5 kernel, which also has that commit.

Can you post guest's cpuid -1 -r ? (I guess after you verify Thomas' patch)

Thanks.
-boris

On 05/06/2016 03:38 PM, Joseph Salisbury wrote:
> On 05/06/2016 02:48 PM, Thomas Gleixner wrote:
>> On Fri, 6 May 2016, Joseph Salisbury wrote:
>>> A kernel bug report was opened against Ubuntu [0]. After a kernel
>>> bisect, it was found that reverting the following commit resolved this bug:
>>>
>>> commit 1f12e32f4cd5243ae46d8b933181be0d022c6793
>>> Author: Thomas Gleixner <email address hidden>
>>> Date: Mon Feb 22 22:19:15 2016 +0000
>>>
>>> x86/topology: Create logical package id
>>>
>>> To build successfully with this commit reverted, I also had to revert
>>> commits: e7ee3e8,2d4de83,87f01cc and 33c3cc7.
>>>
>>> The regression was introduced as of v4.6-rc1.
>>>
>>> I was hoping to get your feedback, since you are the patch author. Do
>>> you think gathering any additional data will help diagnose this issue,
>>> or would it be best to submit a revert request?
>> Yuck. That dies with a divide error. And that looks like XEN is supplying crap
>> data in the CPUID.
>>
>> Does the patch below cure the issue?
>>
>> Thanks,
>>
>> tglx
>>
>> 8<---------------
>>
>> --- a/arch/x86/kernel/smpboot.c
>> +++ b/arch/x86/kernel/smpboot.c
>> @@ -332,6 +332,11 @@ static void __init smp_init_package_map(
>> * primary cores.
>> */
>> ncpus = boot_cpu_data.x86_max_cores;
>> + if (!ncpus) {
>> + pr_warn("x86_max_cores == zero !?!?");
>> + ncpus = 1;
>> + }
>> +
>> __max_logical_packages = DIV_ROUND_UP(total_cpus, ncpus);
>>
>> /*
> I'll have this patch tested and report back.
>
> Thanks,
>
> Joe
Yes, your patch does in fact fix the bug. Would you like any additional
information regarding the bug?

On 05/06/2016 04:46 PM, Boris Ostrovsky wrote:
> On 05/06/2016 03:38 PM, Joseph Salisbury wrote:
>> On 05/06/2016 03:13 PM, Boris Ostrovsky wrote:
>>> On 05/06/2016 02:48 PM, Thomas Gleixner wrote:
>>>> Yuck. That dies with a divide error. And that looks like XEN is supplying crap
>>>> data in the CPUID.
>>> Joe, do you have
>>>
>>> ed6069b xen/apic: Provide Xen-specific version of cpu_present_to_apicid
>>> APIC op
>>>
>>> -boris
>> Yes the commit is in the 4.4 based Ubuntu kernel. This bug also happens
>> with the vanilla 4.6-rc5 kernel, which also has that commit.
>
> Can you post guest's cpuid -1 -r ? (I guess after you verify Thomas' patch)
>
> Thanks.
> -boris
>
>
>
Thomas' patch does resolve the bug. The cpuid info can be seen here:
https://launchpadlibrarian.net/258234267/cpuid_full.txt

Thanks,

Joe

On 05/06/2016 04:51 PM, Joseph Salisbury wrote:
> Thomas' patch does resolve the bug. The cpuid info can be seen here:
> https://launchpadlibrarian.net/258234267/cpuid_full.txt

Any chance you could post it raw (cpuid -1 -r)?

Thanks.
-boris

Here you go, cpuid -1 -r output.

Hi — any idea when the AMIs will be updated?

Xenial can't be launched on half of AWS instances so far. :(

Well, they're probably waiting for the patch to hit the LTS kernel 4.4 branch, which will probably happen on the 18th May... Or something like that.

But you can easily run it until then...

Use the 16.04 Beta 2 AMIs, but just disable kernel updates (say, with "apt-mark hold") and update everything else. That will basically give you all the final stuff, just without the last few kernel updates, including the one that broke most EC2 instances.

When a working kernel gets here, just apt-mark unhold and you should be good.

You might want to temporarily disable automatic security updates until then if you do it though...

Hello,

I'm getting kernel panic on m3.large with these AMI:

- ubuntu/images/hvm-ssd/ubuntu-xenial-16.04-amd64-server-20160420.3 (ami-840910ee)
- ubuntu/images/hvm-ssd/ubuntu-xenial-16.04-amd64-server-20160516.1 (ami-13be557e)

"Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b"

Both use HVM. With Xenial paravirtual AMI I don't get kernel panic.

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!

I've verified that the linux-image-4.4.0-23-generic image in xenial-proposed boots correctly on a c3.large ec2 instance.
uname -v: #41-Ubuntu SMP Mon May 16 23:04:25 UTC 2016

root@ip-10-33-53-135:~# apt-cache showpkg linux-image-4.4.0-23-generic
Package: linux-image-4.4.0-23-generic
Versions:
4.4.0-23.41 (/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_xenial-proposed_main_binary-amd64_Packages)
 Description Language:
                 File: /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_xenial-proposed_main_binary-amd64_Packages
                  MD5: 301993998617cbcae03feb3fe5d3aa55
 Description Language: en
                 File: /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_xenial-proposed_main_i18n_Translation-en
                  MD5: 301993998617cbcae03feb3fe5d3aa55

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

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

  [ Kamal Mostafa ]

  * Release Tracking Bug
    - LP: #1582431

  * zfs: disable module checks for zfs when cross-compiling (LP: #1581127)
    - [Packaging] disable zfs module checks when cross-compiling

  * Xenial update to v4.4.10 stable release (LP: #1580754)
    - Revert "UBUNTU: SAUCE: (no-up) ACPICA: Dispatcher: Update thread ID for
      recursive method calls"
    - Revert "UBUNTU: SAUCE: nbd: ratelimit error msgs after socket close"
    - Revert: "powerpc/tm: Check for already reclaimed tasks"
    - RDMA/iw_cxgb4: Fix bar2 virt addr calculation for T4 chips
    - ipvs: handle ip_vs_fill_iph_skb_off failure
    - ipvs: correct initial offset of Call-ID header search in SIP persistence
      engine
    - ipvs: drop first packet to redirect conntrack
    - mfd: intel-lpss: Remove clock tree on error path
    - nbd: ratelimit error msgs after socket close
    - ata: ahci_xgene: dereferencing uninitialized pointer in probe
    - mwifiex: fix corner case association failure
    - CNS3xxx: Fix PCI cns3xxx_write_config()
    - clk-divider: make sure read-only dividers do not write to their register
    - soc: rockchip: power-domain: fix err handle while probing
    - clk: rockchip: free memory in error cases when registering clock branches
    - clk: meson: Fix meson_clk_register_clks() signature type mismatch
    - clk: qcom: msm8960: fix ce3_core clk enable register
    - clk: versatile: sp810: support reentrance
    - clk: qcom: msm8960: Fix ce3_src register offset
    - lpfc: fix misleading indentation
    - ath9k: ar5008_hw_cmn_spur_mitigate: add missing mask_m & mask_p
      initialisation
    - mac80211: fix statistics leak if dev_alloc_name() fails
    - tracing: Don't display trigger file for events that can't be enabled
    - MD: make bio mergeable
    - Minimal fix-up of bad hashing behavior of hash_64()
    - mm, cma: prevent nr_isolated_* counters from going negative
    - mm/zswap: provide unique zpool name
    - ARM: EXYNOS: Properly skip unitialized parent clock in power domain on
    - ARM: SoCFPGA: Fix secondary CPU startup in thumb2 kernel
    - xen: Fix page <-> pfn conversion on 32 bit systems
    - xen/balloon: Fix crash when ballooning on x86 32 bit PAE
    - xen/evtchn: fix ring resize when binding new events
    - HID: wacom: Add support for DTK-1651
    - HID: Fix boot delay for Creative SB Omni Surround 5.1 with quirk
    - Input: zforce_ts - fix dual touch recognition
    - proc: prevent accessing /proc/<PID>/environ until it's ready
    - mm: update min_free_kbytes from khugepaged after core initialization
    - batman-adv: fix DAT candidate selection (must use vid)
    - batman-adv: Check skb size before using encapsulated ETH+VLAN header
    - batman-adv: Fix broadcast/ogm queue limit on a removed interface
    - batman-adv: Reduce refcnt of removed router when updating route
    - writeback: Fix performance regression in wb_over_bg_thresh()
    - MAINTAINERS: Remove asterisk from EFI directory names
    - x86/tsc: Read all ratio bits from MSR_PLATFORM_INFO
    - ARM: cpuidle: Pass on arm_cpuidle_s...

Any update on when this is going to get released for Xenial?

the kernel version this is fixed in is proposed, but has urgency=low, which seems contradictory to the "critical" importance of this bug. Not sure if that should be changed / how that would be changed.

Travis, the urgency= field is completely ignored in all Ubuntu tooling.

The Ubuntu 14.04 cloud images remain broken on m3.large and c3.large. Is there a way to expedite building them with the fix? It seems that the Ubuntu release process is broken, if bugs like this make it into the LTS images and then don't get a clear timeline or priority for getting fixed.

it seems the fix is in proposed according to this page: https://launchpad.net/ubuntu/+source/linux. But when I enable the proposed repository the version there is old, so the version on that page must just be the source version, but the package hasn't actually been put in the repo?

Clearly I don't understand how this proposed/update/release process works. I'd love to be able to install this from proposed and bake my own base AMI.

I'm going to find time to poke in IRC and see if someone can explain this process/stages to me, but regardless I'd love to know a timeline or at least where this sits in terms of priorities to be released (be it in proposed or preferably updates).

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

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

  [ Kamal Mostafa ]

  * CVE-2016-1583 (LP: #1588871)
    - ecryptfs: fix handling of directory opening
    - SAUCE: proc: prevent stacking filesystems on top
    - SAUCE: ecryptfs: forbid opening files without mmap handler
    - SAUCE: sched: panic on corrupted stack end

  * arm64: statically link rtc-efi (LP: #1583738)
    - [Config] Link rtc-efi statically on arm64

 -- Kamal Mostafa <email address hidden> Fri, 03 Jun 2016 10:02:16 -0700