Ubuntu

Ubuntu 20.10 'Groovy Gorilla'

Ubuntu 20.10 'Groovy Gorilla'

The Ubuntu 20.10 'Groovy Gorilla' reached end of service life on Jul 22, 2021 — Ubuntu no longer ships security patches or fixes for it. Our third-party support keeps it safe to run: 24/7 engineers manage issues, remediate vulnerabilities, and help you maintain compliance.

End of Service LifeEOSL Date: Jul 22, 2021
Issue Management

24/7 engineers own your Ubuntu 20.10 'Groovy Gorilla' incidents end to end.

Vulnerability Remediation

Mitigation and patch-around guidance when the vendor no longer ships fixes.

Compliance Maintenance

Controls evidence and documentation that keep auditors satisfied.

Specifications

product
ubuntu
release
20.10
product Label
Ubuntu
release Label
20.10 'Groovy Gorilla'
codename
Groovy Gorilla
lts
latest Version
20.10
release Date
2020-10-22
maintained
source Url
https://endoflife.date/ubuntu

Lifecycle Dates

End of Service Life
Jul 22, 2021
Last OEM Support
Jul 22, 2021

Get Third Party Support

Your quote will be sent to this address.

By submitting this form, you agree to our Privacy Policy.

OEM vs. 3rd Party Support

See how third-party support compares to the vendor contract for Ubuntu 20.10 'Groovy Gorilla' — monitoring, break/fix, vulnerability work, operations and compliance, before and after EOSL.

FeatureOEM Support3rd Party Support
Post-EOSL Support
Break/Fix Support
Until EOSL
24/7 Monitoring
Vulnerability Scanning & Remediation
Managed Operations
Procedure & Configuration Review
Compliance & Audit Documentation
Limited
Discounted Migration to Other Platforms

Why Choose 3rd Party Support for Ubuntu 20.10 'Groovy Gorilla'?

Vulnerability Remediation

Scanning, mitigation and patch-around guidance for Ubuntu 20.10 'Groovy Gorilla' when the vendor no longer ships fixes.

Compliance Maintenance

Procedure review, controls evidence and the documentation auditors ask for — maintained continuously, not scrambled at audit time.

24/7 Expert Support

Engineers who know this release monitor, manage and fix issues around the clock — break/fix to managed operations.

Ubuntu 20.10 'Groovy Gorilla' Support: Frequently Asked Questions

Is the Ubuntu 20.10 'Groovy Gorilla' still supported?

Ubuntu ended support for the Ubuntu 20.10 'Groovy Gorilla' on Jul 22, 2021 — no more patches or fixes from the vendor. Third-party support keeps it covered: our engineers manage issues, remediate vulnerabilities, and help you maintain compliance for as long as you run it.

When is the Ubuntu 20.10 'Groovy Gorilla' end of service life (EOSL) date?

Ubuntu lists the end of service life for the Ubuntu 20.10 'Groovy Gorilla' as Jul 22, 2021.

Can I keep using the Ubuntu 20.10 'Groovy Gorilla' after its EOSL date?

Yes. EOSL means Ubuntu stops issuing patches and support — the software itself keeps running. Third-party support covers it from there: issue management, security vulnerability remediation, and the compliance documentation auditors ask for, for as long as you choose to run it.

How much does third-party support for the Ubuntu 20.10 'Groovy Gorilla' cost?

Typically 40-70% below the OEM maintenance renewal price. Exact pricing depends on quantity, service level and location — request a quote and we respond within 24 hours.

Known Vulnerabilities Affecting Ubuntu 20.10 'Groovy Gorilla'

21 published CVEs affect the Ubuntu 20.10 'Groovy Gorilla', including 16 rated critical or high severity. Ubuntu no longer ships security patches for this release — our engineers provide mitigation guidance, workarounds and hardening support.

CVESeverityCVSSPublishedSummary
CVE-2020-27352CRITICAL9.3Jun 21, 2024When generating the systemd service units for the docker snap (and other similar snaps), snapd does not specify Delegate=yes - as a result systemd will move processes from the containers created and managed by these snaps into the cgroup of the main daemon within the snap itself when reloading system units. This may grant additional privileges to a container within the snap that were not originally intended.
CVE-2026-31431HIGH7.8Apr 22, 2026In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead - Revert to operating out-of-place This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.
CVE-2021-3491HIGH7.8Jun 4, 2021The io_uring subsystem in the Linux kernel allowed the MAX_RW_COUNT limit to be bypassed in the PROVIDE_BUFFERS operation, which led to negative values being usedin mem_rw when reading /proc/<PID>/mem. This could be used to create a heap overflow leading to arbitrary code execution in the kernel. It was addressed via commit d1f82808877b ("io_uring: truncate lengths larger than MAX_RW_COUNT on provide buffers") (v5.13-rc1) and backported to the stable kernels in v5.12.4, v5.11.21, and v5.10.37. I
CVE-2021-3490HIGH7.8Jun 4, 2021The eBPF ALU32 bounds tracking for bitwise ops (AND, OR and XOR) in the Linux kernel did not properly update 32-bit bounds, which could be turned into out of bounds reads and writes in the Linux kernel and therefore, arbitrary code execution. This issue was fixed via commit 049c4e13714e ("bpf: Fix alu32 const subreg bound tracking on bitwise operations") (v5.13-rc4) and backported to the stable kernels in v5.12.4, v5.11.21, and v5.10.37. The AND/OR issues were introduced by commit 3f50f132d840 (
CVE-2021-3489HIGH7.8Jun 4, 2021The eBPF RINGBUF bpf_ringbuf_reserve() function in the Linux kernel did not check that the allocated size was smaller than the ringbuf size, allowing an attacker to perform out-of-bounds writes within the kernel and therefore, arbitrary code execution. This issue was fixed via commit 4b81ccebaeee ("bpf, ringbuf: Deny reserve of buffers larger than ringbuf") (v5.13-rc4) and backported to the stable kernels in v5.12.4, v5.11.21, and v5.10.37. It was introduced via 457f44363a88 ("bpf: Implement BPF
CVE-2022-20698HIGH7.5Jan 14, 2022A vulnerability in the OOXML parsing module in Clam AntiVirus (ClamAV) Software version 0.104.1 and LTS version 0.103.4 and prior versions could allow an unauthenticated, remote attacker to cause a denial of service condition on an affected device. The vulnerability is due to improper checks that may result in an invalid pointer read. An attacker could exploit this vulnerability by sending a crafted OOXML file to an affected device. An exploit could allow the attacker to cause the ClamAV scannin
CVE-2020-15078HIGH7.5Apr 26, 2021OpenVPN 2.5.1 and earlier versions allows a remote attackers to bypass authentication and access control channel data on servers configured with deferred authentication, which can be used to potentially trigger further information leaks.
CVE-2021-32555HIGH7.3Jun 12, 2021It was discovered that read_file() in apport/hookutils.py would follow symbolic links or open FIFOs. When this function is used by the xorg-hwe-18.04 package apport hooks, it could expose private data to other local users.
CVE-2021-32554HIGH7.3Jun 12, 2021It was discovered that read_file() in apport/hookutils.py would follow symbolic links or open FIFOs. When this function is used by the xorg package apport hooks, it could expose private data to other local users.
CVE-2021-32553HIGH7.3Jun 12, 2021It was discovered that read_file() in apport/hookutils.py would follow symbolic links or open FIFOs. When this function is used by the openjdk-17 package apport hooks, it could expose private data to other local users.
CVE-2021-32552HIGH7.3Jun 12, 2021It was discovered that read_file() in apport/hookutils.py would follow symbolic links or open FIFOs. When this function is used by the openjdk-16 package apport hooks, it could expose private data to other local users.
CVE-2021-32551HIGH7.3Jun 12, 2021It was discovered that read_file() in apport/hookutils.py would follow symbolic links or open FIFOs. When this function is used by the openjdk-15 package apport hooks, it could expose private data to other local users.
CVE-2021-32550HIGH7.3Jun 12, 2021It was discovered that read_file() in apport/hookutils.py would follow symbolic links or open FIFOs. When this function is used by the openjdk-14 package apport hooks, it could expose private data to other local users.
CVE-2021-32549HIGH7.3Jun 12, 2021It was discovered that read_file() in apport/hookutils.py would follow symbolic links or open FIFOs. When this function is used by the openjdk-13 package apport hooks, it could expose private data to other local users.
CVE-2021-32548HIGH7.3Jun 12, 2021It was discovered that read_file() in apport/hookutils.py would follow symbolic links or open FIFOs. When this function is used by the openjdk-8 package apport hooks, it could expose private data to other local users.
CVE-2021-32547HIGH7.3Jun 12, 2021It was discovered that read_file() in apport/hookutils.py would follow symbolic links or open FIFOs. When this function is used by the openjdk-lts package apport hooks, it could expose private data to other local users.
CVE-2020-29385MEDIUM5.5Dec 26, 2020GNOME gdk-pixbuf (aka GdkPixbuf) before 2.42.2 allows a denial of service (infinite loop) in lzw.c in the function write_indexes. if c->self_code equals 10, self->code_table[10].extends will assign the value 11 to c. The next execution in the loop will assign self->code_table[11].extends to c, which will give the value of 10. This will make the loop run infinitely. This bug can, for example, be triggered by calling this function with a GIF image with LZW compression that is crafted in a special
CVE-2020-27349MEDIUM5.5Dec 9, 2020Aptdaemon performed policykit checks after interacting with potentially untrusted files with elevated privileges. This affected versions prior to 1.1.1+bzr982-0ubuntu34.1, 1.1.1+bzr982-0ubuntu32.3, 1.1.1+bzr982-0ubuntu19.5, 1.1.1+bzr982-0ubuntu14.5.
CVE-2023-5536MEDIUM5.0Dec 12, 2023A feature in LXD (LP#1829071), affects the default configuration of Ubuntu Server which allows privileged users in the lxd group to escalate their privilege to root without requiring a sudo password.
CVE-2020-16123MEDIUM4.4Dec 4, 2020An Ubuntu-specific patch in PulseAudio created a race condition where the snap policy module would fail to identify a client connection from a snap as coming from a snap if SCM_CREDENTIALS were missing, allowing the snap to connect to PulseAudio without proper confinement. This could be exploited by an attacker to expose sensitive information. Fixed in 1:13.99.3-1ubuntu2, 1:13.99.2-1ubuntu2.1, 1:13.99.1-1ubuntu3.8, 1:11.1-1ubuntu7.11, and 1:8.0-0ubuntu3.15.

Showing the 20 most severe of 21 known CVEs.

Get Third Party Support

Related Ubuntu Products

All Ubuntu products →
Ubuntu 20.10 'Groovy Gorilla'
Save 40-70% vs OEM
Get Third Party Support