In the Linux kernel, vulnerabilities in netfilter, tls, and tty have been resolved.
26f9dfe489d13089790305d8f67825c601335c35926cd154fac7a9ac2ed36d53
Linux kernel vulnerabilities
A security issue affects these releases of Ubuntu and its derivatives:
- Ubuntu 20.04 LTS
- Ubuntu 18.04 LTS
- Ubuntu 16.04 LTS
- Ubuntu 22.04 LTS
- Ubuntu 14.04 LTS
Summary
Several security issues were fixed in the kernel.
Software Description
- linux - Linux kernel
- linux-aws - Linux kernel for Amazon Web Services (AWS) systems
- linux-azure - Linux kernel for Microsoft Azure Cloud systems
- linux-gcp - Linux kernel for Google Cloud Platform (GCP) systems
- linux-gke - Linux kernel for Google Container Engine (GKE) systems
- linux-gkeop - Linux kernel for Google Container Engine (GKE) systems
- linux-ibm - Linux kernel for IBM cloud systems
- linux-oracle - Linux kernel for Oracle Cloud systems
Details
In the Linux kernel, the following vulnerability has been
resolved: netfilter: nf_tables: disallow timeout for anonymous sets
Never used from userspace, disallow these parameters.(CVE-2023-52620)
In the Linux kernel, the following vulnerability has been
resolved: tls: fix race between tx work scheduling and socket close
Similarly to previous commit, the submitting thread (recvmsg/sendmsg)
may exit as soon as the async crypto handler calls complete(). Reorder
scheduling the work before calling complete(). This seems more logical
in the first place, as it’s the inverse order of what the submitting
thread will do.(CVE-2024-26585)
In the Linux kernel, the following vulnerability has been
resolved: tty: n_gsm: fix possible out-of-bounds in gsm0_receive()
Assuming the following: - side A configures the n_gsm in basic option
mode - side B sends the header of a basic option mode frame with data
length 1 - side A switches to advanced option mode - side B sends 2 data
bytes which exceeds gsm->len Reason: gsm->len is not used in advanced
option mode. - side A switches to basic option mode - side B keeps
sending until gsm0_receive() writes past gsm->buf Reason: Neither
gsm->state nor gsm->len have been reset after reconfiguration. Fix this
by changing gsm->count to gsm->len comparison from equal to less than.
Also add upper limit checks against the constant MAX_MRU in
gsm0_receive() and gsm1_receive() to harden against memory corruption of
gsm->len and gsm->mru. All other checks remain as we still need to limit
the data according to the user configuration and actual payload size.]
(CVE-2024-36016)
Update instructions
The problem can be corrected by updating your kernel livepatch to the
following versions:
Ubuntu 20.04 LTS
aws - 106.1
azure - 106.1
gcp - 106.1
generic - 106.1
gkeop - 106.1
ibm - 106.1
lowlatency - 106.1
oracle - 106.1
Ubuntu 18.04 LTS
aws - 106.1
azure - 106.1
gcp - 106.1
generic - 106.1
lowlatency - 106.1
oracle - 106.1
Ubuntu 16.04 LTS
aws - 106.1
azure - 106.1
gcp - 106.1
generic - 106.1
lowlatency - 106.1
Ubuntu 22.04 LTS
aws - 106.1
azure - 106.1
gcp - 106.1
generic - 106.1
gke - 106.1
ibm - 106.1
oracle - 106.1
Ubuntu 14.04 LTS
generic - 106.1
lowlatency - 106.1
Support Information
Livepatches for supported LTS kernels will receive upgrades for a period
of up to 13 months after the build date of the kernel.
Livepatches for supported HWE kernels which are not based on an LTS
kernel version will receive upgrades for a period of up to 9 months
after the build date of the kernel, or until the end of support for that
kernel’s non-LTS distro release version, whichever is sooner.
References
- CVE-2023-52620
- CVE-2024-26585
- CVE-2024-36016