Bypass of mount visibility through userns + mount propagation

Bug #1789161 reported by Stéphane Graber
272
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Fix Released
High
Unassigned
Trusty
Fix Released
Undecided
Unassigned
Xenial
Fix Released
Undecided
Unassigned
Bionic
Fix Released
Undecided
Unassigned
Cosmic
Fix Released
Undecided
Unassigned
Disco
Fix Released
High
Unassigned

Bug Description

[Impact]

Jonathan Calmels from NVIDIA reported that he's able to bypass the mount visibility security check in place in the Linux kernel by using a combination of the unbindable property along with the private mount propagation option to allow a unprivileged user to see a path which was purposefully hidden by the root user.

[Test Case]

Reproducer:
# Hide a path to all users using a tmpfs
root@castiana:~# mount -t tmpfs tmpfs /sys/devices/
root@castiana:~#

# As an unprivileged user, unshare user namespace and mount namespace
stgraber@castiana:~$ unshare -U -m -r

# Confirm the path is still not accessible
root@castiana:~# ls /sys/devices/

# Make /sys recursively unbindable and private
root@castiana:~# mount --make-runbindable /sys
root@castiana:~# mount --make-private /sys

# Recursively bind-mount the rest of /sys over to /mnnt
root@castiana:~# mount --rbind /sys/ /mnt

# Access our hidden /sys/device as an unprivileged user
root@castiana:~# ls /mnt/devices/
breakpoint cpu cstate_core cstate_pkg i915 intel_pt isa kprobe LNXSYSTM:00 msr pci0000:00 platform pnp0 power software system tracepoint uncore_arb uncore_cbox_0 uncore_cbox_1 uprobe virtual

[Regression Potential]

Low. The fixes are relatively simple. Regressions would most likely be specific to software utilizing user namespaces + mount propagation which is a small (but often important) portion of the Ubuntu archive.

Revision history for this message
Stéphane Graber (stgraber) wrote :

I've reproduced this on Ubuntu 4.15 but Jonathan reported being able to use this flaw on a variety of kernels.

Note that fixing this issue, as was fixing the initial mount visibility issue will come at the cost of some userspace breakages where they effectively rely on this bug.

It's my understanding that Jonathan's own software is currently relying on this bug and will need to switch to an alternative/proper way of dealing with this.

Revision history for this message
Stéphane Graber (stgraber) wrote :

This was discussed in person between Jonathan Calmels (NVIDIA), Aleksa Sarai (SUSE), Christian and I (Canonical). Also including Eric Biederman to this bug as he wrote the mount visibility check.

Revision history for this message
Aleksa Sarai (cyphar) wrote :

> I've reproduced this on Ubuntu 4.15 but Jonathan reported being able to use this flaw on a variety of kernels.

I've also reproduced this on openSUSE Tumbleweed with 4.18. I imagine this is probably a semantic oversight that has been around since the introduction of MS_UNBINDABLE.

Revision history for this message
Christian Brauner (cbrauner) wrote : Re: [Bug 1789161] Re: Bypass of mount visibility through userns + mount propagation

> Bug description:
> Jonathan Calmels from NVIDIA reported that he's able to bypass the
> mount visibility security check in place in the Linux kernel by using
> a combination of the unbindable property along with the private mount
> propagation option to allow a unprivileged user to see a path which
> was purposefully hidden by the root user.

So what we think happens is that copy_tree() simply skips unbindable mounts.

   for (s = r; s; s = next_mnt(s, r)) {
   if (!(flag & CL_COPY_UNBINDABLE) &&
       IS_MNT_UNBINDABLE(s)) {
    s = skip_mnt_tree(s);
    continue;
   }

The solution that just quickly springs to my mind - and I might be
totally wrong - is to not skip unbindable mounts when MNT_LOCKED is set.

>
> Reproducer:
> # Hide a path to all users using a tmpfs
> root@castiana:~# mount -t tmpfs tmpfs /sys/devices/
> root@castiana:~#
>
> # As an unprivileged user, unshare user namespace and mount namespace
> stgraber@castiana:~$ unshare -U -m -r
>
> # Confirm the path is still not accessible
> root@castiana:~# ls /sys/devices/
>
> # Make /sys recursively unbindable and private
> root@castiana:~# mount --make-runbindable /sys
> root@castiana:~# mount --make-private /sys
>
> # Recursively bind-mount the rest of /sys over to /mnnt
> root@castiana:~# mount --rbind /sys/ /mnt
>
> # Access our hidden /sys/device as an unprivileged user
> root@castiana:~# ls /mnt/devices/
> breakpoint cpu cstate_core cstate_pkg i915 intel_pt isa kprobe LNXSYSTM:00 msr pci0000:00 platform pnp0 power software system tracepoint uncore_arb uncore_cbox_0 uncore_cbox_1 uprobe virtual
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1789161/+subscriptions

Revision history for this message
Christian Brauner (cbrauner) wrote :

Or just fail if there are any unbindable children. But let's see what Eric thinks.

Revision history for this message
Eric W. Biederman (ebiederm) wrote :

Christian Brauner <email address hidden> writes:

> Or just fail if there are any unbindable children. But let's see what

My thought is to do the work when mount unbindable is being set:
(a) If the setter has enough permissions to umount the mount in
    question the clear MNT_LOCKED and set MNT_UNBINDABLE

(b) If the setter does not have enough permissions to clear MNT_LOCKED
    than fail to set MNT_UNBINDABLE.

(-) I think only the second case applies as except for mount
     propagation I don't think there is a way to clear MNT_LOCKED.

This needs to happen in public with plenty of exposure as this is a very
minor issue and there is the potential to break userspace. Who knows
what bits of userspace we might break.

I actually don't expect any but we need to be careful and probably take
the full development cycle to get this in. Just so that we are certain
there is plenty of time for people to test and let us know if someone's
configuration breaks.

Eric

Revision history for this message
Christian Brauner (cbrauner) wrote :

On Mon, Aug 27, 2018, 13:00 Eric W. Biederman <email address hidden> wrote:

> Christian Brauner <email address hidden> writes:
>
> > Or just fail if there are any unbindable children. But let's see what
>
> My thought is to do the work when mount unbindable is being set:
> (a) If the setter has enough permissions to umount the mount in
> question the clear MNT_LOCKED and set MNT_UNBINDABLE
>
> (b) If the setter does not have enough permissions to clear MNT_LOCKED
> than fail to set MNT_UNBINDABLE.
>
> (-) I think only the second case applies as except for mount
> propagation I don't think there is a way to clear MNT_LOCKED.
>
> This needs to happen in public with plenty of exposure as this is a very
> minor issue and there is the potential to break userspace. Who knows
> what bits of userspace we might break.
>
> I actually don't expect any but we need to be careful and probably take
> the full development cycle to get this in. Just so that we are certain
>

Are you taking this or should I?

Christian

there is plenty of time for people to test and let us know if someone's
> configuration breaks.
>
> Eric
>

Revision history for this message
Aleksa Sarai (cyphar) wrote :

This is my proposed fix for this, which disallows you from doing a mount
--rbind of something that has MNT_LOCKED|MNT_UNBINDABLE set (I'm at a
conference so I've only compile-tested it so far -- I will try a test kernel in
a bit when my build finishes).

Obviously you're the expert here Eric, but I'm not sure that making
mount(MS_UNBINDABLE) fail is going to be less of a breakage than making rbind
fail if you are trying to rbind something that is *both* MNT_LOCKED and
MNT_UNBINDABLE. This also means that if the host does something like:

  % mount -t tmpfs tmpfs /proc/scsi
  % mount --make-unbindable /proc/scsi

Then this would be exploitable again (or if the set the entirety of /proc to be
runbindable, then a container could set /proc to private which would allow the
same exploit). Maybe this isn't a real issue though, I don't know.

From my reading of do_loopback, I got the (possibly mistaken) impression this
was an oversight of how copy_tree handles MNT_UNBINDABLE, and so it seems to me
that this is the natural place to fix it. But that's just my $0.02 and I'm sure
you definitely know more about this than me.

Revision history for this message
Aleksa Sarai (cyphar) wrote :

Sorry, that patch won't fully fix the issue. If you had something like "/a/b/c" with "/a/b/c" as MNT_LOCKED then the attacker could rbind "/a/b" over "/a/b" and then make "/a/b" MS_UNBINDABLE -- which would be permitted (no single mount has MNT_LOCKED|MS_UNBINDABLE) but as an end result "/a" would be bindmounted without the "/a/b/c" mask.

Given that `mount --bind /something_unbindable /x` fails, I think that `mount --rbind /something_containing_an_unbindable_mount /x` should also fail -- irrespective of MNT_LOCKED (but I imagine -- since this is more drastic -- it might also be more contentious). I'll attach the corrected patch once I've tested it.

Revision history for this message
Aleksa Sarai (cyphar) wrote :

Here's the working patch I have (it took me so long to test it because I hit
some sort of 4.18 kernel regression in mainline that made it not possible for
me to boot -- I'm going to go and bisect what's going on there now).

Revision history for this message
Aleksa Sarai (cyphar) wrote :

Eric, did you have a chance to take a look at the above patchset? The Suggested-by lines were wrong, so attached is the same patch with an updated description.

Revision history for this message
Christian Brauner (cbrauner) wrote :

Adding Serge.

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

Has there been any discussion about this bug in other venues?

Are you talking about it at plumbers this week?

Revision history for this message
Eric W. Biederman (ebiederm) wrote :

Apologies all for sitting on this so long. I got slammed around last merge window dropped the ball on a lot of things and I have been slowly working my way through everything and trying to catch up.

Testing for MNT_UNBINDABLE in do_loopback and then failing the copy if it is set anywhere completely breaks the point of MNT_UNBINDABLE and won't work.

Similarly my original idea of not allowing MNT_UNBINDABLE and MNT_LOCKED on the same mount gets very complicated, especially in the case of pivot_root. MNT_UNBINDABLE and MNT_LOCKED are much easier to manage as indepedent flags.

But it turned out handling this in copy_tree is straight forward so I have implemented the check there.

I intend to post this all shortly once I get a little more testing in and figure out the best route for getting these fixes in. The merge window while code is being merged tends to be a bad time for code review unfortunately.

Revision history for this message
Christian Brauner (cbrauner) wrote :
Tyler Hicks (tyhicks)
description: updated
description: updated
Tyler Hicks (tyhicks)
information type: Private Security → Public Security
tags: added: patch
Changed in linux (Ubuntu Trusty):
status: New → Fix Committed
Changed in linux (Ubuntu Xenial):
status: New → Fix Committed
Changed in linux (Ubuntu Cosmic):
status: New → Fix Committed
Changed in linux (Ubuntu Disco):
status: Triaged → Fix Committed
Changed in linux (Ubuntu Bionic):
status: New → Fix Committed
Revision history for this message
Brad Figg (brad-figg) 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-cosmic' to 'verification-done-cosmic'. If the problem still exists, change the tag 'verification-needed-cosmic' to 'verification-failed-cosmic'.

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-cosmic
Revision history for this message
Brad Figg (brad-figg) 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 the problem still exists, change the tag 'verification-needed-xenial' to 'verification-failed-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-needed-trusty
Revision history for this message
Brad Figg (brad-figg) 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-trusty' to 'verification-done-trusty'. If the problem still exists, change the tag 'verification-needed-trusty' to 'verification-failed-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!

Revision history for this message
Brad Figg (brad-figg) 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-bionic' to 'verification-done-bionic'. If the problem still exists, change the tag 'verification-needed-bionic' to 'verification-failed-bionic'.

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-bionic
tags: added: verification-done-bionic verification-done-cosmic verification-done-trusty verification-done-xenial
removed: verification-needed-bionic verification-needed-cosmic verification-needed-trusty verification-needed-xenial
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

---------------
linux (3.13.0-163.213) trusty; urgency=medium

  * linux: 3.13.0-163.213 -proposed tracker (LP: #1802769)

  * 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

  * dev test in ubuntu_stress_smoke_test cause kernel oops on T-3.13
    (LP: #1797546)
    - drm: fix NULL pointer access by wrong ioctl

  * Packaging resync (LP: #1786013)
    - [Package] add support for specifying the primary makefile

 -- Thadeu Lima de Souza Cascardo <email address hidden> Tue, 13 Nov 2018 13:30:30 -0200

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

This bug was fixed in the package linux - 4.18.0-12.13

---------------
linux (4.18.0-12.13) cosmic; urgency=medium

  * linux: 4.18.0-12.13 -proposed tracker (LP: #1802743)

  * [FEAT] Guest-dedicated Crypto Adapters (LP: #1787405)
    - 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
    - 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
    - [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

  * crash in ENA driver on removing an interface (LP: #1802341)
    - SAUCE: net: ena: fix crash during ena_remove()

  * Ubuntu 18.04.1 - [s390x] Kernel panic while stressing network bonding
    (LP: #1797367)
    - s390/qeth: reduce hard-coded access to ccw channels
    - s390/qeth: sanitize strings in debug messages

  * Add checksum offload and T...

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

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 <email address hidden> Thu, 15 Nov 2018 17:01:46 ...

Read more...

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

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

---------------
linux (4.4.0-140.166) xenial; urgency=medium

  * linux: 4.4.0-140.166 -proposed tracker (LP: #1802776)

  * 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

  * 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

  * crash in ENA driver on removing an interface (LP: #1802341)
    - SAUCE: net: ena: fix crash during ena_remove()

  * xenial guest on arm64 drops to busybox under openstack bionic-rocky
    (LP: #1797092)
    - [Config] CONFIG_PCI_ECAM=y
    - PCI: Provide common functions for ECAM mapping
    - PCI: generic, thunder: Use generic ECAM API
    - PCI, of: Move PCI I/O space management to PCI core code
    - PCI: Move ecam.h to linux/include/pci-ecam.h
    - PCI: Add parent device field to ECAM struct pci_config_window
    - PCI: Add pci_unmap_iospace() to unmap I/O resources
    - PCI/ACPI: Support I/O resources when parsing host bridge resources
    - [Config] CONFIG_ACPI_MCFG=y
    - PCI/ACPI: Add generic MCFG table handling
    - PCI: Refactor pci_bus_assign_domain_nr() for CONFIG_PCI_DOMAINS_GENERIC
    - PCI: Factor DT-specific pci_bus_find_domain_nr() code out
    - ARM64: PCI: Add acpi_pci_bus_find_domain_nr()
    - ARM64: PCI: ACPI support for legacy IRQs parsing and consolidation with DT
      code
    - ARM64: PCI: Support ACPI-based PCI host controller

  * [GLK/CLX] Enhanced IBRS (LP: #1786139)
    - x86/speculation: Remove SPECTRE_V2_IBRS in enum spectre_v2_mitigation
    - x86/speculation: Support Enhanced IBRS on future CPUs

  * Update ENA driver to version 2.0.1K (LP: #1798182)
    - net: ena: remove ndo_poll_controller
    - net: ena: fix warning in rmmod caused by double iounmap
    - net: ena: fix rare bug when failed restart/resume is followed by driver
      removal
    - net: ena: fix NULL dereference due to untimely napi initialization
    - net: ena: fix auto casting to boolean
    - net: ena: minor performance improvement
    - net: ena: complete host info to match latest ENA spec
    - net: ena: introduce Low Latency Queues data structures according to ENA spec
    - net: ena: add functions for handling Low Latency Queues in ena_com
    - net: ena: add functions for handling Low Latency Queues in ena_netdev
    - net: ena: use CSUM_CHECKED device indication to report skb's checksum status
    - net: ena: explicit casting and initialization, and clearer error handling
    - net: ena: limit refill Rx threshold to 256 to avoid latency issues
    - net: ena: change rx copybreak default to reduce kernel memory pressure
    - net: ena: remove redundant parameter in ena_com_admin_init()
    - net: ena: update driver version to 2.0.1
    - net: ena: fix indentations in ena_defs for better readability
    - net: ena: Fix Kconfig dependency on X86
    - net: ena: enable Low Latency Queues
    - net: ena: fix compilat...

Read more...

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

This bug was fixed in the package linux - 4.19.0-12.13

---------------
linux (4.19.0-12.13) disco; urgency=medium

  * linux: 4.19.0-12.13 -proposed tracker (LP: #1813664)

  * kernel oops in bcache module (LP: #1793901)
    - SAUCE: bcache: never writeback a discard operation

  * Disco update: 4.19.18 upstream stable release (LP: #1813611)
    - ipv6: Consider sk_bound_dev_if when binding a socket to a v4 mapped address
    - mlxsw: spectrum: Disable lag port TX before removing it
    - mlxsw: spectrum_switchdev: Set PVID correctly during VLAN deletion
    - net: dsa: mv88x6xxx: mv88e6390 errata
    - net, skbuff: do not prefer skb allocation fails early
    - qmi_wwan: add MTU default to qmap network interface
    - ipv6: Take rcu_read_lock in __inet6_bind for mapped addresses
    - net: clear skb->tstamp in bridge forwarding path
    - netfilter: ipset: Allow matching on destination MAC address for mac and
      ipmac sets
    - gpio: pl061: Move irq_chip definition inside struct pl061
    - drm/amd/display: Guard against null stream_state in set_crc_source
    - drm/amdkfd: fix interrupt spin lock
    - ixgbe: allow IPsec Tx offload in VEPA mode
    - platform/x86: asus-wmi: Tell the EC the OS will handle the display off
      hotkey
    - e1000e: allow non-monotonic SYSTIM readings
    - usb: typec: tcpm: Do not disconnect link for self powered devices
    - selftests/bpf: enable (uncomment) all tests in test_libbpf.sh
    - of: overlay: add missing of_node_put() after add new node to changeset
    - writeback: don't decrement wb->refcnt if !wb->bdi
    - serial: set suppress_bind_attrs flag only if builtin
    - bpf: Allow narrow loads with offset > 0
    - ALSA: oxfw: add support for APOGEE duet FireWire
    - x86/mce: Fix -Wmissing-prototypes warnings
    - MIPS: SiByte: Enable swiotlb for SWARM, LittleSur and BigSur
    - crypto: ecc - regularize scalar for scalar multiplication
    - arm64: perf: set suppress_bind_attrs flag to true
    - drm/atomic-helper: Complete fake_commit->flip_done potentially earlier
    - clk: meson: meson8b: fix incorrect divider mapping in cpu_scale_table
    - samples: bpf: fix: error handling regarding kprobe_events
    - usb: gadget: udc: renesas_usb3: add a safety connection way for
      forced_b_device
    - fpga: altera-cvp: fix probing for multiple FPGAs on the bus
    - selinux: always allow mounting submounts
    - ASoC: pcm3168a: Don't disable pcm3168a when CONFIG_PM defined
    - scsi: qedi: Check for session online before getting iSCSI TLV data.
    - drm/amdgpu: Reorder uvd ring init before uvd resume
    - rxe: IB_WR_REG_MR does not capture MR's iova field
    - efi/libstub: Disable some warnings for x86{,_64}
    - jffs2: Fix use of uninitialized delayed_work, lockdep breakage
    - clk: imx: make mux parent strings const
    - pstore/ram: Do not treat empty buffers as valid
    - media: uvcvideo: Refactor teardown of uvc on USB disconnect
    - powerpc/xmon: Fix invocation inside lock region
    - powerpc/pseries/cpuidle: Fix preempt warning
    - media: firewire: Fix app_info parameter type in avc_ca{,_app}_info
    - ASoC: use dma_ops of parent device for acp_audio_dma
    - media: ve...

Changed in linux (Ubuntu Disco):
status: Fix Committed → Fix Released
Brad Figg (brad-figg)
tags: added: cscc
To post a comment you must log in.
This report contains Public Security information  
Everyone can see this security related information.

Other bug subscribers

Remote bug watches

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