This bug was fixed in the package linux - 4.15.0-42.45
---------------
linux (4.15.0-42.45) bionic; urgency=medium
* linux: 4.15.0-42.45 -proposed tracker (LP: #1803592)
* [FEAT] Guest-dedicated Crypto Adapters (LP: #1787405)
- KVM: s390: reset crypto attributes for all vcpus
- KVM: s390: vsie: simulate VCPU SIE entry/exit
- KVM: s390: introduce and use KVM_REQ_VSIE_RESTART
- KVM: s390: refactor crypto initialization
- s390: vfio-ap: base implementation of VFIO AP device driver
- s390: vfio-ap: register matrix device with VFIO mdev framework
- s390: vfio-ap: sysfs interfaces to configure adapters
- s390: vfio-ap: sysfs interfaces to configure domains
- s390: vfio-ap: sysfs interfaces to configure control domains
- s390: vfio-ap: sysfs interface to view matrix mdev matrix
- KVM: s390: interface to clear CRYCB masks
- s390: vfio-ap: implement mediated device open callback
- s390: vfio-ap: implement VFIO_DEVICE_GET_INFO ioctl
- s390: vfio-ap: zeroize the AP queues
- s390: vfio-ap: implement VFIO_DEVICE_RESET ioctl
- KVM: s390: Clear Crypto Control Block when using vSIE
- KVM: s390: vsie: Do the CRYCB validation first
- KVM: s390: vsie: Make use of CRYCB FORMAT2 clear
- KVM: s390: vsie: Allow CRYCB FORMAT-2
- KVM: s390: vsie: allow CRYCB FORMAT-1
- KVM: s390: vsie: allow CRYCB FORMAT-0
- KVM: s390: vsie: allow guest FORMAT-0 CRYCB on host FORMAT-1
- KVM: s390: vsie: allow guest FORMAT-1 CRYCB on host FORMAT-2
- KVM: s390: vsie: allow guest FORMAT-0 CRYCB on host FORMAT-2
- KVM: s390: device attrs to enable/disable AP interpretation
- KVM: s390: CPU model support for AP virtualization
- s390: doc: detailed specifications for AP virtualization
- KVM: s390: fix locking for crypto setting error path
- KVM: s390: Tracing APCB changes
- s390: vfio-ap: setup APCB mask using KVM dedicated function
- s390/zcrypt: Add ZAPQ inline function.
- s390/zcrypt: Review inline assembler constraints.
- s390/zcrypt: Integrate ap_asm.h into include/asm/ap.h.
- s390/zcrypt: fix ap_instructions_available() returncodes
- s390/zcrypt: remove VLA usage from the AP bus
- s390/zcrypt: Remove deprecated ioctls.
- s390/zcrypt: Remove deprecated zcrypt proc interface.
- s390/zcrypt: Support up to 256 crypto adapters.
- [Config:] Enable CONFIG_S390_AP_IOMMU and set CONFIG_VFIO_AP to module.
* Bypass of mount visibility through userns + mount propagation (LP: #1789161)
- mount: Retest MNT_LOCKED in do_umount
- mount: Don't allow copying MNT_UNBINDABLE|MNT_LOCKED mounts
* CVE-2018-18955: nested user namespaces with more than five extents
incorrectly grant privileges over inode (LP: #1801924) // CVE-2018-18955
- userns: also map extents in the reverse map to kernel IDs
* kdump fail due to an IRQ storm (LP: #1797990)
- SAUCE: x86/PCI: Export find_cap() to be used in early PCI code
- SAUCE: x86/quirks: Add parameter to clear MSIs early on boot
- SAUCE: x86/quirks: Scan all busses for early PCI quirks
-- Thadeu Lima de Souza Cascardo <casca...@canonical.com> Thu, 15 Nov
2018 17:01:46 -0200
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1784501
Title:
libvirtd is unable to configure bridge devices inside of LXD
containers
Status in linux package in Ubuntu:
Fix Released
Status in linux source package in Bionic:
Fix Released
Bug description:
[Impact]
libvirtd cannot properly configure the default bridge device when
installed inside of unprivileged LXD containers. 'systemctl status
libvirtd' shows the following error:
error : virNetDevBridgeSet:140 : Unable to set bridge virbr0
forward_delay: Permission denied
This is caused due to the files under /sys/class/net/ being owned by
init namespace root rather than container root even when the bridge
device is created inside of the container. Here's an example from
inside of an unprivileged container:
# brctl addbr testbr0
# ls -al /sys/class/net/testbr0/bridge/forward_delay
-rw-r--r-- 1 nobody nogroup 4096 Jul 30 22:33
/sys/class/net/testbr0/bridge/forward_delay
libvirt cannot open this file for writing even though it created the
device. Where safe, files under /sys/class/net/ should be owned by
container root.
[Test Case]
A simple kernel test is to verify that you can write to the
/sys/class/net/<BRIDGE>/ files as root inside of an unprivileged LXD
container.
Unpatched kernels will see a Permission denied error:
$ lxc exec c1 -- sh -c 'brctl addbr testbr && \
echo 1 > /sys/class/net/testbr/bridge/flush'
sh: 1: cannot create /sys/class/net/testbr/bridge/flush: Permission denied
The echo command will succeed when using a patched kernel.
You can also install libvirt inside of a an unprivileged LXD
container, restart the container, and verify that the default bridge
(virbr0) is up.
Unpatched kernels will not see the virbr0 bridge:
$ lxc exec c1 -- sh -c 'brctl show virbr0'
bridge name bridge id STP enabled interfaces
virbr0 can't get info No such device
The brctl command will show a valid device when using a patched kerne:
$ lxc exec c1 -- sh -c 'brctl show virbr0'
bridge name bridge id STP enabled interfaces
virbr0 8000.5254005451e8 yes virbr0-nic
[Regression Potential]
The biggest concern with these patches is that they could cause a
sensitive /sys/class/net/** file to be read from or written to inside
of an unprivileged container. I've (tyhicks) audited all on the in-
tree objects exposed to unprivileged containers by this patch set and
I don't see any concerns. I did find one file (tx_maxrate) that I
couldn't make heads or tails of so I added a CAP_NET_ADMIN check
against the init namespace so that it couldn't be modified inside of a
container.
These patches were released in 4.19 and also in the Ubuntu 18.10
release kernel. No issues have been reported in those releases.
[Other info]
The following upstream patches have been merged into linux-next which
fix this bug:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=c59e18b876da3e466abe5fa066aa69050f5be17c
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=d1753390274f7760e5b593cb657ea34f0617e559
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1784501/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
