AppArmor profile reloading causes an intermittent kernel BUG

Bug #1579135 reported by Paul Larson
50
This bug affects 11 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Fix Released
Undecided
Unassigned
Xenial
Fix Released
Undecided
Unassigned
Yakkety
Fix Released
Undecided
Unassigned

Bug Description

First, a bit of background: I've built a go binary of the upstream snappy integration tests, and built them into a snap so that we can easily keep them up to date, and call them from other test suites.

I'm running through the tests in qemu on a current 16 image (built yesteray), and hitting this most of the time with the homeInterface Suite tests in particular. The networkInterfaceSuite tests also seem to produce a similar problem:

sudo snap connect home-consumer:home ubuntu-core:home
[/] Connect home-consumer:home to ubuntu-core:home
home-consumer.writer /home/ubuntu/snap/snappy-tests/100001/writable
sudo snap disconnect home-consumer:home ubuntu-core:home
[ 519.416354] BUG: unable to handle kernel NULL pointer dereference at 0000000000000038
[ 519.417327] IP: [<ffffffff81388eef>] profile_cmp+0x2f/0x180
[ 519.417978] PGD 1f26a067 PUD 1aa4f067 PMD 0
[ 519.418574] Oops: 0000 [#1] SMP
[ 519.419032] Modules linked in: kvm_intel joydev kvm ppdev snd_pcm snd_timer irqbypass snd soundcore parport_pc pcspkr input_leds floppy parport evbug psmouse e1000 8250_fintek i2c_piix4 mac_hid pata_acpi serio_raw autofs4 nls_iso8859_1 usb_storage ahci libahci squashfs
[ 519.422747] CPU: 0 PID: 1915 Comm: apparmor_parser Tainted: G W 4.4.0-21-generic #37-Ubuntu
[ 519.423689] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
[ 519.424627] task: ffff88001d23cb00 ti: ffff88001b58c000 task.ti: ffff88001b58c000
[ 519.425385] RIP: 0010:[<ffffffff81388eef>] [<ffffffff81388eef>] profile_cmp+0x2f/0x180
[ 519.426242] RSP: 0018:ffff88001b58fcb0 EFLAGS: 00010086
[ 519.426791] RAX: 0000000000000000 RBX: ffff88001b1b1400 RCX: 0000000000000006
[ 519.427628] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000009
[ 519.428405] RBP: ffff88001b58fcc0 R08: 000000000000000a R09: 0000000000000274
[ 519.429127] R10: ffff88001f236890 R11: 0000000000000274 R12: 0000000000000000
[ 519.429956] R13: 000000000000000b R14: 0000000000000000 R15: ffff88001abff950
[ 519.430957] FS: 00007f0c1609b740(0000) GS:ffff88001fc00000(0000) knlGS:0000000000000000
[ 519.432256] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 519.433030] CR2: 0000000000000038 CR3: 000000001b14b000 CR4: 00000000000006f0
[ 519.433868] Stack:
[ 519.434204] 000000000000000c ffff88001abff9b0 ffff88001b58fd08 ffffffff8138a0c3
[ 519.435355] 000000011f2b9450 ffff88000000000c ffff88001abff950 ffff88001b1b1760
[ 519.436480] ffff88001f236848 ffff88001abff900 ffff88001f236840 ffff88001b58fd98
[ 519.437609] Call Trace:
[ 519.438007] [<ffffffff8138a0c3>] aa_vec_unique+0x163/0x240
[ 519.438709] [<ffffffff8138e337>] __aa_labelset_update_subtree+0x687/0x820
[ 519.439537] [<ffffffff813811fb>] aa_replace_profiles+0x59b/0xb70
[ 519.440268] [<ffffffff811ec5ae>] ? __kmalloc+0x22e/0x250
[ 519.440944] [<ffffffff81375f1f>] policy_update+0x9f/0x1f0
[ 519.441617] [<ffffffff81376083>] profile_replace+0x13/0x20
[ 519.442299] [<ffffffff8120bf38>] __vfs_write+0x18/0x40
[ 519.443032] [<ffffffff8120c8c9>] vfs_write+0xa9/0x1a0
[ 519.443721] [<ffffffff8120b85f>] ? do_sys_open+0x1bf/0x2a0
[ 519.444416] [<ffffffff8120d585>] SyS_write+0x55/0xc0
[ 519.445042] [<ffffffff818244f2>] entry_SYSCALL_64_fastpath+0x16/0x71
[ 519.445802] Code: 00 55 48 85 ff 48 89 e5 41 54 53 49 89 f4 48 89 fb 0f 84 8b 00 00 00 4d 85 e4 0f 84 aa 00 00 00 48 83 7b 38 00 0f 84 c9 00 00 00 <49> 83 7c 24 38 00 0f 84 e8 00 00 00 48 83 7b 08 00 0f 84 07 01
[ 519.451336] RIP [<ffffffff81388eef>] profile_cmp+0x2f/0x180
[ 519.452088] RSP <ffff88001b58fcb0>
[ 519.452570] CR2: 0000000000000038
[ 519.453032] ---[ end trace 65ff12ee2e7c26af ]---

The details of this test can be found at:
https://github.com/ubuntu-core/snappy/tree/master/integration-tests/data/snaps/home-consumer

Will follow up with more details

Revision history for this message
Paul Larson (pwlars) wrote :

Tail end of syslog:
May 6 16:03:58 localhost kernel: [ 595.676922] audit: type=1400 audit(1462550638.144:10477): apparmor="ALLOWED" operation="recvmsg" profile="snap.snappy-tests.snappy-tests//null-/usr/bin/sudo" pid=1908 comm="sudo" family="netlink" sock_type="raw" protocol=9 requested_mask="receive" denied_mask="receive"
May 6 16:03:58 localhost kernel: [ 595.681696] audit: type=1400 audit(1462550638.148:10478): apparmor="ALLOWED" operation="create" profile="snap.snappy-tests.snappy-tests//null-/usr/bin/sudo" pid=1908 comm="sudo" family="netlink" sock_type="raw" protocol=9 requested_mask="create" denied_mask="create"
May 6 16:03:58 localhost kernel: [ 595.686123] audit: type=1400 audit(1462550638.152:10479): apparmor="ALLOWED" operation="sendmsg" profile="snap.snappy-tests.snappy-tests//null-/usr/bin/sudo" pid=1908 comm="sudo" family="netlink" sock_type="raw" protocol=9 requested_mask="send" denied_mask="send"
May 6 16:03:58 localhost kernel: [ 595.690588] audit: type=1400 audit(1462550638.156:10480): apparmor="ALLOWED" operation="recvmsg" profile="snap.snappy-tests.snappy-tests//null-/usr/bin/sudo" pid=1908 comm="sudo" family="netlink" sock_type="raw" protocol=9 requested_mask="receive" denied_mask="receive"
May 6 16:03:58 localhost kernel: [ 595.695250] audit: type=1400 audit(1462550638.164:10481): apparmor="ALLOWED" operation="recvmsg" profile="snap.snappy-tests.snappy-tests//null-/usr/bin/sudo" pid=1908 comm="sudo" family="netlink" sock_type="raw" protocol=9 requested_mask="receive" denied_mask="receive"
May 6 16:07:41 localhost /usr/lib/snapd/snapd[1578]: taskrunner.go:234: DEBUG: Running task 67 on Doing: Disconnect home-consumer:home from ubuntu-core:home
May 6 16:07:41 localhost /usr/lib/snapd/snapd[1578]: task.go:250: DEBUG: 2016-05-06T16:07:41Z ERROR cannot disconnect plug "home" from snap "home-consumer" from slot "home" from snap "ubuntu-core", it is not connected
May 6 16:09:15 localhost systemd[1]: Starting Cleanup of Temporary Directories...
May 6 16:09:15 localhost systemd-tmpfiles[1919]: [/usr/lib/tmpfiles.d/var.conf:14] Duplicate line for path "/var/log", ignoring.
May 6 16:09:15 localhost systemd[1]: Started Cleanup of Temporary Directories.

Revision history for this message
Paul Larson (pwlars) wrote :
Revision history for this message
Paul Larson (pwlars) wrote :
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

It looks like you installed the snap with --devmode. Can you confirm?

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

I cannot reproduce with the following:

$ mkdir /tmp/cache
$ tar -zxvf ./profiles.tgz
$ cd profiles
$ while /bin/true ; do sudo apparmor_parser --replace --write-cache -O no-expr-simplify --cache-loc=/tmp/cache ./* ; done

The above apparmor_parser options are what snapd uses (see interfaces/apparmor/apparmor.go).

$ cat /proc/version_signature
Ubuntu 4.4.0-21.37-generic 4.4.6

Paul, are you able to reproduce this issue when running the above on the system in question? Perhaps you can also include tarballs for /etc/apparmor.d and /etc/apparmor.d/cache?

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

I'm told home-consumer is https://github.com/ubuntu-core/snappy/blob/master/integration-tests/data/snaps/home-consumer/ so reproducing with a snap would be to checkout that branch, run 'snapcraft snap .' then installing the resulting snap (eg, 'sudo snap install /path/to/snap' adding --devmode if want complain mode).

Revision history for this message
John Johansen (jjohansen) wrote :

What kernel (full version) did this occur on?

Revision history for this message
Paul Larson (pwlars) wrote :

Linux localhost.localdomain 4.4.0-21-generic #37-Ubuntu SMP Mon Apr 18 18:33:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Revision history for this message
Paul Larson (pwlars) wrote :

@Jamie: simply building that snap and installing it, and even connecting/disconnecting the slots doesn't seem to reproduce the problem easily. The easiest way I can come up with for reproducing it is to use the snap that I'm using [attached]. To run into the problem I see, install this snap, and run:
snappy-tests -check.f homeInterfaceSuite

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

@Paul, I tried to test this in a snappy VM with:
$ snappy-tests -check.f homeInterfaceSuite
Bad system call

----------------------------------------------------------------------
FAIL: <autogenerated>:46: homeInterfaceSuite.SetUpSuite

/home/plars/work/snappy/snappy-tests/parts/snappy-tests/go/src/github.com/ubuntu-core/snappy/integration-tests/testutils/common/common.go:65:
    ...open /home/plars/work/snappy/snappy-tests/parts/snappy-tests/go/src/github.com/ubuntu-core/snappy/integration-tests/testutils/common/common.go: no such file or directory
... value *os.PathError = &os.PathError{Op:"open", Path:"integration-tests/data/output/testconfig.json", Err:0x2} ("open integration-tests/data/output/testconfig.json: no such file or directory")
... Error reading config: open integration-tests/data/output/testconfig.json: no such file or directory

OOPS: 0 passed, 1 FAILED, 7 MISSED
--- FAIL: Test (0.01s)
FAIL

Let me try to checkout the branch in a desktop VM to reproduce.

Revision history for this message
Jamie Strandboge (jdstrand) wrote :
Download full text (4.7 KiB)

In my first attempt I didn't use --devmode.

However, I can't seem to make the snap work in a xenial amd64 VM.

I tried the original snap with:
$ sudo snap install --devmode ./snappy-tests_0.1_amd64.snap
$ snappy-tests -check.f homeInterfaceSuite
...
... Error reading config: open integration-tests/data/output/testconfig.json: no such file or directory

I then created a new snap with:
$ sudo apt-get install snapcraft
$ sudo unsquashfs /var/lib/snapd/snaps/snappy-tests_100001.snap
$ sudo vi ./squashfs-root/command-snappy-tests.wrapper
adjust to be:
export GOPATH=$SNAP_USER_DATA/go
mkdir "$GOPATH"
$ adjust ./squashfs-root/snap.yaml
adjust version to be: 0.1+jdstrand1
$ sudo snap install --devmode ./snappy-tests_0.1+jdstrand1_amd64.snap
sudo systemctl stop snappy-autopilot.timer
sudo: no tty present and no askpass program specified
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x0 pc=0x53b74f]

goroutine 1 [running]:
panic(0x94a020, 0xc8200100e0)
 /usr/lib/go-1.6/src/runtime/panic.go:464 +0x3e6
gopkg.in/check%2ev1.(*methodType).PC(0x0, 0x5544e6)
 /home/plars/work/snappy/snappy-tests/parts/snappy-tests/go/src/gopkg.in/check.v1/check.go:60 +0x4f
gopkg.in/check%2ev1.(*C).logCaller(0xc8200e61e0, 0x3)
 /home/plars/work/snappy/snappy-tests/parts/snappy-tests/go/src/gopkg.in/check.v1/check.go:284 +0xa1
gopkg.in/check%2ev1.(*C).internalCheck(0xc8200e61e0, 0x9f39b8, 0x6, 0x9cda80, 0xc8201970c0, 0x7feac3fb2568, 0xc820026028, 0xc82004fd88, 0x0, 0x1, ...)
 /home/plars/work/snappy/snappy-tests/parts/snappy-tests/go/src/gopkg.in/check.v1/helpers.go:216 +0xeaf
gopkg.in/check%2ev1.(*C).Assert(0xc8200e61e0, 0x9cda80, 0xc8201970c0, 0x7feac3fb2568, 0xc820026028, 0xc82004fd88, 0x1, 0x1)
 /home/plars/work/snappy/snappy-tests/parts/snappy-tests/go/src/gopkg.in/check.v1/helpers.go:173 +0x8c
github.com/ubuntu-core/snappy/integration-tests/testutils/cli.ExecCommand(0xc8200e61e0, 0xc820013b40, 0x4, 0x4, 0x0, 0x0)
 /home/plars/work/snappy/snappy-tests/parts/snappy-tests/go/src/github.com/ubuntu-core/snappy/integration-tests/testutils/cli/cli.go:42 +0x306
snappy/integration-tests/tests.init.1()
 /home/plars/work/snappy/snappy-tests/parts/snappy-tests/go/src/snappy/integration-tests/tests/base_test.go:55 +0x16d
snappy/integration-tests/tests.init()
 /home/plars/work/snappy/snappy-tests/parts/snappy-tests/go/src/snappy/integration-tests/tests/writablePaths_test.go:107 +0x10c4
main.init()
 snappy/integration-tests/tests/_test/_testmain.go:56 +0x4a

I then tried to build it myself:
$ sudo apt-get install git snapcraft
$ export GOPATH=$HOME/work
$ mkdir $GOPATH
$ export PATH=$PATH:$GOPATH
$ git clone https://github.com/plars/snappy-tests.git
$ cd snappy-tests
$ snapcraft
(this may fail; if it does, keep trying until it succeeds per IRC)
...
$ sudo snap install --devmode ./snappy-tests_0.1_amd64.snap
$ snappy-tests -check.f homeInterfaceSuite
sudo systemctl stop snappy-autopilot.timer
sudo: no tty present and no askpass program specified
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x0 pc=0x531c3f]

goroutine 1 [running]:
panic(0x928e60, 0xc8200100f0)
 /usr/lib/go-1.6/sr...

Read more...

Changed in apparmor (Ubuntu):
status: New → Incomplete
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

Oh, I didn't give all the steps on recreating your snap and running the tests (not sure how that happened). For posterity:

$ sudo apt-get install snapcraft
$ sudo unsquashfs /var/lib/snapd/snaps/snappy-tests_100001.snap # unpack
$ sudo chown -R jamie:jamie ./squashfs-root
$ vi ./squashfs-root/command-snappy-tests.wrapper # fix the wrapper
adjust to be:
export GOPATH=$SNAP_USER_DATA/go
mkdir "$GOPATH"
$ vi ./squashfs-root/snap.yaml # rev the version
adjust version to be: 0.1+jdstrand1
$ snapcraft snap ./squashfs-root # resquash
$ sudo snap remove snappy-tests # just be doubly sure we start from a clean state
$ sudo snap install --devmode ./snappy-tests_0.1+jdstrand1_amd64.snap # install

$ snappy-tests -check.f homeInterfaceSuite

Revision history for this message
Paul Larson (pwlars) wrote :

Strange, I rebuilt the snap today, built a new amd64 snappy image, and ran through all the tests in kvm twice with no crash. Did something go in that could have fixed it?

Revision history for this message
John Johansen (jjohansen) wrote :

No, which means its a race of some kind

Revision history for this message
Paul Larson (pwlars) wrote :

I'll keep running to see if I can reproduce it again.

Revision history for this message
John Johansen (jjohansen) wrote :

I have been unable to trigger this bug can you please provide more information?

Revision history for this message
John Johansen (jjohansen) wrote :

Is the snap removed and then reinstalled?
Has this been triggered just by running the snap?
When was the kernel rebooted since the snap was installed? Since the snap was removed?
...

Revision history for this message
Tyler Hicks (tyhicks) wrote :

Hi Paul - Any chance that you can help with the additional info requested by John? Thanks!

Revision history for this message
Paul Larson (pwlars) wrote :

Unfortunately no, I mentioned earlier that I'm no longer able to reproduce the problem but John said nothing went in that should have fixed it. I'll leave it up to you guys if you'd like to invalidate it or keep it open, but for me it is now unreproducible. :(

Revision history for this message
Michael Vogt (mvo) wrote :

For me it happend today as well. It happend when I upgraded a devmode snap to a new version of a devmode snap (ubuntu-device-flash in particular). It also happend to ogra with the same snap (but a different upgrade path). U-d-f is not using any plugs or slots, just the default policy.

Changed in apparmor (Ubuntu):
status: Incomplete → New
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

@Michael - can you attach the snap of the version you upgraded from as well as to? I suspect the reproducer becomes:

$ sudo snap install --devmode /path/to/previous/udf
$ sudo snap install --devmode /path/to/updated/udf

Do we need to do something like this instead? (not sure what a fetch from the store would matter):
$ sudo snap install ubuntu-device-flash --channel=beta # ie, the previous snap
$ sudo snap install ubuntu-device-flash --channel=edge # ie, the new snap

Michael, can you confirm (one of) the reproducer(s)?

Revision history for this message
Michael Vogt (mvo) wrote :

It seems like its not trivial to reproduce still, I tried:

    # snap remove ubuntu-device-flash || true
    # snap install --beta --devmode ubuntu-device-flash
    # snap refresh --edge --devmode ubuntu-device-flash

which upgrades from r3->r5 (note that its the default profile anyway so it should not matter).
However i can not reproduce it (anymore).

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

Annoying-- it happened to 3 people today but still no reliable reproducer.

Changed in apparmor (Ubuntu):
status: New → Incomplete
Revision history for this message
Michael Vogt (mvo) wrote :

@jdstrand I was able to reproduce it today with the lines in https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1579135/comments/22. And Ondra hit the issue today as well.

Revision history for this message
Michael Vogt (mvo) wrote :

@jdstrand: but it is still not reliable, I tried the above steps in a fresh VM without success (no crashes, no oops).

Revision history for this message
Tyler Hicks (tyhicks) wrote :

Bug #1581990 looks to be the same kernel trace.

Revision history for this message
John Johansen (jjohansen) wrote :

could you try reproducing with the kernel in

http://people.canonical.com/~jj/linux+jj/

Revision history for this message
Tyler Hicks (tyhicks) wrote :

The 14.04 stable release update for apparmor 2.10.95-0ubuntu2.2 is causing a lot of users to hit this oops during the upgrade process due to the upgrade triggering a profile reload.

summary: - kernel BUG on snap disconnect from within a snap
+ AppArmor profile reloading causes an intermittent kernel BUG
Changed in apparmor (Ubuntu):
assignee: nobody → John Johansen (jjohansen)
importance: Undecided → Critical
Revision history for this message
Tyler Hicks (tyhicks) wrote :

John has been working on a fix but could use some testing. Please see comment 27.

Revision history for this message
C de-Avillez (hggdh2) wrote :

ran some 15 profile reloads with JJ's kernel (a mix of reinstalls and restarts), could not reproduce.

Revision history for this message
John Johansen (jjohansen) wrote :

I believe I have finally tracked this one down. It only occurs when an fd is shared between 9 or more separate profile domains and one of those profiles is removed. The removal part can happen during the apparmor reload phase, if a profile was renamed which is more likely on touch and snappy.

Note: there is a new test kernel using +jj61 at http://people.canonical.com/~jj/linux+jj/

This should be the final fix for this issue

Changed in linux (Ubuntu Xenial):
status: New → Fix Committed
Changed in linux (Ubuntu Yakkety):
status: New → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in apparmor (Ubuntu Xenial):
status: New → Confirmed
Revision history for this message
Tim Gardner (timg-tpi) wrote :

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!

tags: added: verification-needed-xenial
tags: added: verification-done-xenial
removed: verification-needed-xenial
Revision history for this message
Gabriel Hege (gabriel-hege) wrote :

I hit this problem in Trusty with kernel "Ubuntu 4.4.0-36.55~14.04.1-generic 4.4.16" and is seems to be fixed with "Ubuntu 4.4.0-38.57~14.04.1-generic 4.4.19" from trusty-proposed.

Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (22.8 KiB)

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

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

  [ Tim Gardner ]

  * Release Tracking Bug
    - LP: #1620658

  * CIFS client: access problems after updating to kernel 4.4.0-29-generic
    (LP: #1612135)
    - Revert "UBUNTU: SAUCE: (namespace) Bypass sget() capability check for nfs"
    - fs: Call d_automount with the filesystems creds

  * apt-key add fails in overlayfs (LP: #1618572)
    - SAUCE: overlayfs: fix regression in whiteout detection

linux (4.4.0-37.56) xenial; urgency=low

  [ Tim Gardner ]

  * Release Tracking Bug
    - LP: #1618040

  * [Feature] Instruction decoder support for new SKX instructions- AVX512
    (LP: #1591655)
    - x86/insn: perf tools: Fix vcvtph2ps instruction decoding
    - x86/insn: Add AVX-512 support to the instruction decoder
    - perf tools: Add AVX-512 support to the instruction decoder used by Intel PT
    - perf tools: Add AVX-512 instructions to the new instructions test

  * [Ubuntu 16.04] FCoE Lun not visible in OS with inbox driver - Issue with
    ioremap() call on 32bit kernel (LP: #1608652)
    - lpfc: Correct issue with ioremap() call on 32bit kernel

  * [Feature] turbostat support for Skylake-SP server (LP: #1591802)
    - tools/power turbostat: decode more CPUID fields
    - tools/power turbostat: CPUID(0x16) leaf shows base, max, and bus frequency
    - tools/power turbostat: decode HWP registers
    - tools/power turbostat: Decode MSR_MISC_PWR_MGMT
    - tools/power turbostat: allow sub-sec intervals
    - tools/power turbostat: Intel Xeon x200: fix erroneous bclk value
    - tools/power turbostat: Intel Xeon x200: fix turbo-ratio decoding
    - tools/power turbostat: re-name "%Busy" field to "Busy%"
    - tools/power turbostat: add --out option for saving output in a file
    - tools/power turbostat: fix compiler warnings
    - tools/power turbostat: make fewer systems calls
    - tools/power turbostat: show IRQs per CPU
    - tools/power turbostat: show GFXMHz
    - tools/power turbostat: show GFX%rc6
    - tools/power turbostat: detect and work around syscall jitter
    - tools/power turbostat: indicate SMX and SGX support
    - tools/power turbostat: call __cpuid() instead of __get_cpuid()
    - tools/power turbostat: correct output for MSR_NHM_SNB_PKG_CST_CFG_CTL dump
    - tools/power turbostat: bugfix: TDP MSRs print bits fixing
    - tools/power turbostat: SGX state should print only if --debug
    - tools/power turbostat: print IRTL MSRs
    - tools/power turbostat: initial BXT support
    - tools/power turbostat: decode BXT TSC frequency via CPUID
    - tools/power turbostat: initial SKX support

  * [BYT] display hotplug doesn't work on console (LP: #1616894)
    - drm/i915/vlv: Make intel_crt_reset() per-encoder
    - drm/i915/vlv: Reset the ADPA in vlv_display_power_well_init()
    - drm/i915/vlv: Disable HPD in valleyview_crt_detect_hotplug()
    - drm/i915: Enable polling when we don't have hpd

  * [Feature]intel_idle enabling on Broxton-P (LP: #1520446)
    - intel_idle: add BXT support

  * [Feature] EDAC: Update driver for SKX-SP (LP: #1591815)
    - [Config] CONFIG_EDAC_SKX=m
    - EDAC, skx_edac: Ad...

Changed in linux (Ubuntu Xenial):
status: Fix Committed → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (3.4 KiB)

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

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

  * change_hat is logging failures during expected hat probing (LP: #1615893)
    - SAUCE: apparmor: Fix auditing behavior for change_hat probing

  * deleted files outside of the namespace are not being treated as
    disconnected
    (LP: #1615892)
    - SAUCE: apparmor: deleted dentries can be disconnected

  * stacking to unconfined in a child namespace confuses mediation
    (LP: #1615890)
    - SAUCE: apparmor: special case unconfined when determining the mode

  * apparmor module parameters can be changed after the policy is locked
    (LP: #1615895)
    - SAUCE: apparmor: fix: parameters can be changed after policy is locked

  * AppArmor profile reloading causes an intermittent kernel BUG (LP:
    #1579135)
    - SAUCE: apparmor: fix vec_unique for vectors larger than 8

  * label vec reductions can result in reference labels instead of direct
    access
    to labels (LP: #1615889)
    - SAUCE: apparmor: reduction of vec to single entry is just that entry

  * profiles from different namespaces can block other namespaces from being
    able to load a profile (LP: #1615887)
    - SAUCE: apparmor: profiles in one ns can affect mediation in another ns

  * The label build for onexec when stacking is wrong (LP: #1615881)
    - SAUCE: apparmor: Fix label build for onexec stacking.

  * The inherit check for new to old label comparison for domain transitions
    is
    wrong (LP: #1615880)
    - SAUCE: apparmor: Fix new to old label comparison for domain transitions

  * warning stack trace while playing with apparmor namespaces (LP: #1593874)
    - SAUCE: apparmor: fix stack trace when removing namespace with profiles

  * __label_update proxy comparison test is wrong (LP: #1615878)
    - SAUCE: apparmor: Fix __label_update proxy comparison test

  * reading /sys/kernel/security/apparmor/profiles requires CAP_MAC_ADMIN
    (LP: #1560583)
    - SAUCE: apparmor: Allow ns_root processes to open profiles file
    - SAUCE: apparmor: Consult sysctl when reading profiles in a user ns

  * policy namespace stacking (LP: #1379535)
    - SAUCE: (no-up) apparmor: rebase of apparmor3.5-beta1 snapshot for 4.8
    - SAUCE: add a sysctl to enable unprivileged user ns AppArmor policy loading

  * Miscellaneous Ubuntu changes
    - [Debian] Dynamically determine linux udebs package name
    - [Debian] d-i -- fix dtb handling in new kernel-wedge form
    - SAUCE: apparmor: Fix FTBFS due to bad include path
    - SAUCE: apparmor: add data query support
    - [Config] Set CONFIG_SECURITY_APPARMOR_UNCONFINED_INIT=y

  * Miscellaneous upstream changes
    - fixup backout policy view capable for forward port
    - apparmor: fix: Rework the iter loop for label_update
    - apparmor: add more assertions for updates/merges to help catch errors
    - apparmor: Make pivot root transitions work with stacking
    - apparmor: convert delegating deleted files to mediate deleted files
    - apparmor: add missing parens. not a bug fix but highly recommended
    - apparmor: add a stack_version file to allow detection of bug fixes
    - apparmor: push path looku...

Read more...

Changed in linux (Ubuntu Yakkety):
status: Fix Committed → Fix Released
Mathew Hodson (mhodson)
no longer affects: apparmor (Ubuntu)
no longer affects: apparmor (Ubuntu Xenial)
no longer affects: apparmor (Ubuntu Yakkety)
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.