1. Ubuntu Security Notices
  2. LSN-0112-1

LSN-0112-1: Kernel Live Patch Security Notice

Publication date

29 May 2025

Overview

Several security issues were fixed in the kernel.

Releases

Software description

  • aws – Linux kernel for Amazon Web Services (AWS) systems - (>= 4.15.0-1159, >= 5.4.0-1009, >= 5.4.0-1061, >= 5.15.0-1000, >= 6.8.0-1008, >= 4.4.0-1159)
  • aws-5.15 – Linux kernel for Amazon Web Services (AWS) systems - (>= 5.15.0-1000)
  • aws-hwe – Linux kernel for Amazon Web Services (AWS-HWE) systems - (>= 4.15.0-1126)
  • azure – Linux kernel for Microsoft Azure Cloud systems - (>= 5.4.0-1010, >= 5.15.0-1000, >= 6.8.0-1007, >= 4.15.0-1114)
  • azure-4.15 – Linux kernel for Microsoft Azure Cloud systems - (>= 4.15.0-1168)
  • azure-5.15 – Linux kernel for Microsoft Azure cloud systems - (>= 5.15.0-1069)
  • gcp – Linux kernel for Google Cloud Platform (GCP) systems - (>= 5.4.0-1009, >= 5.15.0-1000, >= 6.8.0-1007, >= 4.15.0-1118)
  • gcp-4.15 – Linux kernel for Google Cloud Platform (GCP) systems - (>= 4.15.0-1154)
  • gcp-5.15 – Linux kernel for Google Cloud Platform (GCP) systems - (>= 5.15.0-1000)
  • generic-4.15 – Linux hardware enablement (HWE) kernel - (>= 4.15.0-214, >= 4.15.0-143)
  • generic-4.4 – Linux kernel - (>= 4.4.0-243)
  • aws – Linux kernel for Amazon Web Services (AWS) systems - (>= 4.15.0-1159, >= 5.4.0-1009, >= 5.4.0-1061, >= 5.15.0-1000, >= 6.8.0-1008, >= 4.4.0-1159)
  • aws-5.15 – Linux kernel for Amazon Web Services (AWS) systems - (>= 5.15.0-1000)
  • aws-hwe – Linux kernel for Amazon Web Services (AWS-HWE) systems - (>= 4.15.0-1126)
  • azure – Linux kernel for Microsoft Azure Cloud systems - (>= 5.4.0-1010, >= 5.15.0-1000, >= 6.8.0-1007, >= 4.15.0-1114)
  • azure-4.15 – Linux kernel for Microsoft Azure Cloud systems - (>= 4.15.0-1168)
  • azure-5.15 – Linux kernel for Microsoft Azure cloud systems - (>= 5.15.0-1069)
  • gcp – Linux kernel for Google Cloud Platform (GCP) systems - (>= 5.4.0-1009, >= 5.15.0-1000, >= 6.8.0-1007, >= 4.15.0-1118)
  • gcp-4.15 – Linux kernel for Google Cloud Platform (GCP) systems - (>= 4.15.0-1154)
  • gcp-5.15 – Linux kernel for Google Cloud Platform (GCP) systems - (>= 5.15.0-1000)
  • generic-4.15 – Linux hardware enablement (HWE) kernel - (>= 4.15.0-214, >= 4.15.0-143)
  • generic-4.4 – Linux kernel - (>= 4.4.0-243)
  • generic-5.15 – Linux hardware enablement (HWE) kernel - (>= 5.15.0-0)
  • generic-5.4 – Linux kernel - (>= 5.4.0-150, >= 5.4.0-26)
  • gke – Linux kernel for Google Container Engine (GKE) systems - (>= 5.15.0-1000)
  • gkeop – Linux kernel for Google Container Engine (GKE) systems - (>= 5.4.0-1009)
  • ibm – Linux kernel for IBM cloud systems - (>= 5.4.0-1009, >= 5.15.0-1000, >= 6.8.0-1005)
  • ibm-5.15 – Linux kernel for IBM cloud systems - (>= 5.15.0-1000)
  • linux – Linux kernel - (>= 5.15.0-71, >= 5.15.0-24, >= 6.8.0-1)
  • lowlatency-4.15 – Linux hardware enablement (HWE) kernel - (>= 4.15.0-214, >= 4.15.0-143)
  • lowlatency-4.4 – Linux kernel - (>= 4.4.0-243)
  • lowlatency-5.15 – Linux hardware enablement (HWE) kernel - (>= 5.15.0-0)
  • lowlatency-5.4 – Linux kernel - (>= 5.4.0-150, >= 5.4.0-26)
  • oracle – Linux kernel for Oracle Cloud systems - (>= 4.15.0-1129, >= 5.4.0-1121, >= 5.15.0-1055, >= 6.8.0-1005)
  • oracle-5.15 – Linux kernel for Oracle Cloud systems - (>= 5.15.0-1055)

Details

In the Linux kernel, the following vulnerability has been
resolved: nfsd: fix use-after-free due to delegation race A delegation
break could arrive as soon as we've called vfs_setlease. A delegation break
runs a callback which immediately (in nfsd4_cb_recall_prepare) adds the
delegation to del_recall_lru. If we then exit nfs4_set_delegation without
hashing the delegation, it will be freed as soon as the callback is done
with it, without ever being removed from del_recall_lru. Symptoms show up
later as use-after-free or list corruption warnings, usually in the
laundromat thread. I suspect aba2072f4523 'nfsd: grant read delegations to
clients holding writes' made this bug easier to hit, but I looked as far
back as v3.0 and it looks to me it already had the same problem. So I'm not
sure where the bug was introduced; it may have been there from the
beginning.)(CVE-2021-47506)

Jann Horn...

In the Linux kernel, the following vulnerability has been
resolved: nfsd: fix use-after-free due to delegation race A delegation
break could arrive as soon as we've called vfs_setlease. A delegation break
runs a callback which immediately (in nfsd4_cb_recall_prepare) adds the
delegation to del_recall_lru. If we then exit nfs4_set_delegation without
hashing the delegation, it will be freed as soon as the callback is done
with it, without ever being removed from del_recall_lru. Symptoms show up
later as use-after-free or list corruption warnings, usually in the
laundromat thread. I suspect aba2072f4523 'nfsd: grant read delegations to
clients holding writes' made this bug easier to hit, but I looked as far
back as v3.0 and it looks to me it already had the same problem. So I'm not
sure where the bug was introduced; it may have been there from the
beginning.)(CVE-2021-47506)

Jann Horn discovered that the watch_queue event notification subsystem in
the Linux kernel contained an out-of-bounds write vulnerability. A local
attacker could use this to cause a denial of service (system crash) or
escalate their privileges.)(CVE-2022-0995)

In the Linux kernel, the following vulnerability has been
resolved: net: atlantic: eliminate double free in error handling logic
Driver has a logic leak in ring data allocation/free, where aq_ring_free
could be called multiple times on same ring, if system is under stress and
got memory allocation error. Ring pointer was used as an indicator of
failure, but this is not correct since only ring data is
allocated/deallocated. Ring itself is an array member. Changing ring
allocation functions to return error code directly. This simplifies error
handling and eliminates aq_ring_free on higher layer.)(CVE-2023-52664)

In the Linux kernel, the following vulnerability has been
resolved: ceph: prevent use-after-free in encode_cap_msg() In
fs/ceph/caps.c, in encode_cap_msg(), 'use after free' error was caught by
KASAN at this line - 'ceph_buffer_get(arg->xattr_buf);'. This implies
before the refcount could be increment here, it was freed. In same file, in
'handle_cap_grant()' refcount is decremented by this line -
'ceph_buffer_put(ci->i_xattrs.blob);'. It appears that a race occurred and
resource was freed by the latter line before the former line could
increment it. encode_cap_msg() is called by send_cap() and send_cap()
is called by ceph_check_caps() after calling prep_cap(). prep_cap() is
where arg->xattr_buf is assigned to ci->i_xattrs.blob. This is the spot
where the refcount must be increased to prevent 'use after free' error.)(CVE-2024-26689)

In the Linux kernel, the following vulnerability has been
resolved: smb: client: fix potential UAF in smb2_is_valid_lease_break()
Skip sessions that are being teared down (status == SES_EXITING) to avoid
UAF.)(CVE-2024-35864)

In the Linux kernel, the following vulnerability has been
resolved: HID: core: zero-initialize the report buffer Since the report
buffer is used by all kinds of drivers in various ways, let's zero-
initialize it during allocation to make sure that it can't be ever used to
leak kernel memory via specially-crafted report.)(CVE-2024-50302)

In the Linux kernel, the following vulnerability has been
resolved: media: dvbdev: prevent the risk of out of memory access The
dvbdev contains a static variable used to store dvb minors. The behavior of
it depends if CONFIG_DVB_DYNAMIC_MINORS is set or not. When not set,
dvb_register_device() won't check for boundaries, as it will rely that a
previous call to dvb_register_adapter() would already be enforcing it. On a
similar way, dvb_device_open() uses the assumption that the register
functions already did the needed checks. This can be fragile if some device
ends using different calls. This also generate warnings on static check
analysers like Coverity. So, add explicit guards to prevent potential risk
of OOM issues.)(CVE-2024-53063)

In the Linux kernel, the following vulnerability has been
resolved: ALSA: usb-audio: Fix out of bounds reads when finding clock
sources The current USB-audio driver code doesn't check bLength of each
descriptor at traversing for clock descriptors. That is, when a device
provides a bogus descriptor with a shorter bLength, the driver might hit
out-of-bounds reads. For addressing it, this patch adds sanity checks to
the validator functions for the clock descriptor traversal. When the
descriptor length is shorter than expected, it's skipped in the loop. For
the clock source and clock multiplier descriptors, we can just check
bLength against the sizeof() of each descriptor type. OTOH, the clock
selector descriptor of UAC2 and UAC3 has an array of bNrInPins elements and
two more fields at its tail, hence those have to be checked in addition to
the sizeof() check.)(CVE-2024-53150)

In the Linux kernel, the following vulnerability has been
resolved: sunrpc: fix one UAF issue caused by sunrpc kernel tcp socket BUG:
KASAN: slab-use-after-free in tcp_write_timer_handler+0x156/0x3e0 (CVE-2024-53168)

In the Linux kernel, the following vulnerability has been
resolved: ALSA: usb-audio: Fix potential out-of-bound accesses for Extigy
and Mbox devices A bogus device can provide a bNumConfigurations value that
exceeds the initial value used in usb_get_configuration for allocating
dev->config. This can lead to out-of-bounds accesses later, e.g. in
usb_destroy_configuration.)(CVE-2024-53197)

In the Linux kernel, the following vulnerability has been
resolved: drm/amdgpu: fix usage slab after free [ +0.000021] BUG: KASAN:
slab-use-after-free in drm_sched_entity_flush+0x6cb/0x7a0 (CVE-2024-56551)

In the Linux kernel, the following vulnerability has been
resolved: wifi: brcmfmac: Fix oops due to NULL pointer dereference in
brcmf_sdiod_sglist_rw() This patch fixes a NULL pointer dereference bug in
brcmfmac that occurs when a high 'sd_sgentry_align' value applies (e.g.
512) and a lot of queued SKBs are sent from the pkt queue. The problem is
the number of entries in the pre-allocated sgtable, it is nents =
max(rxglom_size, txglom_size) + max(rxglom_size, txglom_size) >> 4 + 1.
Given the default [rt]xglom_size=32 it's actually 35 which is too small.
Worst case, the pkt queue can end up with 64 SKBs. This occurs when a new
SKB is added for each original SKB if tailroom isn't enough to hold
tail_pad. At least one sg entry is needed for each SKB. So, eventually the
'skb_queue_walk loop' in brcmf_sdiod_sglist_rw may run out of sg entries.
This makes sg_next return NULL and this causes the oops. The patch sets
nents to max(rxglom_size, txglom_size) 2 to be able handle the worst-
case. Btw. this requires only 64-35=29 16 (or 20 if
CONFIG_NEED_SG_DMA_LENGTH) = 464 additional bytes of memory.)(CVE-2024-56593)

In the Linux kernel, the following vulnerability has been
resolved: jfs: add a check to prevent array-index-out-of-bounds in
dbAdjTree When the value of lp is 0 at the beginning of the for loop, it
will become negative in the next assignment and we should bail out.)(CVE-2024-56595)

In the Linux kernel, the following vulnerability has been
resolved: jfs: array-index-out-of-bounds fix in dtReadFirst The value of
stbl can be sometimes out of bounds due to a bad filesystem. Added a check
with appopriate return of error code in that case.)(CVE-2024-56598)

In the Linux kernel, the following vulnerability has been
resolved: Bluetooth: btmtk: avoid UAF in btmtk_process_coredump
hci_devcd_append may lead to the release of the skb, so it cannot be
accessed once it is called.
(CVE-2024-56653)

In the Linux kernel, the following vulnerability has been
resolved: drm/dp_mst: Ensure mst_primary pointer is valid in
drm_dp_mst_handle_up_req() While receiving an MST up request message from
one thread in drm_dp_mst_handle_up_req(), the MST topology could be removed
from another thread via drm_dp_mst_topology_mgr_set_mst(false), freeing
mst_primary and setting drm_dp_mst_topology_mgr::mst_primary to NULL. This
could lead to a NULL deref/use-after-free of mst_primary in
drm_dp_mst_handle_up_req(). Avoid the above by holding a reference for
mst_primary in drm_dp_mst_handle_up_req() while it's used. v2: Fix kfreeing
the request if getting an mst_primary reference fails.)(CVE-2024-57798)

Checking update status

To check your kernel type and Livepatch version, enter this command:

canonical-livepatch status

The problem can be corrected in these Livepatch versions:

Kernel type 24.04 22.04 20.04 18.04 16.04
aws 112.1 112.2 112.1 112.1 112.1
aws-5.15 — — 112.2 — —
aws-hwe — — — — 112.1
azure 112.1 112.2 112.2 — 112.1
azure-4.15 — — — 112.1 —
azure-5.15 — — 112.2 — —
gcp 112.1 112.2 112.2 — 112.1
gcp-4.15 — — — 112.1 —
gcp-5.15 — — 112.2 — —
generic-4.15 — — — 112.1 112.1
generic-4.4 — — — — 112.1
generic-5.15 — — 112.2 — —
generic-5.4 — — 112.1 112.1 —
gke — 112.1 — — —
gkeop — — 112.1 — —
ibm 112.1 112.1 112.1 — —
ibm-5.15 — — 112.1 — —
linux 112.1 112.2 — — —
lowlatency-4.15 — — — 112.1 112.1
lowlatency-4.4 — — — — 112.1
lowlatency-5.15 — — 112.2 — —
lowlatency-5.4 — — 112.1 112.1 —
oracle 112.2 112.1 112.1 112.1 —
oracle-5.15 — — 112.1 — —

References

Have additional questions?

Talk to a member of the team ›